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 <fo...@univ-mlv.fr> wrote: > ----- Mail original ----- > > De: "Alan Bateman" <alan.bate...@oracle.com> > > À: "Stephane Epardaud" <s...@epardaud.fr>, jigsaw-dev@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@9.0/Native > Method) > > > at > > > java.lang.ClassLoader.defineClass(java.base@9.0 > /ClassLoader.java:854) > > > at > > > java.security.SecureClassLoader.defineClass(java.base@9.0 > /SecureClassLoader.java:152) > > > at > > > java.net.URLClassLoader.defineClass(java.base@9.0 > /URLClassLoader.java:462) > > > at > > > java.net.URLClassLoader.access$100(java.base@9.0 > /URLClassLoader.java:75) > > > at > > > java.net.URLClassLoader$1.run(java.base@9.0 > /URLClassLoader.java:370) > > > at > > > java.net.URLClassLoader$1.run(java.base@9.0 > /URLClassLoader.java:364) > > > at java.security.AccessController.doPrivileged(java.base@9.0 > /Native > > > Method) > > > at > > > java.net.URLClassLoader.findClass(java.base@9.0 > /URLClassLoader.java:363) > > > at java.lang.ClassLoader.loadClass(java.base@9.0 > /ClassLoader.java:440) > > > at java.lang.ClassLoader.loadClass(java.base@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 >
