Late for the train

[Alex Buckley]

On 7/20/2012 11:18 AM, mark.reinhold at oracle.com wrote:
> 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.

... extend the Java _syntax_ ...

To be absolutely clear: module membership must be part of the Java 
language because module membership is to govern access control to 
module-private types at compile-time and runtime.

A separate topic is the syntactic mechanism(s) by which a module is 
declared, its general membership expressed, and its module-private 
membership expressed. (Still saying nothing about dependencies to keep 
things simple.)

Alex