What is a language construct? (was Re: Comment on state of Project Jigsaw)
eric at tibco.com
Wed Jan 4 12:49:50 PST 2012
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.)
More information about the jigsaw-dev