Late for the train

[mark.reinhold at oracle.com]

2012/7/19 17:46 -0700, eric at tibco.com:
> On 7/19/12 5:06 PM, Alex Buckley wrote:
>> On 7/19/2012 4:54 PM, Alex Buckley wrote:
>>> Because the compiler needs to know every type's module membership
>>> (module name _and_ version), and assuming you want to compile
>>> multiple modules in one compiler invocation, and assuming you might
>>> start compilation with only sources (not JARs), it becomes necessary
>>> to rework your Java compiler - a lot.
>> 
>> I want to add that this is where the "module declarations in Java source
>> code" theme comes from.
> 
> The theme, though, is a mis-statement of the problem. The problem statement
> should use the phrase "module declarations **and** Java source code". The
> choice of "in" is an implementation choice. The obvious requirement is that
> both sets of information be used together by the compiler, without dictating
> the input form of the module declaration.

I don't think Alex meant his theme to be taken as a statement of the
problem, but rather as a rationale for the particular solution we're
exploring here right now.

I agree that a purely-stated requirement would not dictate the form of
module declarations, leaving a design free to use MANIFEST.MF, use a JSON
or XML syntax, extend the Java language, or do something else entirely.

For what it's worth, I also agree that the present requirements document
is flawed in that it's a mixture of pure requirements and partial design
choices.  That's due to its heritage as a record of discussions amongst
many parties.  I expect that revising that document into a more abstract
form will be one of the first activities of the Expert Group of the
forthcoming Java Platform Module System JSR.

> ...
> 
>> Hence a module is declared via a Java language construct with syntax similar
>> to constructs which declare other entities (classes, interfaces).
> 
> And *even if* you think that this should result in changes to the recognized
> keywords in ".java" files, and an input file that uses a special ".java" name
> to carry said info, there's still no reason that the output has to be a .class
> file, after the darn thing is compiled.

No, there's no reason that it absolutely has to be a class file.  There
are, however, some good reasons for that choice.  One is that existing
tools are apt to get very confused if there's suddenly a special kind of
Java source file that doesn't produce a corresponding class file when
compiled.  Sure, that can be handled by updating the tools, but it seems
easier just to maintain the invariant that a file whose name ends in
".java" always produces a file whose name ends in ".class" when you
compile it.

> Those are all implementation choices. And from discussions we've had, there are
> many folks such as myself that think that those implementation choices come at
> an unnecessary cost. Different implementation choices might be better.

You're absolutely right, and the EG might ultimately decide to make a
different set of choices.  If and when that happens then this Project
will change course as appropriate.

In the meantime, however, we're focused on exploring a design in which
modularity is a language construct, as described in the draft design
overview [1].  This approach is markedly different from that of existing
Java modularity solutions, and I think it's important to have a good
understanding of it ahead of the EG discussion.

- Mark


[1] http://cr.openjdk.java.net/~mr/jigsaw/notes/jigsaw-big-picture-01