[jsr294-modularity-eg] 294 EG conf call, 2009-05-13

[Bob Lee]

On Thu, May 14, 2009 at 1:21 PM, Alex Buckley <Alex.Buckley at sun.com> wrote:

> As a schema language (or metatheory, as Doug put it), module directive
> types share some restrictions of annotation types: optional operands cannot
> be expressed (default values may not be appropriate in this domain)


Will you please provide an example where you can't use a default sentinel
value?


> and deep structures such as versions are unwieldy to define and use (akin
> to @Version(@Major(".."), @Minor(".."), @Qualifier("..")).
>

Versions can be expressed as strings and evaluated by the module system,
just like we do with the less strict approach.


> Peter (and to a lesser extent, Doug) supported Bob's use of a schema
> language to allow a compiler to partially validate a module compilation
> unit. Bryan and Alex disagreed, taking the position that validation is too
> large a problem to be solved without significant module system help, and too
> small a problem to justify a whole schema language which only a handful of
> module system designers will ever write in.
>

It's not my intention to validate without a module system. *We will always
need a module system at build time*. It's my intention to limit the
structure of module directives and ensure that their behavior is familiar to
Java developers. Moving so much responsibility for validation to module
system implementations (which may or may not implement checks consistently
with existing checks in the language) is a cop out and is bad for Java
programmers.

For example, with the key/value approach, a module system could ignore
operators and operands it doesn't understand. I don't think any of this
should be allowed; to allow this sort of thing would violate the principle
of least astonishment.

Speaking as a user, as a module system's API evolves, I want it to do so in
a way that I'm already familiar with (like interfaces and annotations). If I
make a typo, a module system shouldn't be allowed to ignore it. I want the
semantics of module directive types to be documented in a uniform way
(Javadoc-style). I don't want to read vendor-specific docs in a
vendor-specific format. I don't like leaving Java source code to reading
semantic information; that's one reason I'm not fond of EE. Am I supposed to
read the Javadocs on the vendor's ModuleSystem implementation?

We aren't really simplifying much for ourselves by moving responsibility
from the compiler to a module system. We're just moving complexity from the
grammar to an API. So far, the APIs that have been thrown out have not been
very forward looking. What if we want to support more than just String
values in the future? We'd have to replace the currently proposed
interfaces. That's not something we should take any more lightly just
because the interface isn't referenced by the JLS.

The argument that we'll only have a handful of module systems doesn't hold
water for me. One, we should restrict what module systems can do so they at
least have some level of uniformity in syntax if not semantics. Two, this
has turned into a general purpose language construct, and we don't know all
the ways programmers will use it. I plan to use it for dependency injection
implementation and would just assume have a statically typed API with more
than just String values to work against instead of a Map<String, String>. If
we get Map literals in Java 7, we should get them here (in annotations,
too). If we get them in Java 8, we should add them here then.

One last thing I don't like about the heavily API-based approach is that it
gives module systems more power than necessary at the expense of tools. Our
API will have to anticipate everything a tool may want to do. How did
JSR-269 fare here? With a grammar based-approach, the API gets very simple,
familiar, and forward-compatible, and tools can implement module-system
independent validation for themselves and ensure a high QoS:

  interface ModuleSystem {
    List<Module> findModules(List<ModuleDirective> directives) throws
EvaluationException;
  }

  class EvaluationException extends Exception {
    ...
    List<Error> errors();
  }


> Bryan also believed it was a disservice to users if module directive types
> allowed dependencies for different module systems in the same compilation
> unit, as Bob's example showed.


This is an orthogonal issue. With the lest strict approach, you
*must*separate module blocks by system type because the operators
don't have
namespaces. With a more strict approach, you can go either way.

Bob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/jsr294-modularity-eg/attachments/20090516/44c23835/attachment.html>