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

[Rémi Forax]

On 01/04/2012 09:49 PM, Eric Johnson wrote:
> 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?

The classfile format is versioned, each time a new version is created, 
like 1.5 and 1.7 did,
you have to update your tools. most of the tools, first check the 
version and just exit
if the version number is unknown.

>
> 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. 

If you use a text format, you introduce several stupid problems like the 
charset encoding
and the fact that a user can update the module descriptor without 
re-validating it.

> 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.)

I don't agree.
You still need to validate the module descriptor before distributing it 
so a long time before installing it.
And the module descriptor contains references to packages and types that 
need to be checked.

>
> -Eric.
>

Rémi