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.ll...@redhat.com> wrote: > On 12/02/2015 09:05 AM, Remi Forax wrote: > >> >> >> ----- Mail original ----- >> >>> De: "David M. Lloyd" <david.ll...@redhat.com> >>> À: jigsaw-dev@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.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. >>>> >>> >>> 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
