is ClassLoader.loadClass() supposed to work on module-info classes?

[Stefan Fuchs]

Thank you for repeating my concerns I raised in September.


Stephen Felts wrote:
> I agree.  I would much rather be able to see the information using unzip -p and update it using a text editor or any tool that can write text.
>
>
>
> -----Original Message-----
> From: Paul Benedict [mailto:pbenedict at apache.org]
> Sent: Wednesday, December 02, 2015 9:53 AM
> To: Remi Forax
> Cc: jigsaw-dev at openjdk.java.net
> Subject: Re: is ClassLoader.loadClass() supposed to work on module-info classes?
>
> This is probably a good time to (once again) bring up the objection that the Module Descriptor shouldn't be a class file to begin with. I know I am not the only one who has stated this on the mailing list. I doubt this email will gain any traction, but it's something the EG should seriously consider -- as a group. Especially since the Module Descriptor is likely to be read/written by many tools to add custom data, it's clear it's more like a Manifest than a source file.
>
> Cheers,
> Paul
>
> On Wed, Dec 2, 2015 at 8:46 AM, Remi Forax <forax at univ-mlv.fr> wrote:
>
>> ----- Mail original -----
>>> De: "Alan Bateman" <Alan.Bateman at oracle.com>
>>> À: "Stephane Epardaud" <stef at epardaud.fr>,
>>> jigsaw-dev at openjdk.java.net
>>> Envoyé: Mercredi 2 Décembre 2015 14:56:00
>>> Objet: Re: is ClassLoader.loadClass() supposed to work on
>>> module-info
>> classes?
>>> On 02/12/2015 11:01, Stephane Epardaud wrote:
>>>> Just tried it and got:
>>>>
>>>> Exception in thread "main" java.lang.ClassFormatError: Illegal
>>>> class name "com.ceylon.java9.Test" in class file module-info
>>>>       at java.lang.ClassLoader.defineClass1(java.base at 9.0/Native
>> Method)
>>>>       at
>>>>       java.lang.ClassLoader.defineClass(java.base at 9.0
>> /ClassLoader.java:854)
>>>>       at
>>>> java.security.SecureClassLoader.defineClass(java.base at 9.0
>> /SecureClassLoader.java:152)
>>>>       at
>>>> java.net.URLClassLoader.defineClass(java.base at 9.0
>> /URLClassLoader.java:462)
>>>>       at
>>>> java.net.URLClassLoader.access$100(java.base at 9.0
>> /URLClassLoader.java:75)
>>>>       at
>>>>       java.net.URLClassLoader$1.run(java.base at 9.0
>> /URLClassLoader.java:370)
>>>>       at
>>>>       java.net.URLClassLoader$1.run(java.base at 9.0
>> /URLClassLoader.java:364)
>>>>       at java.security.AccessController.doPrivileged(java.base at 9.0
>> /Native
>>>> Method)
>>>>       at
>>>> java.net.URLClassLoader.findClass(java.base at 9.0
>> /URLClassLoader.java:363)
>>>>       at java.lang.ClassLoader.loadClass(java.base at 9.0
>> /ClassLoader.java:440)
>>>>       at java.lang.ClassLoader.loadClass(java.base at 9.0
>> /ClassLoader.java:373)
>>>> I know it works for package-info.class files, but is it supposed
>>>> to
>> work
>>>> with module-info.class files too? Or is it just not implemented yet?
>>>>
>>> The this_class should be <internal-name>/module-info but in any
>>> case, this isn't the way to "define" a module to the run-time.
>>> Instead modules are defined in layers, with Layer.create the method to create a Layer.
>> Alan,
>> there are two issues, the first one is should a module-info be
>> accessible at runtime as a Class and the second is that the current
>> binary format for a module-info.class break the invariant that the
>> name of the .class is the same as the name inside of the .class
>> because the name used for a module-info.class is the name of the module.
>>
>> 1) I think module-info should not be reified to a class, defineClass
>> should reject any .class that has a module bit set in the class file format.
>>     If we allow to create a Class from a module-info, a class loader
>> may be able to load several module-info.class and it will be a real
>> mess because module-info.class is not qualified in the jar file so the
>> classloader will return the first seen.
>> 2) In term of backward compatibility, I think i prefer that the
>> module-info.class uses "module-info" as class name and store the name
>> of the module inside an attribute.
>>     An already existing tool that parses the bytecode format may forget
>> to check the class version and use the module name to do something, if
>> the name inside the module-info is "module-info", it will be easier to
>> diagnose because the error will report a failure on "module-info" and
>> not on a name that can also be a package name.
>>
>>> -Alan.
>>>
>> Rémi
>>