Closed FroMage closed 10 years ago
It seems to be something inside the class loading itself, because the .car contains the correct class and the runtime is trying to load it but the classloader returns a ClassNotFoundException
. Possibly there's something going on with code that assumes anything that starts with "java" to be special.
For the moment that's all I can see without downloading the JBoss source code and debugging further.
Yes, jboss modules has special case for java.
apparently. No time to fix for 1.0
assumes anything that starts with "java" to be special.
Yes, you're not allowed to have any package named java.* ever! (per spec!)
To @alesj: You said "per spec", which spec is that? From JBoss Modules? To the rest: And what do we do about it? Treat "java" as a keyword so we quote it?
@quintesse Plain Java spec -- search for "observability". As it would mean that this module would have to be visible from every where, which is definitely not the case, hence it would break spec defined behaviour.
Consequently, should the spec forbid declaring any module starting with java
then? @gavinking?
It does, doesn't it?
Oh no, it prohibits java.
not javaxxx
.
It does? javaxxx
is fine BTW, it's just anything starting with java.
or simply java
that is an issue. I suppose we can close that issue if our typechecker already rejects this. I suppose this was added after this issue was reported then?
No, a module called java
compiles just fine.
Spec §9.3.1.
It shouldn't -- as it won't work during Runtime; Modules do follow the spec. ;-)
And 7.4.3 in Java spec.
And trying to run it in a flat classpath to circumvent JBoss Modules gives:
$ java -cp `ceylon classpath java/1.0.0` java.run_
Exception in thread "main" java.lang.SecurityException: Prohibited package name: java
at java.lang.ClassLoader.preDefineClass(ClassLoader.java:658)
at java.lang.ClassLoader.defineClass(ClassLoader.java:794)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:482)
It shouldn't -- as it won't work during Runtime; Modules do follow the spec. ;-)
Hrm, that might be a bit heavy-handed. It's only a warning in the typechecker and IDE. It's not an actual error.
via @dmlloyd:
the EULA says: C. Java Technology Restrictions. You may not create, modify, or change the behavior of, or authorize your licensees to create, modify, or change the behavior of, classes, interfaces, or subpackages that are in any way identified as "java", "javax", "sun" or similar convention as specified by Oracle in any naming convention designation.
@gavinking: should you turn this into an error then?
Um, fine, ok, open an issue against ceylon-spec
and close this one.
Done, closing then.
Apparently it doesn't work. Calling it
javaa
works.