The jlr.Module -> jl.Module can cause some other problems.
It breaks source code compatibility that is totally unrelated to JDK9 (code
that has been compiling for 20 years). Unfortunately, the name Module is
pretty popular – I saw 7 occurrences of the following.
$ cat Test.java
import tmp.*;
public class Test extends Module {
}
$ cat tmp/Module.java
package tmp;
public class Module {
}
$ javac Test.java tmp/Module.java
Test.java:3: error: reference to Module is ambiguous public class Test extends
Module {
^
both class tmp.Module in tmp and class java.lang.Module in java.lang match
1 error
In addition to OpenFX, this also breaks standalone jaxws-rt.
META-INF/versions/9/com/sun/xml/ws/api/server/SDDocumentSource.class
META-INF/versions/9/com/sun/xml/ws/util/HandlerAnnotationProcessor.class
If you need to handle the old and new classes, I used something like the
following where “module” used to be “Module” instead of “Object”.
Object module = resolvingClass.getModule();
if (module != null) {
Class c = null;
try {
c = Class.forName("java.lang.reflect.Module");
} catch (Exception ignore) {
try {
c = Class.forName("java.lang.Module");
} catch (Exception ignore2) {
}
}
if (c == null) {
throw new IOException("Can't find Module class");
}
try {
Method m = c.getMethod("getResourceAsStream",
String.class);
InputStream stream = (InputStream)m.invoke(module, path);
if (stream != null) {
return stream;
}
} catch (Exception e) {
}
Throw new Exception(“you lose”);
-----Original Message-----
From: Alan Bateman
Sent: Monday, April 3, 2017 3:01 PM
To: jigsaw-dev
Subject: jake -> jdk9/dev
We have a number of changes accumulated in the jake forest that we need to
bring to jdk9/dev soon.
The bulk of changes relate to #MoveModuleAndLayerClasses [1] and so a bit
disruptive for those using the JDK 9 EA builds and the new APIs.
The revised proposed for #VersionsInModuleNames reverts a previous proposal so
that digits are now preserved at the end of module names.
We also have a minor update to JVM TI to java.lang.instrument to allow for
unmodifable modules. This is to fix the inconsistency with unmodifable classes.
It is independent of the ongoing discussion about java agents and no impact to
agents using the draft APIs.
That's all for now. The highest priority is to get the jlr.Module -> jl.Module
move into jdk9/dev. As I mentioned in a mail last week, this requires a bit of
coordination to meet up with the changes coming from the OpenJFX project.
-Alan
[1]
http://openjdk.java.net/projects/jigsaw/spec/issues/#MoveModuleAndLayerClasses
