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

[David Bosschaert]

On 5 January 2012 16:25, Eric Johnson <eric at tibco.com> wrote:
> 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.
>

Just FYI I started modifying OpenJDK/Jigsaw in the context of the
Penrose project to see if something like module-info.xml instead of
module-info.class/.java would work. From the prototype that I made it
seems to make a lot of sense. See here:
http://mail.openjdk.java.net/pipermail/penrose-dev/2012-March/000023.html

Best regards,

David