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:pbened...@apache.org]
Sent: Wednesday, December 02, 2015 9:53 AM
To: Remi Forax
Cc: jigsaw-dev@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 <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
