module-info.class spec and attributes

[Alex Buckley]

I think we're slightly missing each other here. I wasn't implying javac 
is unable to cache module declarations; rather that module declarations 
are now woven deeply into compilation because determining the visibility 
of _any_ type (whether available in source or class file form) is 
dependent on a graph of module declarations (possibly cached by the 
module system, but not when the world is being built from source). 
Jigsaw is just keeping the structure of those module declarations in 
source/binary forms that compilers are familiar with.

Alex

On 6/29/2011 6:00 PM, David M. Lloyd wrote:
> Not really.  In fact that's basically using the (apparently poor) design 
> choices of the compiler to justify this, which I find to be exceedingly 
> weak.
> 
> The compiler should never need to parse module information more than 
> once per compilation, regardless of how many source files are compiled. 
>  If it's requiring that, fix the real problem, rather than using it as 
> justification for crap decisions elsewhere.
> 
> On 06/29/2011 07:46 PM, Alex Buckley wrote:
>> In the context of Project Jigsaw, javac parses module declarations every
>> time a source file in a modular directory structure is compiled. That's
>> a powerful driver for Java-like source syntax and a class file form.
>>
>> Projects which don't put module information so close to the compiler may
>> well choose other forms.
>>
>> Alex
>>
>> On 6/29/2011 5:24 PM, David M. Lloyd wrote:
>>> On 06/29/2011 07:07 PM, Alex Buckley wrote:
>>>> (Sent this mail yesterday but I think it got lost.)
>>>>
>>>> On 6/28/2011 2:24 PM, David Bosschaert wrote:
>>>>> I wonder why such a binary .class file for module declarations is
>>>>> really needed. Why not go for a textual file, for instance
>>>>> META-INF/module-info.jmod (or something like that) and declare the
>>>>> module declarations in there using a textual format of some sort?
>>>>
>>>> The arguments for a binary compiled form are given at:
>>>>
>>>> http://openjdk.java.net/projects/jigsaw/doc/draft-java-module-system-requirements-12#_C 
>>>>
>>>>
>>>
>>> All of which are trivially debunkable. Yes, it is *slightly* more
>>> efficient to read structured binary than a text format. It is an
>>> insignificant difference though. We actually parse ours as XML using
>>> StAX, which should be somewhat more expensive than a dedicated text
>>> parser, and it's so fast that I'm not even able to get a significant
>>> measurement of the time when booting up a 100+ module project. The
>>> performance argument is invalid.
>>>
>>> And constraining the module metadata to a Java-like syntax with a
>>> Java-like file name is just a dumb idea. There's no reason for it.
>>>
>>> Saying that requiring a tool to modify the metadata for a module is
>>> somehow a good thing is pretty off the wall too. I mean just crazy.
>>>
>>> Come down to Earth guys.
>>>
>>>>> IMO there are multiple benefits associated keeping the textual format.
>>>>> People using the jar can use a simple zip tool to look inside the jar
>>>>> to see what its dependencies are. Additionally tools can easily be
>>>>> written to read the module-info.jmod file without needing to resort to
>>>>> classfile parsing libraries. The module information can be of use to
>>>>> both developer as well as deployer tools.
>>>>>
>>>>> Finally it's probably easier to make the textual file extensible, as
>>>>> required by [1], without resorting to inefficient reflection-style
>>>>> operations.
>>>>
>>>> I think these points are also captured in Appendix C. Could not the 
>>>> same
>>>> points have been made in favor of a textual format for class and
>>>> interface declarations?
>>>
>>> Yup. But that ship has sailed. A binary format for module
>>> meta-information is going to be yet another annoying disaster.
> 
>