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

[Paul Benedict]

Of course, Stephen. Look, the current manifest has a Class-Path entry to
add classes in other JAR files to the classpath when running an applet or
application. It's pretty close to what's going on with the Module
Descriptor. Developers are simply listing out modules instead of jars. Yes,
there is some additional qualifying information but nothing that requires
language support. I agree with David the current push to make this a
language feature is self-justifying. It's cool but totally unnecessary.

Now let's relate this to people's concerns about annotation scanning. One
solution being floated is indexing the module with found annotations. So
let's pretend that during compiling, tools (like Maven) are going to have
to read the Module Descriptor (in binary) and augment it (in binary) with
the scan results. All that information is locked in binary format but it
should be human readable. I should be able to go in myself and do this with
a text editor. I shouldn't have to compile a file anymore than I have to
compile my MANIFEST.MF or web.xml or application.xml. This is all about
configuration; not executable code.

Cheers,
Paul

On Wed, Dec 2, 2015 at 10:16 AM, Stephen Felts <stephen.felts at oracle.com>
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
> >
>