jake -> jdk9/dev

Stephen Felts stephen.felts at oracle.com
Mon Apr 3 20:54:35 UTC 2017

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.





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.








More information about the jigsaw-dev mailing list