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

[Jeff MAURY]

Being a meta-data container, I don't understand why it's not under META-INF
?

Jeff

On Wed, Dec 2, 2015 at 4:15 PM, David M. Lloyd <david.lloyd at redhat.com>
wrote:

> On 12/02/2015 09:05 AM, Remi Forax wrote:
>
>>
>>
>> ----- Mail original -----
>>
>>> De: "David M. Lloyd" <david.lloyd at redhat.com>
>>> À: jigsaw-dev at openjdk.java.net
>>> Envoyé: Mercredi 2 Décembre 2015 15:52:56
>>> Objet: Re: is ClassLoader.loadClass() supposed to work on module-info
>>>  classes?
>>>
>>> On 12/02/2015 08:46 AM, Remi Forax 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.
>>>>
>>>
>>> If it's not a class, it's pretty bizarre to call it "module-info.class".
>>>    At this point can we admit we're bending over backwards for principles
>>> that don't really add up?
>>>
>>
>> We already had this discussion, no ?
>>
>> It's a ".class" but not a java.lang.reflect.Class, i.e it's a compiled
>> artifact of the Java platform,
>> and the real question is why the file format of Java the platform is
>> .class and not .btcd (for bytecode).
>>
>
> You can couch it in whatever terms you want, but it's still an ugly
> duckling, and entirely self-justified.  There's no good solid reason to
> make this into a class file other than the social excuse "make it part of
> the language/JVM".
>
> --
> - DML
>



-- 
Jeff MAURY


"Legacy code" often differs from its suggested alternative by actually
working and scaling.
 - Bjarne Stroustrup

http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.twitter.com/jeffmaury