Late for the train

[Eric Johnson]

Since this has been a pet peeve of mine, this elicits a comment from me:

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.

> A module declaration which gives name and version for the purpose of 
> compile-time and runtime access control is _by definition_ a 
> first-class entity in the Java platform.

Sure, but so is MANIFEST.MF, which carries compile-time information 
(example, Main-Class), as well as signing information, which must be 
used by the runtime when a security manager is turned on.

> 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.

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.

-Eric.