module-info.class spec and attributes

[Alex Buckley]

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.