module-info.class spec and attributes

[Rémi Forax]

David,
I think storing the module metadata as a class file is a brilliant idea.

First you have to think that what we want is not one text file but two.
Some module metadata are generated (the one marked synthetic in the 
current format)
by the compiler and as a user I don't want to see them, edit them, etc.

Eclipse plugins use the approach of having one file for the two 
purposes, be a module
descriptor editable by a human and be a module deployment descriptor 
readable
by the module runtime.
As a user, the experience is painful, the file is big and a big part of 
the data are useless
and sometimes you have to reconcile the state of the source and the 
plugin descriptor
by hand.

To summarize, we need a file which is readable/writable by a human, 
readable by the compiler
and the compiler need to generate a module deployment from it that need 
to be readable
by the module runtime system.
Hence, it's logical to have a Java file and a class file.

Also a classfile is versioned, compact, has no character encoding problem,
is well integrated with the other files and as Alex said is more 
efficient than an XML file.

Another cool point is that because the module descriptor is a Java file 
you know
where to put the module doc :)

Rémi

On 06/30/2011 04:51 AM, Alex Buckley wrote:
> 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.
>>
>>