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

[Eric Johnson]

Comment below...

On 1/4/12 5:02 PM, Rémi Forax wrote:
> On 01/04/2012 04:23 PM, David Bosschaert wrote:
>> On 4 January 2012 14:46, Rémi Forax<forax at univ-mlv.fr>  wrote:
>>> The module descriptor is not the .java but the .class,
>>> the .java is a convenient way to specify the module descriptor.
>> I have nothing against a convenient way of specifying a module
>> description, I actually see that as a requirement :) but that
>> requirement doesn't imply that it needs to be shoe-horned into .java
>> and .class files!
>
> 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. 

OK, perhaps the format is reusable, but how will existing tools fare 
with it? Will existing IDEs choke on the file unless modified because it 
has unexpected content? Will code obfuscation tools obfuscate it by 
default? Will Ant need to be updated to treat these files specially? 
Will any ASM client ever written fall over because the module definition 
file doesn't actually include byte codes? What about tools like "bnd" 
that introspect ".class" files looking for referenced symbols, so that 
they can generate OSGi information?

I think the notion of reusing a format might work, but I suspect reusing 
the extension ".class" will cause a lot of churn in downstream tooling, 
and it doesn't sound like that's been considered here. (And I worry that 
I've written code that would succumb to that churn.)

If you're arguing that it is a useful container format, though, there 
are plenty of other "container formats" - JSON and XML jump to mind - 
that can equally well satisfy the requirements that have been stated so 
far. Since modules must be "installed" (if I've understood what I've 
read correctly), then any notions of pre-compiling them are likely not 
essential, because the installation process can do what it wishes, and 
the files themselves have no "external" dependencies that need to be 
controlled in a compilation process (unlike, say, the existing Java 
classes that we compile.)

-Eric.