jake -> jdk9/dev

Kevin Rushforth kevin.rushforth at oracle.com
Mon Apr 3 21:09:02 UTC 2017


I note that Phil pushed the changes to OpenJFX in time for build 164 so 
that problem, at least, is resolved.

-- Kevin


Stephen Felts wrote:
> 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
>
>  
>
>  
>   


More information about the jigsaw-dev mailing list