What is a language construct? (was Re: Comment on state of Project Jigsaw)

[Eric Johnson]

At the risk of tilting at windmills, I'm going to try two responses 
here. First this email.

Consider an alternate straw-man, wherein the module descriptor uses XML, 
let's see how the responses change based on what Rémi proposes. Counter 
responses sprinkled throughout.

<strawman>

On 1/5/12 3:14 PM, Rémi Forax wrote:
> On 01/05/2012 02:23 PM, Peter Kriens wrote:
>> On 4 jan. 2012, at 17:02, Rémi Forax wrote:
>>> The .class format is already an extensible versioned container format
>>> with a dictionnary which is able to store string and class name.
>>> No shoehorn here.
>> Hmmmmm. To me this is the biggest shoehorn I've seen in a long, long 
>> time ... Would you ever, ever, use this format if it had not been 
>> there before? Is there any reason to use the class file except that 
>> it happens already be there?
>>
>> The worst thing is that you could view a class as a container of 
>> members, which on a higher level is also true for a module. However, 
>> the way the class format is used is ignoring this possibility and 
>> only (ab)uses the constant pool and the type's (!) attributes. Further:
>>
>> a) It is not easy readable for inspection
>
> javap module-info.class

cat module-info.xml (Java classfile tools need not be used - simpler!)
>
>> c) You have to stopgap mandatory fields like super class, access, 
>> class name, etc.
>
> No, the access_flags will indicate that it's a module descriptor.

The root element of the XML file will indicate it is a module 
descriptor. If you add namespaces, a schema-aware XML editor can even 
validate conformance of the "syntax" of expected elements, if not the 
semantics.

>
>> d) It will confuse the heck out of any existing class parsers
>
> No, the classfile is versioned. It has already changed twice (1.5 and 
> 1.7)

As a separate XML file, no existing class parsers need to be updated at all.

>
>> e) It is not easy extendable for other module systems
>
> The attribute_info let you store any attributes you want.

The attributes of XML elements can let you store any additional data you 
want.

>
>> f) There is just no need to use the class file
>
> a circular argument, sorry my brain overflow.

Your argument seems to be "I have a hammer, therefore this is a nail" - 
I have a container file format, therefore this module data can fit into it.

In other words, the argument is not circular. Peter and I are merely 
pointing out that the use of a .class file, or even just a .class file 
format under a different name is not a foregone conclusion based on the 
requirements stated so far.
>
>> h) It unnecessarily complicates management systems
>
> why ?

Myriad tools can be used to edit/update an XML format file, not just the 
specific tools designed to work with Java class files. The fact that you 
*also* insist that it also end with ".class" means that all tools that 
look for class files will now have to pay attention to when to ignore 
these files. Examples include obfuscators, byte-code analysis tools, etc.

>
>>
>> This is an almost perfect example of Conways law pointed out by 
>> Gafter. Once you're familiar with a technology you frame solutions in 
>> that technology.
>
> A module descriptor has to be versioned, extensible, to contains 
> synthetized values (tagged as such),
> be validated (by at least checking that referenced modules, packages 
> and types exist),
> in my opinion, that's match what the classfile format is.

An XML file can be versioned, is extensible, can contain synthesized 
values (which can be tagged as such), can be validated by a schema, and 
use tools like SchemaTron to further check semantics. In my opinion 
that's a perfect fit for schema-constrained XML file.

>
> If you prefer another format, I have no problem but, in my opinion,
> it will be enough close to the classfile format to not worth to create 
> a new format.

And in my opinion, you're overloading an existing container format with 
surprising new content, when an existing meta-format works better for 
myriad uses.


</strawman>

The above isn't all to argue that XML is the best choice here, merely 
that it seems to work to counter the arguments put forth so far that the 
classfile is the ideal format. At a minimum, the file deserves a 
different extension so that existing tools that only care about actual 
classes don't read it for byte codes.

-Eric.