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

[Eric Johnson]

Hi Rémi,

On 1/5/12 3:25 PM, Rémi Forax wrote:
> 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 understood that. I think you're overlooking my point about how many 
additional changes tools might need to make. Think of the universe of 
existing tools that crawl Java .class files for whatever reason. How 
many of those existing tools need to care about module information 
(answer 0%)? How many of those tools will need to be updated - beyond 
accepting the newer version - if the module information is loaded into 
an existing .class file format, with a .class extension.

If I were drawing a picture, I'd have a circle with three pie slices:

  * tools that need to change merely to accept the new version of the
    class file format
  * tools that don't care about the module information but will need to
    change to work around/ignore said data
  * tools that actually care about the new module information.

Question is, how big are you making that middle slice? If you put the 
module information into an alternate format, I *know* that the second 
slice is an empty set.
>
>>
>> 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.

XML deals quite nicely with character encodings.

As for updating, it is merely that the tooling is simpler. Re-validating 
might be required in either case.

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

My point was that any "compilation" process you can do on a module 
descriptor can be done on the file itself without reference to those 
external entities. /Validation/ is a separate problem.

For an analogy, a Python file can be compiled to a ".pyc" file without 
any knowledge of external dependencies. However, it cannot be run unless 
those external dependencies are satisfied.

-Eric.