From alan.bateman at oracle.com Sat Jul 1 07:26:13 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 01 Jul 2017 07:26:13 +0000 Subject: hg: jigsaw/jake/corba: 2 new changesets Message-ID: <201707010726.v617QERb021294@aojmv0008.oracle.com> Changeset: 76cebcdca958 Author: lana Date: 2017-06-29 17:26 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/76cebcdca958 Added tag jdk-9+176 for changeset 40fb9f229471 ! .hgtags Changeset: ace27af8942f Author: alanb Date: 2017-07-01 07:58 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/ace27af8942f Merge ! .hgtags From alan.bateman at oracle.com Sat Jul 1 07:26:14 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 01 Jul 2017 07:26:14 +0000 Subject: hg: jigsaw/jake/jaxp: 2 new changesets Message-ID: <201707010726.v617QEMf021306@aojmv0008.oracle.com> Changeset: 332ad9f92632 Author: lana Date: 2017-06-29 17:26 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/332ad9f92632 Added tag jdk-9+176 for changeset 38cf34e23280 ! .hgtags Changeset: 712c8f06dd80 Author: alanb Date: 2017-07-01 07:58 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/712c8f06dd80 Merge ! .hgtags From alan.bateman at oracle.com Sat Jul 1 07:26:14 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 01 Jul 2017 07:26:14 +0000 Subject: hg: jigsaw/jake/jaxws: 2 new changesets Message-ID: <201707010726.v617QEXI021311@aojmv0008.oracle.com> Changeset: 880541212285 Author: lana Date: 2017-06-29 17:26 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/880541212285 Added tag jdk-9+176 for changeset ea819b6009d3 ! .hgtags Changeset: 7c7fed544711 Author: alanb Date: 2017-07-01 07:58 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/7c7fed544711 Merge ! .hgtags From alan.bateman at oracle.com Sat Jul 1 07:26:16 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 01 Jul 2017 07:26:16 +0000 Subject: hg: jigsaw/jake/langtools: 3 new changesets Message-ID: <201707010726.v617QGaR021372@aojmv0008.oracle.com> Changeset: 0d0ac75b0f6c Author: jjg Date: 2017-06-26 18:48 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/0d0ac75b0f6c 8182736: javadoc generates bad names and broken module graph links Reviewed-by: jjg, bpatel, darcy, ksrini Contributed-by: bhavesh.patel at oracle.com, jonathan.gibbons at oracle.com ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ModuleSummaryBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/IndexBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java ! test/jdk/javadoc/doclet/testModules/TestModules.java + test/jdk/javadoc/doclet/testModules/test.moduleFullName/module-info.java + test/jdk/javadoc/doclet/testModules/test.moduleFullName/testpkgmdlfullname/TestClassInTestModuleFullName.java Changeset: 552f8fdfba55 Author: lana Date: 2017-06-29 17:26 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/552f8fdfba55 Added tag jdk-9+176 for changeset 0d0ac75b0f6c ! .hgtags Changeset: 1dce953430d8 Author: alanb Date: 2017-07-01 07:57 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/1dce953430d8 Merge ! .hgtags ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ModuleSummaryBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java ! test/jdk/javadoc/doclet/testModules/TestModules.java From alan.bateman at oracle.com Sat Jul 1 07:26:13 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 01 Jul 2017 07:26:13 +0000 Subject: hg: jigsaw/jake: 4 new changesets Message-ID: <201707010726.v617QERr021304@aojmv0008.oracle.com> Changeset: 99918cff846d Author: ihse Date: 2017-06-21 12:51 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/99918cff846d 8179892: Update build documentation for JDK 9 Reviewed-by: erikj ! common/doc/building.html ! common/doc/building.md ! common/doc/testing.html ! make/Init.gmk ! make/UpdateBuildDocs.gmk Changeset: 84777531d994 Author: lana Date: 2017-06-22 19:23 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/84777531d994 Merge Changeset: 85e6cb013b98 Author: lana Date: 2017-06-29 17:26 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/85e6cb013b98 Added tag jdk-9+176 for changeset 84777531d994 ! .hgtags Changeset: 59950a133c54 Author: alanb Date: 2017-07-01 07:56 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/59950a133c54 Merge ! .hgtags From alan.bateman at oracle.com Sat Jul 1 07:26:17 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 01 Jul 2017 07:26:17 +0000 Subject: hg: jigsaw/jake/nashorn: 2 new changesets Message-ID: <201707010726.v617QHUe021385@aojmv0008.oracle.com> Changeset: b25986e36b28 Author: lana Date: 2017-06-29 17:26 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/b25986e36b28 Added tag jdk-9+176 for changeset 3c6fbdf6e785 ! .hgtags Changeset: e93bc38cf3f3 Author: alanb Date: 2017-07-01 07:58 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/e93bc38cf3f3 Merge ! .hgtags From alan.bateman at oracle.com Sat Jul 1 07:26:19 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 01 Jul 2017 07:26:19 +0000 Subject: hg: jigsaw/jake/hotspot: 3 new changesets Message-ID: <201707010726.v617QJLf021400@aojmv0008.oracle.com> Changeset: 2ab74e5dbdc2 Author: roland Date: 2017-06-23 09:33 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2ab74e5dbdc2 8181742: Load that bypasses arraycopy has wrong memory state Summary: Set load memory edge to the memory state right before the arraycopy. Reviewed-by: kvn, thartmann ! src/share/vm/opto/arraycopynode.cpp ! src/share/vm/opto/arraycopynode.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp + test/compiler/arraycopy/TestLoadBypassACWithWrongMem.java Changeset: 1ca8f038fceb Author: lana Date: 2017-06-29 17:26 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1ca8f038fceb Added tag jdk-9+176 for changeset 2ab74e5dbdc2 ! .hgtags Changeset: 354453651ff7 Author: alanb Date: 2017-07-01 07:57 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/354453651ff7 Merge ! .hgtags ! src/share/vm/opto/library_call.cpp From alan.bateman at oracle.com Sat Jul 1 07:26:19 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 01 Jul 2017 07:26:19 +0000 Subject: hg: jigsaw/jake/jdk: 4 new changesets Message-ID: <201707010726.v617QJ5Z021406@aojmv0008.oracle.com> Changeset: 2425838cfb5e Author: mullan Date: 2017-06-23 14:32 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2425838cfb5e 8182652: RuntimePermission("usePolicy") is not a Java SE permission Reviewed-by: mchung ! src/java.base/share/classes/java/lang/RuntimePermission.java Changeset: 9f27d513658d Author: jjg Date: 2017-06-26 18:48 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9f27d513658d 8182736: javadoc generates bad names and broken module graph links Reviewed-by: jjg, bpatel, darcy, ksrini Contributed-by: bhavesh.patel at oracle.com, jonathan.gibbons at oracle.com ! make/src/classes/build/tools/taglet/ModuleGraph.java Changeset: 473db5c4c2c9 Author: lana Date: 2017-06-29 17:26 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/473db5c4c2c9 Added tag jdk-9+176 for changeset 9f27d513658d ! .hgtags Changeset: f140e400a7f0 Author: alanb Date: 2017-07-01 07:57 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f140e400a7f0 Merge ! .hgtags ! src/java.base/share/classes/java/lang/RuntimePermission.java From peter.levart at gmail.com Sat Jul 1 09:09:46 2017 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 1 Jul 2017 11:09:46 +0200 Subject: Exporting a package with no Java sources In-Reply-To: References: Message-ID: Hi Alexander, Have you tried to put a package-info.java into the exported package? It might work. Regards, Peter On Jun 30, 2017 6:42 PM, "Alexander Udalov" wrote: > I'm trying to figure out how to compile a mixed-language (in this > case, Java + Kotlin) JVM module and having a problem in case the > module tries to export a package without any .java sources in it. The > javac error I get is: > > src/module-info.java:2: error: package is empty or does not exist: foo > exports foo; > ^ > > Now, through experiments, I found out that it's actually possible to > workaround this error by > 1) always compiling non-.java sources first, and > 2) compiling .java sources to the same directory where non-.java > sources are compiled to on step 1. > > However, with Gradle deprecating single-output directory builds for > projects using multiple JVM languages [1], this workaround is not > always going to be possible. > Is there some other way to suggest to javac that .class files in a > particular location on the disk are a part of the same module, so that > it would be possible to export the package? > If there isn't, would it make sense to relax the severity of this > compiler message to a warning? > > Thank you in advance! > > Alexander > > [1] https://docs.gradle.org/4.0/release-notes.html#multiple- > class-directories-for-a-single-source-set > From markt at apache.org Sat Jul 1 09:18:20 2017 From: markt at apache.org (Mark Thomas) Date: Sat, 1 Jul 2017 10:18:20 +0100 Subject: Cleanly starting apps on Java 9 and earlier Message-ID: Hi, Apache Tomcat needs to add the following options when running on Java 9: --add-modules=java.se.ee --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED The first is because it depends on javax.xml.ws.WebServiceRef and javax.xml.ws.WebServiceRefs. We could work around this by shipping our own implementations but that sort of duplication should not be necessary. The second and third are required by Tomcat's memory leak detection and prevention code. In an ideal world, web applications wouldn't have memory leaks. Unfortunately, the world isn't ideal and the memory leak detection and prevention code has proven immensely valuable over the years. The problem we have is that Tomcat needs to run on Java 9 though 6. If the above options aren't provided, Java 6 through 8 are fine but on Java 9 at best the users see a bunch of errors and at worst Tomcat won't start. If the above options are included, Java 9 is fine but then Tomcat fails to start on Java 6 though 8. What is the recommended approach for applications that need to use one or more of the options above and need to start cleanly on multiple Java versions including 9 and earlier using a single, common start-up script? To date, Tomcat has always been Java version agnostic as long as at least the minimum Java version as specified by the Java EE spec has been used. We really don't want to have to change that. Suggestions welcome. Mark From Alan.Bateman at oracle.com Sat Jul 1 09:53:25 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 1 Jul 2017 10:53:25 +0100 Subject: Cleanly starting apps on Java 9 and earlier In-Reply-To: References: Message-ID: <3144a7a4-28d2-a9da-2fc5-dcaaafc6e0c0@oracle.com> On 01/07/2017 10:18, Mark Thomas wrote: > Hi, > > Apache Tomcat needs to add the following options when running on Java 9: > > --add-modules=java.se.ee > --add-opens=java.base/java.lang=ALL-UNNAMED > --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED > > The first is because it depends on javax.xml.ws.WebServiceRef and > javax.xml.ws.WebServiceRefs. > We could work around this by shipping our own implementations but that > sort of duplication should not be necessary. The java.xml.ws module is deprecated for removal (along with the other modules shared with Java EE) so expect these modules to not be included in the JDK some day (exactly when is TBD as it depends on when Java SE drops them). In the short term then `--add-modules java.se.ee` will resolve the EE modules included in the JDK but it may bring complications, it all depends on whether you have the EE java.transaction module or JAR files with annotations in the javax.annotation package in your environment. An important page for the JDK 9 docs is a page with instructions and deployments options for those using these APIs. > > The second and third are required by Tomcat's memory leak detection and > prevention code. In an ideal world, web applications wouldn't have > memory leaks. Unfortunately, the world isn't ideal and the memory leak > detection and prevention code has proven immensely valuable over the years. Both of these packages are open since jdk-9+175 so the hacks to null fields will continue to work. That said, I thought the issue with TCCL in sun.rmi.transport.GC was fixed via JDK-8157570. Have you tested that? > The problem we have is that Tomcat needs to run on Java 9 though 6. If > the above options aren't provided, Java 6 through 8 are fine but on Java > 9 at best the users see a bunch of errors and at worst Tomcat won't > start. If the above options are included, Java 9 is fine but then Tomcat > fails to start on Java 6 though 8. > The launch script could examine the JAVA_VERSION property in the `release` file. Another approach is to set the JDK_JAVA_OPTIONS environment variable as that is new 9 and so will be ignored by older releases. There is also -XX:+IgnoreUnrecognizedVMOptions to ignore unrecognized options. -Alan From Alan.Bateman at oracle.com Sat Jul 1 10:08:10 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 1 Jul 2017 11:08:10 +0100 Subject: Exporting a package with no Java sources In-Reply-To: References: Message-ID: On 01/07/2017 10:09, Peter Levart wrote: > Hi Alexander, > > Have you tried to put a package-info.java into the exported package? It > might work. > I don't think so, but a dummy class/interface will do (it doesn't have to be public). There is a lengthy discussion on this topic in JIRA from 2016 that would be useful to link to (but I can't find it just now because JIRA is down for maintenance). -Alan From eolivelli at gmail.com Sat Jul 1 12:15:29 2017 From: eolivelli at gmail.com (Enrico Olivelli) Date: Sat, 01 Jul 2017 12:15:29 +0000 Subject: Cleanly starting apps on Java 9 and earlier In-Reply-To: <3144a7a4-28d2-a9da-2fc5-dcaaafc6e0c0@oracle.com> References: <3144a7a4-28d2-a9da-2fc5-dcaaafc6e0c0@oracle.com> Message-ID: Il sab 1 lug 2017, 11:53 Alan Bateman ha scritto: > On 01/07/2017 10:18, Mark Thomas wrote: > > Hi, > > > > Apache Tomcat needs to add the following options when running on Java 9: > > > > --add-modules=java.se.ee > > --add-opens=java.base/java.lang=ALL-UNNAMED > > --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED > > > > The first is because it depends on javax.xml.ws.WebServiceRef and > > javax.xml.ws.WebServiceRefs. > > We could work around this by shipping our own implementations but that > > sort of duplication should not be necessary. > The java.xml.ws module is deprecated for removal (along with the other > modules shared with Java EE) so expect these modules to not be included > in the JDK some day (exactly when is TBD as it depends on when Java SE > drops them). > > In the short term then `--add-modules java.se.ee` will resolve the EE > modules included in the JDK but it may bring complications, it all > depends on whether you have the EE java.transaction module or JAR files > with annotations in the javax.annotation package in your environment. An > important page for the JDK 9 docs is a page with instructions and > deployments options for those using these APIs. > Alan, Can you give some poonters to this page? Thank you Enrico Olivelli > > > > > > The second and third are required by Tomcat's memory leak detection and > > prevention code. In an ideal world, web applications wouldn't have > > memory leaks. Unfortunately, the world isn't ideal and the memory leak > > detection and prevention code has proven immensely valuable over the > years. > Both of these packages are open since jdk-9+175 so the hacks to null > fields will continue to work. > > That said, I thought the issue with TCCL in sun.rmi.transport.GC was > fixed via JDK-8157570. Have you tested that? > > > > The problem we have is that Tomcat needs to run on Java 9 though 6. If > > the above options aren't provided, Java 6 through 8 are fine but on Java > > 9 at best the users see a bunch of errors and at worst Tomcat won't > > start. If the above options are included, Java 9 is fine but then Tomcat > > fails to start on Java 6 though 8. > > > The launch script could examine the JAVA_VERSION property in the > `release` file. Another approach is to set the JDK_JAVA_OPTIONS > environment variable as that is new 9 and so will be ignored by older > releases. There is also -XX:+IgnoreUnrecognizedVMOptions to ignore > unrecognized options. > > -Alan > -- -- Enrico Olivelli From kevin.rushforth at oracle.com Sat Jul 1 13:47:46 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 01 Jul 2017 06:47:46 -0700 Subject: gradle 3.x runs without setting _JAVA_OPTIONS on jdk-9+175 (and later) Message-ID: <5957A802.4000209@oracle.com> Now that '--illegal-access=permit' is the default for JDK 9 (as of build 175) I can confirm that gradle 3.x works without needing to specify a bunch of '--add-opens' options. I was able to do an entire build / test of JavaFX without setting _JAVA_OPTIONS at all. I hope this will give the groovy and gradle teams the time they need to fix all remaining issues. -- Kevin From stephen.felts at oracle.com Sat Jul 1 13:57:58 2017 From: stephen.felts at oracle.com (Stephen Felts) Date: Sat, 1 Jul 2017 06:57:58 -0700 (PDT) Subject: Cleanly starting apps on Java 9 and earlier In-Reply-To: <3144a7a4-28d2-a9da-2fc5-dcaaafc6e0c0@oracle.com> References: <3144a7a4-28d2-a9da-2fc5-dcaaafc6e0c0@oracle.com> Message-ID: <6ae6b0d2-6b87-4a06-98a8-6f298fbc530d@default> IMO: 1. You should avoid `--add-modules java.se.ee' unless you need all of those modules. You should bring in only those modules that you need. The choices are java.activation, java.corba, java.transaction, java.xml.bind, java.xml.ws, java.xml.ws.annotation. So use --add-modules java.xml.ws. 2. You can't use -XX:+IgnoreUnrecognizedVMOptions as a general solution because that isn't available in JDK6 JRockit for example. 3. Setting JDK_JAVA_OPTIONS is good because only JDK9 recognizes it and it is inherited by all nested invocations (unless there is an exec that excludes the environment). You might want to use export JDK_JAVA_OPTIONS="-XX:+IgnoreUnrecognizedVMOptions --add-modules java.xml.ws" 4. --add-opens is not needed starting in b175 so require that as a base. It will still be noisy (a 3-line WARNING will be printed to the standard error). -----Original Message----- From: Alan Bateman Sent: Saturday, July 1, 2017 5:53 AM To: Mark Thomas; jigsaw-dev at openjdk.java.net Subject: Re: Cleanly starting apps on Java 9 and earlier On 01/07/2017 10:18, Mark Thomas wrote: > Hi, > > Apache Tomcat needs to add the following options when running on Java 9: > > --add-modules=java.se.ee > --add-opens=java.base/java.lang=ALL-UNNAMED > --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED > > The first is because it depends on javax.xml.ws.WebServiceRef and > javax.xml.ws.WebServiceRefs. > We could work around this by shipping our own implementations but that > sort of duplication should not be necessary. The java.xml.ws module is deprecated for removal (along with the other modules shared with Java EE) so expect these modules to not be included in the JDK some day (exactly when is TBD as it depends on when Java SE drops them). In the short term then `--add-modules java.se.ee` will resolve the EE modules included in the JDK but it may bring complications, it all depends on whether you have the EE java.transaction module or JAR files with annotations in the javax.annotation package in your environment. An important page for the JDK 9 docs is a page with instructions and deployments options for those using these APIs. > > The second and third are required by Tomcat's memory leak detection > and prevention code. In an ideal world, web applications wouldn't have > memory leaks. Unfortunately, the world isn't ideal and the memory leak > detection and prevention code has proven immensely valuable over the years. Both of these packages are open since jdk-9+175 so the hacks to null fields will continue to work. That said, I thought the issue with TCCL in sun.rmi.transport.GC was fixed via JDK-8157570. Have you tested that? > The problem we have is that Tomcat needs to run on Java 9 though 6. If > the above options aren't provided, Java 6 through 8 are fine but on Java > 9 at best the users see a bunch of errors and at worst Tomcat won't > start. If the above options are included, Java 9 is fine but then Tomcat > fails to start on Java 6 though 8. > The launch script could examine the JAVA_VERSION property in the `release` file. Another approach is to set the JDK_JAVA_OPTIONS environment variable as that is new 9 and so will be ignored by older releases. There is also -XX:+IgnoreUnrecognizedVMOptions to ignore unrecognized options. -Alan From stephan.herrmann at berlin.de Sat Jul 1 15:08:20 2017 From: stephan.herrmann at berlin.de (Stephan Herrmann) Date: Sat, 1 Jul 2017 17:08:20 +0200 Subject: javap cannot read module-info.class Message-ID: compile an arbitrary module-info.java and then: $ javap module-info.class Error: error while reading constant pool for /tmp/bin/module-info.class: unexpected tag at #5: 19 From tweaking the Eclipse compiler it seems that javap is expecting a CONSTANT_Utf8_info, where according to JVMS 4.7.25 a CONSTANT_Module_info is required. JVMS and javac agree, so javap is the odd man out. Stephan PS: build is 9+175 From forax at univ-mlv.fr Sat Jul 1 16:01:26 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 1 Jul 2017 18:01:26 +0200 (CEST) Subject: javap cannot read module-info.class In-Reply-To: References: Message-ID: <1044346912.3180776.1498924886276.JavaMail.zimbra@u-pem.fr> Hi Stephan, there is something wrong from your side, it works for me :) /usr/jdk/jdk-9-b175/bin/javap --module-path target/main/exploded/ --module fr.umlv.asm.test module-info Compiled from "module-info.java" module fr.umlv.asm.test { requires java.base; requires org.objectweb.asm.all.debug; exports fr.umlv.asm.test; } /usr/jdk/jdk-9-b175/bin/javap -m java.base module-info Compiled from "module-info.java" module java.base at 9 { exports sun.reflect.generics.reflectiveObjects to java.desktop; exports java.util; exports java.lang.ref; exports jdk.internal.misc to java.rmi, java.sql, jdk.jshell, ... cheers, R?mi ----- Mail original ----- > De: "Stephan Herrmann" > ?: jigsaw-dev at openjdk.java.net > Envoy?: Samedi 1 Juillet 2017 17:08:20 > Objet: javap cannot read module-info.class > compile an arbitrary module-info.java and then: > > $ javap module-info.class > Error: error while reading constant pool for /tmp/bin/module-info.class: > unexpected tag at #5: 19 > > From tweaking the Eclipse compiler it seems that javap is expecting a > CONSTANT_Utf8_info, > where according to JVMS 4.7.25 a CONSTANT_Module_info is required. > > JVMS and javac agree, so javap is the odd man out. > > Stephan > > PS: build is 9+175 From Alan.Bateman at oracle.com Sat Jul 1 16:36:30 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 1 Jul 2017 17:36:30 +0100 Subject: javap cannot read module-info.class In-Reply-To: References: Message-ID: On 01/07/2017 16:08, Stephan Herrmann wrote: > compile an arbitrary module-info.java and then: > > $ javap module-info.class > Error: error while reading constant pool for > /tmp/bin/module-info.class: unexpected tag at #5: 19 > > From tweaking the Eclipse compiler it seems that javap is expecting a > CONSTANT_Utf8_info, > where according to JVMS 4.7.25 a CONSTANT_Module_info is required. It would be interesting to see if the runtime can read this, does "java -p /tmp/bin --list-modules" list the module? -Alan From Alan.Bateman at oracle.com Sat Jul 1 16:50:12 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 1 Jul 2017 17:50:12 +0100 Subject: Cleanly starting apps on Java 9 and earlier In-Reply-To: References: <3144a7a4-28d2-a9da-2fc5-dcaaafc6e0c0@oracle.com> Message-ID: On 01/07/2017 13:15, Enrico Olivelli wrote: > : > > Alan, > Can you give some poonters to this page? > Thank you > There isn't a page to point at yet, mostly we are waiting for javaee.github.io to be updated to list stable Maven coordinates or download links for each of the standalone technologies. -Alan. From stephan.herrmann at berlin.de Sat Jul 1 17:12:00 2017 From: stephan.herrmann at berlin.de (Stephan Herrmann) Date: Sat, 1 Jul 2017 19:12:00 +0200 Subject: javap cannot read module-info.class In-Reply-To: <1044346912.3180776.1498924886276.JavaMail.zimbra@u-pem.fr> References: <1044346912.3180776.1498924886276.JavaMail.zimbra@u-pem.fr> Message-ID: <7883e3cf-532d-fb75-fdec-71de52bbad48@berlin.de> One working example certainly doesn't prove absence of a bug :) But yes, I must have gotten my bash aliases wrong, the reported error is only printed by the Java 8 version of javap, in 9 it works as expected. One small bit remains: If I let our compiler emit CONSTANT_Utf8_info for the module name without a wrapper CONSTANT_Module_info javap does happily accept this. "java --list-modules" rejects this, though. other than that: sorry for the noise, Stephan On 01.07.2017 18:01, Remi Forax wrote: > Hi Stephan, > there is something wrong from your side, it works for me :) > > /usr/jdk/jdk-9-b175/bin/javap --module-path target/main/exploded/ --module fr.umlv.asm.test module-info > Compiled from "module-info.java" > module fr.umlv.asm.test { > requires java.base; > requires org.objectweb.asm.all.debug; > exports fr.umlv.asm.test; > } > > /usr/jdk/jdk-9-b175/bin/javap -m java.base module-info > Compiled from "module-info.java" > module java.base at 9 { > exports sun.reflect.generics.reflectiveObjects to > java.desktop; > exports java.util; > exports java.lang.ref; > exports jdk.internal.misc to > java.rmi, > java.sql, > jdk.jshell, > ... > > cheers, > R?mi > > ----- Mail original ----- >> De: "Stephan Herrmann" >> ?: jigsaw-dev at openjdk.java.net >> Envoy?: Samedi 1 Juillet 2017 17:08:20 >> Objet: javap cannot read module-info.class > >> compile an arbitrary module-info.java and then: >> >> $ javap module-info.class >> Error: error while reading constant pool for /tmp/bin/module-info.class: >> unexpected tag at #5: 19 >> >> From tweaking the Eclipse compiler it seems that javap is expecting a >> CONSTANT_Utf8_info, >> where according to JVMS 4.7.25 a CONSTANT_Module_info is required. >> >> JVMS and javac agree, so javap is the odd man out. >> >> Stephan >> >> PS: build is 9+175 From jonathan.gibbons at oracle.com Sat Jul 1 20:53:21 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Sat, 1 Jul 2017 13:53:21 -0700 Subject: Exporting a package with no Java sources In-Reply-To: References: Message-ID: <5574e8de-a165-8984-cb9b-939bf6dda8cb@oracle.com> Right now, javac only looks in one location (i.e. directory + its subdirectories) for the compiled classes for a module. It is too late to change this for JDK 9, and even if we could, I think we are already pushing the limits of what can be specified on the command line to configure the different paths for all the modules involved in the compilation. Converting the error to a warning (as was suggested in the original post in this thread) would not address the case where the Java source code needs to refer to types declared in class files generated from non-Java sources. -- Jon On 7/1/17 3:08 AM, Alan Bateman wrote: > On 01/07/2017 10:09, Peter Levart wrote: >> Hi Alexander, >> >> Have you tried to put a package-info.java into the exported package? It >> might work. >> > I don't think so, but a dummy class/interface will do (it doesn't have > to be public). There is a lengthy discussion on this topic in JIRA > from 2016 that would be useful to link to (but I can't find it just > now because JIRA is down for maintenance). > > -Alan From cay.horstmann at sjsu.edu Sun Jul 2 10:16:31 2017 From: cay.horstmann at sjsu.edu (Cay Horstmann) Date: Sun, 2 Jul 2017 12:16:31 +0200 Subject: Spec confusion about open modules Message-ID: In ?7.7, the JLS draft from 2017-06-26 states: An open module, with the open modifier ... grants access at run time to types in all its packages, as if all packages had been exported. ... Distinct from access at compile time and access at run time, the Java SE Platform provides reflective access via the Core Reflection API (?1.4)... So, here is my question. I had thought the purpose of open modules and opened packages was to be able to access non-public members at runtime through reflection. But it appears from the workding of the JLS as if other runtime access would also be possible. Like what? I mean, if I don't have compile-time access, what runtime access do I have other than through reflection? Synthesized byte codes? Method handles? Or did I overlook something really obvious here? Thanks, Cay -- Cay S. Horstmann | http://horstmann.com | mailto:cay at horstmann.com From Alan.Bateman at oracle.com Sun Jul 2 20:36:53 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 2 Jul 2017 21:36:53 +0100 Subject: Spec confusion about open modules In-Reply-To: References: Message-ID: <70ec848f-cc04-5905-d8da-0c528b7a6ad4@oracle.com> On 02/07/2017 11:16, Cay Horstmann wrote: > In ?7.7, the JLS draft from 2017-06-26 states: > > An open module, with the open modifier ... grants access at run time to > types in all its packages, as if all packages had been exported. > ... > Distinct from access at compile time and access at run time, the Java > SE Platform provides reflective access via the Core Reflection API > (?1.4)... > > So, here is my question. I had thought the purpose of open modules and > opened packages was to be able to access non-public members at runtime > through reflection. > > But it appears from the workding of the JLS as if other runtime access > would also be possible. Like what? I mean, if I don't have > compile-time access, what runtime access do I have other than through > reflection? Synthesized byte codes? Method handles? Or did I overlook > something really obvious here? As it says, an open module grants access at run time to types in all of the module's packages, as if all packages are exported. This means bytecode or reflection can be used to access the public classes / public members in all packages. In addition, the reflection APIs (with setAccessible or MethodHandles.privateLookupIn) allow for "deep reflection" so you can reflect on all members of all classes in all packages. -Alan From markt at apache.org Mon Jul 3 09:35:50 2017 From: markt at apache.org (Mark Thomas) Date: Mon, 3 Jul 2017 10:35:50 +0100 Subject: Cleanly starting apps on Java 9 and earlier In-Reply-To: <3144a7a4-28d2-a9da-2fc5-dcaaafc6e0c0@oracle.com> References: <3144a7a4-28d2-a9da-2fc5-dcaaafc6e0c0@oracle.com> Message-ID: <4b126529-97bf-79bf-cd3b-5dfd072847c0@apache.org> On 01/07/17 10:53, Alan Bateman wrote: > On 01/07/2017 10:18, Mark Thomas wrote: >> Hi, >> >> Apache Tomcat needs to add the following options when running on Java 9: >> >> --add-modules=java.se.ee >> --add-opens=java.base/java.lang=ALL-UNNAMED >> --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED >> >> The first is because it depends on javax.xml.ws.WebServiceRef and >> javax.xml.ws.WebServiceRefs. >> We could work around this by shipping our own implementations but that >> sort of duplication should not be necessary. > The java.xml.ws module is deprecated for removal (along with the other > modules shared with Java EE) so expect these modules to not be included > in the JDK some day (exactly when is TBD as it depends on when Java SE > drops them). > > In the short term then `--add-modules java.se.ee` will resolve the EE > modules included in the JDK but it may bring complications, it all > depends on whether you have the EE java.transaction module or JAR files > with annotations in the javax.annotation package in your environment. An > important page for the JDK 9 docs is a page with instructions and > deployments options for those using these APIs. Alan, Thanks for the info. Tomcat only recently dropped its own implementation of those classes so the simplest thing to do is reinstate them. >> The second and third are required by Tomcat's memory leak detection and >> prevention code. In an ideal world, web applications wouldn't have >> memory leaks. Unfortunately, the world isn't ideal and the memory leak >> detection and prevention code has proven immensely valuable over the >> years. > Both of these packages are open since jdk-9+175 so the hacks to null > fields will continue to work. Yep. Partly I want to avoid the warnings entirely - for some users start-up warnings are errors that MUST be resolved. > That said, I thought the issue with TCCL in sun.rmi.transport.GC was > fixed via JDK-8157570. Have you tested that? Yes that bug is fixed. The RMI leaks in this case are application bugs, not JRE bugs. They are typically caused by applications registering stuff for RMI and then failing to de-register it. Tomcat needs to poke around in the internals to find out if such a memory leak is present. >> The problem we have is that Tomcat needs to run on Java 9 though 6. If >> the above options aren't provided, Java 6 through 8 are fine but on Java >> 9 at best the users see a bunch of errors and at worst Tomcat won't >> start. If the above options are included, Java 9 is fine but then Tomcat >> fails to start on Java 6 though 8. >> > The launch script could examine the JAVA_VERSION property in the > `release` file. Another approach is to set the JDK_JAVA_OPTIONS > environment variable as that is new 9 and so will be ignored by older > releases. There is also -XX:+IgnoreUnrecognizedVMOptions to ignore > unrecognized options. Excellent. JDK_JAVA_OPTIONS is exactly what I need. Many thanks for the response. Kind regards, Mark From markt at apache.org Mon Jul 3 09:39:28 2017 From: markt at apache.org (Mark Thomas) Date: Mon, 3 Jul 2017 10:39:28 +0100 Subject: Cleanly starting apps on Java 9 and earlier In-Reply-To: <6ae6b0d2-6b87-4a06-98a8-6f298fbc530d@default> References: <3144a7a4-28d2-a9da-2fc5-dcaaafc6e0c0@oracle.com> <6ae6b0d2-6b87-4a06-98a8-6f298fbc530d@default> Message-ID: On 01/07/17 14:57, Stephen Felts wrote: > IMO: > > 1. You should avoid `--add-modules java.se.ee' unless you need all of those modules. You should bring in only those modules that you need. The choices are java.activation, java.corba, java.transaction, java.xml.bind, java.xml.ws, > java.xml.ws.annotation. So use --add-modules java.xml.ws. Thanks for the tip. > 2. You can't use -XX:+IgnoreUnrecognizedVMOptions as a general solution because that isn't available in JDK6 JRockit for example. Good to know. I was leaning towards JDK_JAVA_OPTIONS anyway. This point confirms that choice. > 3. Setting JDK_JAVA_OPTIONS is good because only JDK9 recognizes it and it is inherited by all nested invocations (unless there is an exec that excludes the environment). You might want to use > export JDK_JAVA_OPTIONS="-XX:+IgnoreUnrecognizedVMOptions --add-modules java.xml.ws" > > 4. --add-opens is not needed starting in b175 so require that as a base. It will still be noisy (a 3-line WARNING will be printed to the standard error). Tomcat won't officially support Java 9 until there is a GA release. Anything before then is on the basis that is should work, but it might not. Thanks again for the additional info. Mark > > > -----Original Message----- > From: Alan Bateman > Sent: Saturday, July 1, 2017 5:53 AM > To: Mark Thomas; jigsaw-dev at openjdk.java.net > Subject: Re: Cleanly starting apps on Java 9 and earlier > > On 01/07/2017 10:18, Mark Thomas wrote: >> Hi, >> >> Apache Tomcat needs to add the following options when running on Java 9: >> >> --add-modules=java.se.ee >> --add-opens=java.base/java.lang=ALL-UNNAMED >> --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED >> >> The first is because it depends on javax.xml.ws.WebServiceRef and >> javax.xml.ws.WebServiceRefs. >> We could work around this by shipping our own implementations but that >> sort of duplication should not be necessary. > The java.xml.ws module is deprecated for removal (along with the other modules shared with Java EE) so expect these modules to not be included in the JDK some day (exactly when is TBD as it depends on when Java SE drops them). > > In the short term then `--add-modules java.se.ee` will resolve the EE modules included in the JDK but it may bring complications, it all depends on whether you have the EE java.transaction module or JAR files with annotations in the javax.annotation package in your environment. An important page for the JDK 9 docs is a page with instructions and deployments options for those using these APIs. > > >> >> The second and third are required by Tomcat's memory leak detection >> and prevention code. In an ideal world, web applications wouldn't have >> memory leaks. Unfortunately, the world isn't ideal and the memory leak >> detection and prevention code has proven immensely valuable over the years. > Both of these packages are open since jdk-9+175 so the hacks to null fields will continue to work. > > That said, I thought the issue with TCCL in sun.rmi.transport.GC was fixed via JDK-8157570. Have you tested that? > > >> The problem we have is that Tomcat needs to run on Java 9 though 6. If >> the above options aren't provided, Java 6 through 8 are fine but on Java >> 9 at best the users see a bunch of errors and at worst Tomcat won't >> start. If the above options are included, Java 9 is fine but then Tomcat >> fails to start on Java 6 though 8. >> > The launch script could examine the JAVA_VERSION property in the > `release` file. Another approach is to set the JDK_JAVA_OPTIONS > environment variable as that is new 9 and so will be ignored by older > releases. There is also -XX:+IgnoreUnrecognizedVMOptions to ignore > unrecognized options. > > -Alan > From alexander.udalov at jetbrains.com Mon Jul 3 11:20:20 2017 From: alexander.udalov at jetbrains.com (Alexander Udalov) Date: Mon, 3 Jul 2017 14:20:20 +0300 Subject: Exporting a package with no Java sources In-Reply-To: References: Message-ID: Hi Jonathan, > Converting the error to a warning (as was suggested in the original post > in this thread) would not address the case where the Java source code > needs to refer to types declared in class files generated from non-Java > sources. You're right. For some reason, I was thinking of passing the non-Java compiled classes directory on the _classpath_ to javac, assuming that would make the classes there accessible to the Java source code. However, this is not a solution because of course, we're compiling a named module which does not read an unnamed module which would contain everything on the classpath. So it seems that the only way to reliably compile a mixed language module would be to compile everything to the same destination directory. But Gradle's decision to separate outputs for different languages, which I mentioned in the first post and which looks pretty logical to me, sort of directly contradicts with this conclusion. Developers of Gradle plugins for other JVM languages would then, I suppose, be required to use hacks like forcing the Java plugin to compile into the same destination directory and then moving out all the newly created files to the correct directory afterwards, right? > It is too late to change this for JDK 9, and even if we could, I think > we are already pushing the limits of what can be specified on the > command line to configure the different paths for all the modules > involved in the compilation. Sure, I understand this is a wrong point in time to propose changes into JDK 9. I'm rather trying to figure out if the situation I described here is considered normal by the Jigsaw team and there could be a sane workaround by us (JVM language engineers), or is considered a problem that should be fixed in the JDK itself, probably in a future update. Thanks! Alexander From alexander.udalov at jetbrains.com Mon Jul 3 11:57:15 2017 From: alexander.udalov at jetbrains.com (Alexander Udalov) Date: Mon, 3 Jul 2017 14:57:15 +0300 Subject: Exporting a package with no Java sources In-Reply-To: References: Message-ID: Hi Alan, > I don't think so, but a dummy class/interface will do (it doesn't have to be > public). There is a lengthy discussion on this topic in JIRA from 2016 that > would be useful to link to (but I can't find it just now because JIRA is > down for maintenance). Thanks, a dummy class certainly workarounds the problem of javac reporting a compilation error here. However, I hope there's a better way because it'd be a bit strange to force users to create a dummy Java class in every exported package in pure X modules (replace X with any JVM language that is not Java). Moreover, as pointed by Jonathan in his answer, I failed to recognize a larger problem initially, that it wouldn't be possible to refer to non-Java classes from Java sources anyway. So what I'm really looking for instead, is the way to "augment" the module currently compiled by javac with a directory containing class files, emitted by another compiler. Still, this workaround could prove helpful for example if there are not many exported packages in a module (which I assume would be true for many modules out there), and there are no Java sources in that module. Thanks! Alexander From Alan.Bateman at oracle.com Mon Jul 3 12:14:28 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 3 Jul 2017 13:14:28 +0100 Subject: Exporting a package with no Java sources In-Reply-To: References: Message-ID: <23fec374-dc45-1b01-df64-3c5d69b09e35@oracle.com> On 03/07/2017 12:57, Alexander Udalov wrote: > : > Thanks, a dummy class certainly workarounds the problem of javac > reporting a compilation error here. However, I hope there's a better > way because it'd be a bit strange to force users to create a dummy > Java class in every exported package in pure X modules (replace X with > any JVM language that is not Java). > > Moreover, as pointed by Jonathan in his answer, I failed to recognize > a larger problem initially, that it wouldn't be possible to refer to > non-Java classes from Java sources anyway. So what I'm really looking > for instead, is the way to "augment" the module currently compiled by > javac with a directory containing class files, emitted by another > compiler. > > Still, this workaround could prove helpful for example if there are > not many exported packages in a module (which I assume would be true > for many modules out there), and there are no Java sources in that > module. > In the module, does the non-Java source code reference the Java code or is it the other way around? It would be useful for thread to understand the order that they need to be compiled. As you use the term "augment" then I'm guessing that the Java code is compiled first, without reference to the non-Java code. Maybe a side point for now but I assume the Kotlin compiler doesn't understand modules yet and so will compile the source "as if" it's in the unnamed module. This could mean the resulting module is DOA if it references types in modules that it won't read when the module is resolved. -Alan From alexander.udalov at jetbrains.com Mon Jul 3 13:23:32 2017 From: alexander.udalov at jetbrains.com (Alexander Udalov) Date: Mon, 3 Jul 2017 16:23:32 +0300 Subject: Exporting a package with no Java sources In-Reply-To: <23fec374-dc45-1b01-df64-3c5d69b09e35@oracle.com> References: <23fec374-dc45-1b01-df64-3c5d69b09e35@oracle.com> Message-ID: > In the module, does the non-Java source code reference the Java code or is > it the other way around? It would be useful for thread to understand the > order that they need to be compiled. As you use the term "augment" then I'm > guessing that the Java code is compiled first, without reference to the > non-Java code. Let's assume that there are both references from Java to non-Java and from non-Java to Java. The compilation order is therefore fixed: first non-Java sources are compiled, then Java sources are compiled. The non-Java compiler is able to read both Java and non-Java sources, and creates .class files for the latter. The Java compiler, on the other hand, cannot read non-Java source files, so it reads the class files compiled by the non-Java compiler on the first step. This is how build tool plugins work today for Kotlin. Also, this is how it _would_ work with Java 9 without any issues, if the destination directory was guaranteed to be the same. But in circumstances where the destination directory could be different for class files compiled by Java and non-Java, I see no way to make the Java compiler read the class files compiled by the non-Java compiler. If they're passed on the classpath (as they are currently on Java 8 and earlier), the classes there are not accessible in Java because the named module cannot read the unnamed module. If they're passed on the module path, they would be loaded in another module, which is incorrect because semantically it's the same module. The original problem of exporting a package I highlighted in the first post is thus only a consequence to this inability to add compiled class files to the currently compiled module. > Maybe a side point for now but I assume the Kotlin compiler doesn't > understand modules yet and so will compile the source "as if" it's in the > unnamed module. This could mean the resulting module is DOA if it references > types in modules that it won't read when the module is resolved. We're working on this currently and this is going to be fixed by the Kotlin compiler being able to read the module-info.java file of the module being compiled, and determining which references are valid and which are not. Alexander From sander.mak at luminis.eu Mon Jul 3 13:36:48 2017 From: sander.mak at luminis.eu (Sander Mak) Date: Mon, 3 Jul 2017 13:36:48 +0000 Subject: Exporting a package with no Java sources In-Reply-To: References: <23fec374-dc45-1b01-df64-3c5d69b09e35@oracle.com> Message-ID: <484B089E-48CE-4ED3-926A-8B0D6AAD0583@luminis.eu> On 3 Jul 2017, at 15:23, Alexander Udalov > wrote: But in circumstances where the destination directory could be different for class files compiled by Java and non-Java, I see no way to make the Java compiler read the class files compiled by the non-Java compiler. If they're passed on the classpath (as they are currently on Java 8 and earlier), the classes there are not accessible in Java because the named module cannot read the unnamed module. If they're passed on the module path, they would be loaded in another module, which is incorrect because semantically it's the same module. Have you tried using `--patch-module` during compilation of the Java sources (as described in http://openjdk.java.net/jeps/261)? Not sure if it works with class files in the patch directory as well, but it sounds like it could address your usecase. Sander From jonathan.gibbons at oracle.com Mon Jul 3 15:30:59 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 3 Jul 2017 08:30:59 -0700 Subject: Exporting a package with no Java sources In-Reply-To: <484B089E-48CE-4ED3-926A-8B0D6AAD0583@luminis.eu> References: <23fec374-dc45-1b01-df64-3c5d69b09e35@oracle.com> <484B089E-48CE-4ED3-926A-8B0D6AAD0583@luminis.eu> Message-ID: <732a84ec-28a7-7da5-de29-30495c5859e1@oracle.com> On 7/3/17 6:36 AM, Sander Mak wrote: > On 3 Jul 2017, at 15:23, Alexander Udalov > wrote: > > But in circumstances where the destination > directory could be different for class files compiled by Java and > non-Java, I see no way to make the Java compiler read the class files > compiled by the non-Java compiler. If they're passed on the classpath > (as they are currently on Java 8 and earlier), the classes there are > not accessible in Java because the named module cannot read the > unnamed module. If they're passed on the module path, they would be > loaded in another module, which is incorrect because semantically it's > the same module. > > Have you tried using `--patch-module` during compilation of the Java sources (as described in http://openjdk.java.net/jeps/261)? Not sure if it works with class files in the patch directory as well, but it sounds like it could address your usecase. > > > Sander Yes, --patch-module should be able to help. -- Jon From alexander.udalov at jetbrains.com Mon Jul 3 16:11:09 2017 From: alexander.udalov at jetbrains.com (Alexander Udalov) Date: Mon, 3 Jul 2017 19:11:09 +0300 Subject: Exporting a package with no Java sources In-Reply-To: <23fec374-dc45-1b01-df64-3c5d69b09e35@oracle.com> References: <23fec374-dc45-1b01-df64-3c5d69b09e35@oracle.com> Message-ID: Hi Sander, > Have you tried using `--patch-module` during compilation of the Java sources (as described in http://openjdk.java.net/jeps/261)? Not sure if it works with class files in the patch directory as well, but it sounds like it could address your usecase. This fixes my problem completely (apart from the minor fact that --patch-module's "use in production settings is strongly discouraged", according to the JEP). I've confirmed with the Gradle team that this approach would be fine to compile a mixed-language module. Thank you! On Mon, Jul 3, 2017 at 3:14 PM, Alan Bateman wrote: > On 03/07/2017 12:57, Alexander Udalov wrote: >> >> : >> Thanks, a dummy class certainly workarounds the problem of javac >> reporting a compilation error here. However, I hope there's a better >> way because it'd be a bit strange to force users to create a dummy >> Java class in every exported package in pure X modules (replace X with >> any JVM language that is not Java). >> >> Moreover, as pointed by Jonathan in his answer, I failed to recognize >> a larger problem initially, that it wouldn't be possible to refer to >> non-Java classes from Java sources anyway. So what I'm really looking >> for instead, is the way to "augment" the module currently compiled by >> javac with a directory containing class files, emitted by another >> compiler. >> >> Still, this workaround could prove helpful for example if there are >> not many exported packages in a module (which I assume would be true >> for many modules out there), and there are no Java sources in that >> module. >> > In the module, does the non-Java source code reference the Java code or is > it the other way around? It would be useful for thread to understand the > order that they need to be compiled. As you use the term "augment" then I'm > guessing that the Java code is compiled first, without reference to the > non-Java code. > > Maybe a side point for now but I assume the Kotlin compiler doesn't > understand modules yet and so will compile the source "as if" it's in the > unnamed module. This could mean the resulting module is DOA if it references > types in modules that it won't read when the module is resolved. > > -Alan From jonathan.gibbons at oracle.com Mon Jul 3 16:20:31 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 3 Jul 2017 09:20:31 -0700 Subject: Exporting a package with no Java sources In-Reply-To: References: <23fec374-dc45-1b01-df64-3c5d69b09e35@oracle.com> Message-ID: On 7/3/17 9:11 AM, Alexander Udalov wrote: > Hi Sander, > >> Have you tried using `--patch-module` during compilation of the Java sources (as described in http://openjdk.java.net/jeps/261)? Not sure if it works with class files in the patch directory as well, but it sounds like it could address your usecase. > This fixes my problem completely (apart from the minor fact that > --patch-module's "use in production settings is strongly discouraged", > according to the JEP). I've confirmed with the Gradle team that this > approach would be fine to compile a mixed-language module. > > Thank you! I think that exhortation applies more to use at runtime. If you're using it at compile/build time to create a well-formed module that does not itself need the use of --patch-module, that seems less of an issue. > > On Mon, Jul 3, 2017 at 3:14 PM, Alan Bateman wrote: >> On 03/07/2017 12:57, Alexander Udalov wrote: >>> : >>> Thanks, a dummy class certainly workarounds the problem of javac >>> reporting a compilation error here. However, I hope there's a better >>> way because it'd be a bit strange to force users to create a dummy >>> Java class in every exported package in pure X modules (replace X with >>> any JVM language that is not Java). >>> >>> Moreover, as pointed by Jonathan in his answer, I failed to recognize >>> a larger problem initially, that it wouldn't be possible to refer to >>> non-Java classes from Java sources anyway. So what I'm really looking >>> for instead, is the way to "augment" the module currently compiled by >>> javac with a directory containing class files, emitted by another >>> compiler. >>> >>> Still, this workaround could prove helpful for example if there are >>> not many exported packages in a module (which I assume would be true >>> for many modules out there), and there are no Java sources in that >>> module. >>> >> In the module, does the non-Java source code reference the Java code or is >> it the other way around? It would be useful for thread to understand the >> order that they need to be compiled. As you use the term "augment" then I'm >> guessing that the Java code is compiled first, without reference to the >> non-Java code. >> >> Maybe a side point for now but I assume the Kotlin compiler doesn't >> understand modules yet and so will compile the source "as if" it's in the >> unnamed module. This could mean the resulting module is DOA if it references >> types in modules that it won't read when the module is resolved. >> >> -Alan From mark.reinhold at oracle.com Mon Jul 3 17:52:31 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 03 Jul 2017 10:52:31 -0700 Subject: RFR 8182776/8183161/8183251: Miscellaneous API doc fixes In-Reply-To: <5956D9D9.1010104@oracle.com> References: <20170630213608.0A5718091A@eggemoggin.niobe.net> <5956D9D9.1010104@oracle.com> Message-ID: <20170703105231.826067087@eggemoggin.niobe.net> 2017/6/30 16:08:09 -0700, jonathan.gibbons at oracle.com: > Mark, > > The font-family settings in the
nodes were deliberate, and a > workaround for not having time to create a proper taglet for tool guides. > > If you remove the style attribute, you'll see in your sample output that > the "Tool Guides" header is in Serif font, but the immediately following > "Since: " header is in the standard Sans Serif font. > > See, for example, this page: > http://cr.openjdk.java.net/~mr/rev/8182776/api/jdk.compiler-summary.html You're right, but the problem with placing the style attribute on the `
` elements is that it forces the `
` text into the sans-serif font. That's fine for the tool-guide links, since they're tool names, but it's wrong for provider descriptions, which are free text (see the attached image). The right fix is to repair the Javadoc stylesheet, but the expedient fix is to tweak the style attributes just where needed, so I've updated the patch to do the latter: http://cr.openjdk.java.net/~mr/rev/8182776/jdk9-dev.patch http://cr.openjdk.java.net/~mr/rev/8182776/api/ (sample output) - Mark From jonathan.gibbons at oracle.com Mon Jul 3 18:02:19 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 03 Jul 2017 11:02:19 -0700 Subject: RFR 8182776/8183161/8183251: Miscellaneous API doc fixes In-Reply-To: <20170703105231.826067087@eggemoggin.niobe.net> References: <20170630213608.0A5718091A@eggemoggin.niobe.net> <5956D9D9.1010104@oracle.com> <20170703105231.826067087@eggemoggin.niobe.net> Message-ID: <595A86AB.4050302@oracle.com> On 07/03/2017 10:52 AM, mark.reinhold at oracle.com wrote: > 2017/6/30 16:08:09 -0700, jonathan.gibbons at oracle.com: >> Mark, >> >> The font-family settings in the
nodes were deliberate, and a >> workaround for not having time to create a proper taglet for tool guides. >> >> If you remove the style attribute, you'll see in your sample output that >> the "Tool Guides" header is in Serif font, but the immediately following >> "Since: " header is in the standard Sans Serif font. >> >> See, for example, this page: >> http://cr.openjdk.java.net/~mr/rev/8182776/api/jdk.compiler-summary.html > You're right, but the problem with placing the style attribute on the > `
` elements is that it forces the `
` text into the sans-serif > font. That's fine for the tool-guide links, since they're tool names, > but it's wrong for provider descriptions, which are free text (see the > attached image). > > The right fix is to repair the Javadoc stylesheet, but the expedient fix > is to tweak the style attributes just where needed, so I've updated the > patch to do the latter: > > http://cr.openjdk.java.net/~mr/rev/8182776/jdk9-dev.patch > http://cr.openjdk.java.net/~mr/rev/8182776/api/ (sample output) > > - Mark Yes, understood. I hadn't realized that "Tool Guides" had been extended to "Providers". -- Jon From jonathan.gibbons at oracle.com Mon Jul 3 18:27:45 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 3 Jul 2017 11:27:45 -0700 Subject: RFR 8182776/8183161/8183251: Miscellaneous API doc fixes In-Reply-To: <20170703105231.826067087@eggemoggin.niobe.net> References: <20170630213608.0A5718091A@eggemoggin.niobe.net> <5956D9D9.1010104@oracle.com> <20170703105231.826067087@eggemoggin.niobe.net> Message-ID: <05d43a1f-23f8-a727-4c03-3bced7097375@oracle.com> Looks good to me. -- Jon On 7/3/17 10:52 AM, mark.reinhold at oracle.com wrote: > 2017/6/30 16:08:09 -0700, jonathan.gibbons at oracle.com: >> Mark, >> >> The font-family settings in the
nodes were deliberate, and a >> workaround for not having time to create a proper taglet for tool guides. >> >> If you remove the style attribute, you'll see in your sample output that >> the "Tool Guides" header is in Serif font, but the immediately following >> "Since: " header is in the standard Sans Serif font. >> >> See, for example, this page: >> http://cr.openjdk.java.net/~mr/rev/8182776/api/jdk.compiler-summary.html > You're right, but the problem with placing the style attribute on the > `
` elements is that it forces the `
` text into the sans-serif > font. That's fine for the tool-guide links, since they're tool names, > but it's wrong for provider descriptions, which are free text (see the > attached image). > > The right fix is to repair the Javadoc stylesheet, but the expedient fix > is to tweak the style attributes just where needed, so I've updated the > patch to do the latter: > > http://cr.openjdk.java.net/~mr/rev/8182776/jdk9-dev.patch > http://cr.openjdk.java.net/~mr/rev/8182776/api/ (sample output) > > - Mark From Alan.Bateman at oracle.com Mon Jul 3 19:53:59 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 3 Jul 2017 20:53:59 +0100 Subject: RFR 8182776/8183161/8183251: Miscellaneous API doc fixes In-Reply-To: <05d43a1f-23f8-a727-4c03-3bced7097375@oracle.com> References: <20170630213608.0A5718091A@eggemoggin.niobe.net> <5956D9D9.1010104@oracle.com> <20170703105231.826067087@eggemoggin.niobe.net> <05d43a1f-23f8-a727-4c03-3bced7097375@oracle.com> Message-ID: <88e099f4-5b86-c302-36d2-b716a91946bf@oracle.com> On 03/07/2017 19:27, Jonathan Gibbons wrote: > Looks good to me. > > -- Jon Thumbs up from me too. -Alan From christoph.langer at sap.com Tue Jul 4 07:02:46 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 4 Jul 2017 07:02:46 +0000 Subject: Use classes in unnamed module that are also contained in a JDK platform/runtime module Message-ID: Hi experts, probably this was already asked or discussed here but I don't find an exact answer for my type of issue, so I'm asking again. I have some piece of software that we ship as a jar file and which will hence run on a JDK 9 in the unnamed module. However, this jar file contains a package that is also contained in our JDK image in a module that is always part of the runtime. So, when my app wants to use one of these classes, I get a java.lang.IllegalAccessError because the class is not exported from the runtime module to my app. And, also if I have a class in that package which is not part of the runtime module, I get a java.lang.NoClassDefFoundError because probably the package is loaded from the runtime module. As I don't want to maintain 2 copies of the same code just to have different package names, I'm wondering if I could solve this somehow by implementing my own class loader for the app that would first try to load these classes from the classpath before delegating to the default application class loader. Would that work? I also did some googling on implementing a non-delegating class loader but to me that seems not so easy and has pitfalls. Is there a good reference or even something in the JDK that I could subclass? Thanks Christoph From Alan.Bateman at oracle.com Tue Jul 4 09:47:06 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 4 Jul 2017 10:47:06 +0100 Subject: Use classes in unnamed module that are also contained in a JDK platform/runtime module In-Reply-To: References: Message-ID: <34be8fb5-5030-aa10-cf93-09ef261d539f@oracle.com> On 04/07/2017 08:02, Langer, Christoph wrote: > Hi experts, > > probably this was already asked or discussed here but I don't find an exact answer for my type of issue, so I'm asking again. > > I have some piece of software that we ship as a jar file and which will hence run on a JDK 9 in the unnamed module. However, this jar file contains a package that is also contained in our JDK image in a module that is always part of the runtime. So, when my app wants to use one of these classes, I get a java.lang.IllegalAccessError because the class is not exported from the runtime module to my app. And, also if I have a class in that package which is not part of the runtime module, I get a java.lang.NoClassDefFoundError because probably the package is loaded from the runtime module. > > As I don't want to maintain 2 copies of the same code just to have different package names, I'm wondering if I could solve this somehow by implementing my own class loader for the app that would first try to load these classes from the classpath before delegating to the default application class loader. Would that work? I also did some googling on implementing a non-delegating class loader but to me that seems not so easy and has pitfalls. Yes, that should work. An alternative is to patch the module (with --patch-module) with the additional classes in the JAR file. This assumes of course that the contents of the JAR file are indeed a compatible superset. > Is there a good reference or even something in the JDK that I could subclass? > The trampoline code in sun.reflect.misc.MethodUtil is roughly in this area but might be too specialized. There may be some test code that you could use - one example is in the patch for JDK-8183503 which is currently waiting for review on hotspot-runtime-dev [1]. -Alan. [1] http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-July/023841.html From christoph.langer at sap.com Thu Jul 6 12:03:07 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 6 Jul 2017 12:03:07 +0000 Subject: Module in JDK image as platform module or loaded by application class loader? Message-ID: Hi there, for our JDK 9 image the jtreg test jdk/modules/etc/VerifyModuleDelegation has unveiled a problem. The issue is that we introduced a few modules that are defined as a platform module. One of these modules requires jdk.attach which is neither boot nor platform. The code within the module that requires jdk.attach seems to work since the platform class loader is able to load jdk.attach classes because it delegates to the application class loader. However, VerifyModuleDelegation is not satisfied with the fact that the loader of our custom module isn't the loader of jdk.attach or one of its ancestors. Now, for me the question is how to solve this correctly? I currently see 3 options: 1. move jdk.attach (and hence jdk.internal.jvmstat ) to the platform modules 2. remove our custom modules from the list of platform modules in order to get them under the application class loader 3. leave the class loaders of the modules alone, remove the requires statement from module-info and implement a Service (Loader) that can be implemented in our jdk.attach version To get on the right way here I probably understand too little of the implications of a module being "Platform". I understand that platform modules don't have all permissions by default such as modules loaded by the boot loader. However, there are some differences and there were reasons why we elevated our modules to "platform", I think it had to do something with caller sensitive calls or other authentication checking mechanisms. So, probably solution 1.) would be the easiest but I don't know if it is a good idea and we lose some compatibility with OpenJDK. 2.) I have to check again where the problems were and 3.) Seems a bit complicated and would unnecessarily break the coupling of modules via module-info. So, I'm hoping to get some advice here :) Thanks in advance and best regards Christoph From Alan.Bateman at oracle.com Thu Jul 6 12:44:19 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 6 Jul 2017 13:44:19 +0100 Subject: Module in JDK image as platform module or loaded by application class loader? In-Reply-To: References: Message-ID: On 06/07/2017 13:03, Langer, Christoph wrote: > Hi there, > > for our JDK 9 image the jtreg test jdk/modules/etc/VerifyModuleDelegation has unveiled a problem. > > The issue is that we introduced a few modules that are defined as a platform module. One of these modules requires jdk.attach which is neither boot nor platform. The code within the module that requires jdk.attach seems to work since the platform class loader is able to load jdk.attach classes because it delegates to the application class loader. This is special delegation that is needed in order to support upgraded modules that depend on modules on the application module path. > However, VerifyModuleDelegation is not satisfied with the fact that the loader of our custom module isn't the loader of jdk.attach or one of its ancestors. > > Now, for me the question is how to solve this correctly? I currently see 3 options: > 1. move jdk.attach (and hence jdk.internal.jvmstat ) to the platform modules The attach API is a tool API and tool APIs have traditionally had their classes defined to the app class loader (by way of putting tools.jar on the class path path). So I don't think this should be changed. > 2. remove our custom modules from the list of platform modules in order to get them under the application class loader This seems the right option but would be interesting to know why it was added to PLATFORM_MODULES in the first place. > 3. leave the class loaders of the modules alone, remove the requires statement from module-info and implement a Service (Loader) that can be implemented in our jdk.attach version > > That would work but seems unnecessary indirection unless the usage lends itself to services. -Alan From alex.buckley at oracle.com Thu Jul 6 18:16:01 2017 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 06 Jul 2017 11:16:01 -0700 Subject: Use classes in unnamed module that are also contained in a JDK platform/runtime module In-Reply-To: References: Message-ID: <595E7E61.4020506@oracle.com> Hi Christoph, On 7/4/2017 12:02 AM, Langer, Christoph wrote: > I have some piece of software that we ship as a jar file and which > will hence run on a JDK 9 in the unnamed module. However, this jar > file contains a package that is also contained in our JDK image in a > module that is always part of the runtime. It would be remiss of me if I didn't ask for some details about why this scenario has arisen. From "always part of the runtime", I would have guessed the package is in java.base, but you also mention "our JDK image" so perhaps the package is in a module that SAP always jlinks in? Alex From christoph.langer at sap.com Fri Jul 7 06:37:57 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 7 Jul 2017 06:37:57 +0000 Subject: Use classes in unnamed module that are also contained in a JDK platform/runtime module In-Reply-To: <595E7E61.4020506@oracle.com> References: <595E7E61.4020506@oracle.com> Message-ID: Hi Alex, > On 7/4/2017 12:02 AM, Langer, Christoph wrote: > > I have some piece of software that we ship as a jar file and which > > will hence run on a JDK 9 in the unnamed module. However, this jar > > file contains a package that is also contained in our JDK image in a > > module that is always part of the runtime. > > It would be remiss of me if I didn't ask for some details about why this > scenario has arisen. From "always part of the runtime", I would have > guessed the package is in java.base, but you also mention "our JDK > image" so perhaps the package is in a module that SAP always jlinks in? Thanks for your interest in the details. Here it is: We have a separate module that exposes an augmenting SAP specific API which is publicly exported. This module is part of our JDK image. And it in turn pulls a few other modules with the implementing classes and packages. And then we ship a few tools and services apart from the JDK. Some of these are Eclipse based, some of these are standalone. And parts of these tools use the basic classes which are also observable in the JDK. But they need to be there as our tooling should run on any JDK, not only ours. I think Eclipse-wise we are good, at least when Eclipse runs on Java 8. With the Eclipse classloading, we get the classes out of the plugins. However, since Eclipse is not really mature yet for Java 9, I didn't test there so far. And for the standalone apps, I probably need to look into implementing some custom classloader. I'll try with Alan's suggestions (thanks Alan) but didn't find the time yet. Thanks & Best regards Christoph From alex.buckley at oracle.com Sat Jul 8 00:26:14 2017 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 07 Jul 2017 17:26:14 -0700 Subject: Use classes in unnamed module that are also contained in a JDK platform/runtime module In-Reply-To: References: <595E7E61.4020506@oracle.com> Message-ID: <596026A6.4050008@oracle.com> On 7/6/2017 11:37 PM, Langer, Christoph wrote: >> On 7/4/2017 12:02 AM, Langer, Christoph wrote: >>> I have some piece of software that we ship as a jar file and >>> which will hence run on a JDK 9 in the unnamed module. However, >>> this jar file contains a package that is also contained in our >>> JDK image in a module that is always part of the runtime. >> >> It would be remiss of me if I didn't ask for some details about why >> this scenario has arisen. From "always part of the runtime", I >> would have guessed the package is in java.base, but you also >> mention "our JDK image" so perhaps the package is in a module that >> SAP always jlinks in? > > Thanks for your interest in the details. Here it is: We have a > separate module that exposes an augmenting SAP specific API which is > publicly exported. This module is part of our JDK image. The default set of root modules for the unnamed module is specified by JEP 261 rather than a JSR, but I guess the SAP JDK implementation uses the same default set as the OpenJDK implementation. Then, since your separate module exports a package without qualification, the separate module is in the default set. You could mark the separate module as DoNotResolveByDefault so that it is observable *but not readable* by the unnamed module which holds your JAR file's tool classes + copies of SAP-specific API/impl classes. Or, given that the JAR file is meant to be cross-JDK and so should never be aware of the separate module, your tool's launch script could make the separate module unobservable (--limit-modules). Alex From blackdrag at gmx.org Sun Jul 9 23:16:58 2017 From: blackdrag at gmx.org (Jochen Theodorou) Date: Mon, 10 Jul 2017 01:16:58 +0200 Subject: =?UTF-8?Q?trySetAccessible=e2=80=8b?= Message-ID: Hi all, since the JVM now prints warnings if you call setAccssible there was the advise to move to trySetAccessible? to prvent these warnings. Now I am told those warnings appear here as well. Now my question would be about what the intended behaviour here is. in what mode is a trySetAccessible? supposed to cause the JVM to issue a warning or other message about a module accessing something? And if the warnings are the intended behaviour, then what is the way to avoid this if I cannot just stop trying? bye Jochen From stephen.felts at oracle.com Mon Jul 10 02:28:32 2017 From: stephen.felts at oracle.com (Stephen Felts) Date: Sun, 9 Jul 2017 19:28:32 -0700 (PDT) Subject: =?utf-8?B?UkU6IHRyeVNldEFjY2Vzc2libGXigIs=?= In-Reply-To: References: Message-ID: <7387b29a-3857-4729-af4a-b9ebb383eed3@default> I have asked for a mechanism to avoid the warnings multiple times and there is no way to do it. That's unfortunate because there are multiple projects that have been modified to work with JDK9 and they still produce a warning. I have resorted to keeping a list of known warnings that are OK (currently at 10). Here are a few public (non-Oracle) ones: ? org.python.core.PyJavaClass com.sun.xml.bind.v2.runtime.reflect.opt.Injector com.sun.xml.ws.model.Injector net.sf.cglib.core.ReflectUtils$ ? ? -----Original Message----- From: Jochen Theodorou [mailto:blackdrag at gmx.org] Sent: Sunday, July 9, 2017 7:17 PM To: jigsaw-dev at openjdk.java.net Subject: trySetAccessible? ? Hi all, ? since the JVM now prints warnings if you call setAccssible there was the advise to move to trySetAccessible? to prvent these warnings. Now I am told those warnings appear here as well. ? Now my question would be about what the intended behaviour here is. in what mode is a trySetAccessible? supposed to cause the JVM to issue a warning or other message about a module accessing something? ? And if the warnings are the intended behaviour, then what is the way to avoid this if I cannot just stop trying? ? bye Jochen ? From christoph.langer at sap.com Mon Jul 10 07:21:23 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 10 Jul 2017 07:21:23 +0000 Subject: Use classes in unnamed module that are also contained in a JDK platform/runtime module In-Reply-To: <596026A6.4050008@oracle.com> References: <595E7E61.4020506@oracle.com> <596026A6.4050008@oracle.com> Message-ID: <6d4035bec4624e0b9818dab921350171@sap.com> Hi Alex, > On 7/6/2017 11:37 PM, Langer, Christoph wrote: > >> On 7/4/2017 12:02 AM, Langer, Christoph wrote: > >>> I have some piece of software that we ship as a jar file and > >>> which will hence run on a JDK 9 in the unnamed module. However, > >>> this jar file contains a package that is also contained in our > >>> JDK image in a module that is always part of the runtime. > >> > >> It would be remiss of me if I didn't ask for some details about why > >> this scenario has arisen. From "always part of the runtime", I > >> would have guessed the package is in java.base, but you also > >> mention "our JDK image" so perhaps the package is in a module that > >> SAP always jlinks in? > > > > Thanks for your interest in the details. Here it is: We have a > > separate module that exposes an augmenting SAP specific API which is > > publicly exported. This module is part of our JDK image. > > The default set of root modules for the unnamed module is specified by > JEP 261 rather than a JSR, but I guess the SAP JDK implementation uses > the same default set as the OpenJDK implementation. Then, since your > separate module exports a package without qualification, the separate > module is in the default set. Exactly, this is how it is designed. > You could mark the separate module as DoNotResolveByDefault so that it > is observable *but not readable* by the unnamed module which holds your > JAR file's tool classes + copies of SAP-specific API/impl classes. > > Or, given that the JAR file is meant to be cross-JDK and so should never > be aware of the separate module, your tool's launch script could make > the separate module unobservable (--limit-modules). OK, this maybe is a good idea to try. When I'm running my JDK-independent tool on top of our VM, then this public API is not used and probably neither of its dependents. I'll test that. Thanks a lot for your consulting. Best regards Christoph From Alan.Bateman at oracle.com Mon Jul 10 08:07:06 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 10 Jul 2017 09:07:06 +0100 Subject: =?UTF-8?Q?Re:_trySetAccessible=e2=80=8b?= In-Reply-To: References: Message-ID: <64e937e7-4a60-7a09-ae6e-1fa816e510d4@oracle.com> On 10/07/2017 00:16, Jochen Theodorou wrote: > Hi all, > > since the JVM now prints warnings if you call setAccssible there was > the advise to move to trySetAccessible? to prvent these warnings. The motivation for trySetAccessible is to avoid using exceptions for control flow. I don't recall any suggestion here to use it as a way to avoid warnings. Remember the purpose of the warnings is to make you or your users aware that the code will behave differently when access to JDK internals, or other so-called illegal access, is denied. -Alan From Alan.Bateman at oracle.com Mon Jul 10 08:12:06 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 10 Jul 2017 09:12:06 +0100 Subject: =?UTF-8?Q?Re:_trySetAccessible=e2=80=8b?= In-Reply-To: <7387b29a-3857-4729-af4a-b9ebb383eed3@default> References: <7387b29a-3857-4729-af4a-b9ebb383eed3@default> Message-ID: On 10/07/2017 03:28, Stephen Felts wrote: > : > > com.sun.xml.bind.v2.runtime.reflect.opt.Injector > > com.sun.xml.ws.model.Injector > From what I can tell, these two aren't using tryAccessible. Instead they seem to use setAccessible to attempt to get at a non-public ClassLoader.defineClass method. It succeeds, with a warning, because java.lang is open. If it were to fail then they catch InaccessibleObjectException and try the deprecated-for-removal Unsafe.defineClass. These two seem like good candidates for Lookup.defineClass. -Alan From uschindler at apache.org Mon Jul 10 08:43:42 2017 From: uschindler at apache.org (Uwe Schindler) Date: Mon, 10 Jul 2017 10:43:42 +0200 Subject: =?utf-8?Q?RE:_trySetAccessible=E2=80=8B?= In-Reply-To: <64e937e7-4a60-7a09-ae6e-1fa816e510d4@oracle.com> References: <64e937e7-4a60-7a09-ae6e-1fa816e510d4@oracle.com> Message-ID: <01ce01d2f958$a5843930$f08cab90$@apache.org> Hi Alan, I was trying to fix Groovy to use trySetAccessible() instead of setAccessible() and this did not change any warnings at all: The code can be found here: https://github.com/apache/groovy/compare/master...uschindler:java9/trySetAccessible It did not change anything. In fact, the code behaved as it did before - no change at all! Warnings are almost the same (actually worse, because of how I did it using MethodHandles, see bwlow). It also granted full access, like the usual call to setAccessible()! As Jochen said: > Now I am told those warnings appear here as well. I was the one who told it to him indirectly... because I tried to fix it for Groovy with the above code change! It granted access to internal API as it did before and it also printed the warning - so the new API was identicak to a simple call to setAccessible. Why is the new AI there at all, setAccessible did the same. And an if/then/else vs. a try/catch is not really different! Sorry, I expected trySetAccesible() to behave differently: As this is a *new* API in Java 9, I would have expected that the "big kill switch" does not affect this! So when calling this new API, I would have expected that it would behave as follows: - It would *not* grant access to internal APIs, as specified in the Java 9 spec and the module system. As the API is new, there s no need for it to respect the "big kill switch" aka "permit-illegal-access". - It would not print a warning at all! In fact the new code in the above patch to Groovy was much more confusing, as the warning was suddenly printed by a JDK-internal class - which is a bug IMHO: The JDK printed a warning like this: WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by org.codehaus.groovy.reflection.InjectedInvoker/1364880320 (file:/C:/Users/Uwe%20Schindler/Projects/groovy/target/classes/java/main/) to method java.lang.Object.finalize() WARNING: Please consider reporting this to the maintainers of org.codehaus.groovy.reflection.InjectedInvoker/1364880320 WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release This came from the fact, that the internal wrapper of the MethodHandle, which was created by the call to trySetAccessible() using a MethodHandle. I suppose it was used to make the caller-sensitive stuff work correctly. So I was baffled, because the warning was not really helpful anymore! The class mentioned here does not even exist anywhere!!! ? Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: jigsaw-dev [mailto:jigsaw-dev-bounces at openjdk.java.net] On Behalf > Of Alan Bateman > Sent: Monday, July 10, 2017 10:07 AM > To: Jochen Theodorou ; jigsaw-dev at openjdk.java.net > Subject: Re: trySetAccessible? > > On 10/07/2017 00:16, Jochen Theodorou wrote: > > Hi all, > > > > since the JVM now prints warnings if you call setAccssible there was > > the advise to move to trySetAccessible? to prvent these warnings. > The motivation for trySetAccessible is to avoid using exceptions for > control flow. I don't recall any suggestion here to use it as a way to > avoid warnings. > > Remember the purpose of the warnings is to make you or your users aware > that the code will behave differently when access to JDK internals, or > other so-called illegal access, is denied. > > -Alan From cedric.champeau at gmail.com Mon Jul 10 08:49:35 2017 From: cedric.champeau at gmail.com (=?UTF-8?Q?C=C3=A9dric_Champeau?=) Date: Mon, 10 Jul 2017 10:49:35 +0200 Subject: =?UTF-8?Q?Re=3A_trySetAccessible=E2=80=8B?= In-Reply-To: <01ce01d2f958$a5843930$f08cab90$@apache.org> References: <64e937e7-4a60-7a09-ae6e-1fa816e510d4@oracle.com> <01ce01d2f958$a5843930$f08cab90$@apache.org> Message-ID: I second Uwe's comment here: I was surprised as well, I expected the semantics of `trySetAccessible` to be: "let me know if I can do this, respecting the semantics of modules, and if not, return false" 2017-07-10 10:43 GMT+02:00 Uwe Schindler : > Hi Alan, > > I was trying to fix Groovy to use trySetAccessible() instead of > setAccessible() and this did not change any warnings at all: The code can > be found here: > > https://github.com/apache/groovy/compare/master...uschindler:java9/ > trySetAccessible > > It did not change anything. In fact, the code behaved as it did before - > no change at all! Warnings are almost the same (actually worse, because of > how I did it using MethodHandles, see bwlow). It also granted full access, > like the usual call to setAccessible()! > > As Jochen said: > > > Now I am told those warnings appear here as well. > > I was the one who told it to him indirectly... because I tried to fix it > for Groovy with the above code change! > > It granted access to internal API as it did before and it also printed the > warning - so the new API was identicak to a simple call to setAccessible. > Why is the new AI there at all, setAccessible did the same. And an > if/then/else vs. a try/catch is not really different! Sorry, I expected > trySetAccesible() to behave differently: As this is a *new* API in Java 9, > I would have expected that the "big kill switch" does not affect this! So > when calling this new API, I would have expected that it would behave as > follows: > > - It would *not* grant access to internal APIs, as specified in the Java 9 > spec and the module system. As the API is new, there s no need for it to > respect the "big kill switch" aka "permit-illegal-access". > - It would not print a warning at all! > > In fact the new code in the above patch to Groovy was much more confusing, > as the warning was suddenly printed by a JDK-internal class - which is a > bug IMHO: The JDK printed a warning like this: > > WARNING: An illegal reflective access operation has occurred > WARNING: Illegal reflective access by org.codehaus.groovy. > reflection.InjectedInvoker/1364880320 (file:/C:/Users/Uwe% > 20Schindler/Projects/groovy/target/classes/java/main/) to method > java.lang.Object.finalize() > WARNING: Please consider reporting this to the maintainers of > org.codehaus.groovy.reflection.InjectedInvoker/1364880320 > WARNING: Use --illegal-access=warn to enable warnings of further illegal > reflective access operations > WARNING: All illegal access operations will be denied in a future release > > This came from the fact, that the internal wrapper of the MethodHandle, > which was created by the call to trySetAccessible() using a MethodHandle. I > suppose it was used to make the caller-sensitive stuff work correctly. So I > was baffled, because the warning was not really helpful anymore! The class > mentioned here does not even exist anywhere!!! ? > > Uwe > > ----- > Uwe Schindler > uschindler at apache.org > ASF Member, Apache Lucene PMC / Committer > Bremen, Germany > http://lucene.apache.org/ > > > -----Original Message----- > > From: jigsaw-dev [mailto:jigsaw-dev-bounces at openjdk.java.net] On Behalf > > Of Alan Bateman > > Sent: Monday, July 10, 2017 10:07 AM > > To: Jochen Theodorou ; jigsaw-dev at openjdk.java.net > > Subject: Re: trySetAccessible? > > > > On 10/07/2017 00:16, Jochen Theodorou wrote: > > > Hi all, > > > > > > since the JVM now prints warnings if you call setAccssible there was > > > the advise to move to trySetAccessible? to prvent these warnings. > > The motivation for trySetAccessible is to avoid using exceptions for > > control flow. I don't recall any suggestion here to use it as a way to > > avoid warnings. > > > > Remember the purpose of the warnings is to make you or your users aware > > that the code will behave differently when access to JDK internals, or > > other so-called illegal access, is denied. > > > > -Alan > > From blackdrag at gmx.org Mon Jul 10 08:52:10 2017 From: blackdrag at gmx.org (Jochen Theodorou) Date: Mon, 10 Jul 2017 10:52:10 +0200 Subject: =?UTF-8?Q?Re:_trySetAccessible=e2=80=8b?= In-Reply-To: References: <64e937e7-4a60-7a09-ae6e-1fa816e510d4@oracle.com> <01ce01d2f958$a5843930$f08cab90$@apache.org> Message-ID: On 10.07.2017 10:49, C?dric Champeau wrote: > I second Uwe's comment here: I was surprised as well, I expected the > semantics of `trySetAccessible` to be: "let me know if I can do this, > respecting the semantics of modules, and if not, return false" I suspect canAccess is supposed to be used here... of course the semantics of that method are not enough for us. bye Jochen From blackdrag at gmx.org Mon Jul 10 09:44:30 2017 From: blackdrag at gmx.org (Jochen Theodorou) Date: Mon, 10 Jul 2017 11:44:30 +0200 Subject: =?UTF-8?Q?Re:_trySetAccessible=e2=80=8b?= In-Reply-To: <64e937e7-4a60-7a09-ae6e-1fa816e510d4@oracle.com> References: <64e937e7-4a60-7a09-ae6e-1fa816e510d4@oracle.com> Message-ID: <6f810b30-1030-1e4a-4fdf-3def884c6a27@gmx.org> On 10.07.2017 10:07, Alan Bateman wrote: [...] > Remember the purpose of the warnings is to make you or your users aware > that the code will behave differently when access to JDK internals, or > other so-called illegal access, is denied. In the past we did create a MetaClass, which contains all the accessible methods and properties. This meta class is used for method selection during invocation, it is used for querying and for runtime meta programming. These warnings now force us to change the semantics and not show the accessible methods, but all methods. Invocation will then have to make it accessible... something we moved to meta class creation because it slows down the invocation mechanism. And then we will still get false warnings in reflective code. Example: module A: class Foo { protected void foo(){} } Groovy program: class X extends Foo { def bar() {return {foo()}} } if Foo is in an exported package, then it is legal for X to call foo, even though it is protected. But bar() does not directly call foo, it will do so in a Closure (not functional closure, not lambdas). In a Closure the implicit this has no fixed meaning and is realized as anonymous inner class. With our current protocol the call to foo ends up in the meta class logic, which then executes the method call. This will then cause a warning "WARNING: An illegal reflective access operation has occurred". Now tell me how this is useful for the user. The call is supposed to be legal after all. Still we will get a warning. How am I supposed to tell our users about correct and wrong warnings? Of course I am aware that I am supposed to give in a Lookup object and return a MethodHandle instead. But without changes to the MOP API this cannot be done. And that means Groovy 1.0 code will, for the first time in our history, no longer really work on a new Groovy version, once this change is done. And here I am not even sure that "giving in the Lookup object" is really what I should do. This Lookup object would have full access to X after all (I need to be able to call private methods too you know). And that does not sound right either bye Jochen From Alan.Bateman at oracle.com Mon Jul 10 09:55:58 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 10 Jul 2017 10:55:58 +0100 Subject: =?UTF-8?Q?Re:_trySetAccessible=e2=80=8b?= In-Reply-To: References: <64e937e7-4a60-7a09-ae6e-1fa816e510d4@oracle.com> <01ce01d2f958$a5843930$f08cab90$@apache.org> Message-ID: On 10/07/2017 09:49, C?dric Champeau wrote: > I second Uwe's comment here: I was surprised as well, I expected the > semantics of `trySetAccessible` to be: "let me know if I can do this, > respecting the semantics of modules, and if not, return false" For the example, trySetAccessible succeeds (returns `true`) because `java.lang` is open. If you run with `--illegal-access=deny` then `java.lang` will not be opened and trySetAccessible should return `false`. -Alan From stephen.felts at oracle.com Mon Jul 10 09:58:51 2017 From: stephen.felts at oracle.com (Stephen Felts) Date: Mon, 10 Jul 2017 02:58:51 -0700 (PDT) Subject: =?utf-8?B?UkU6IHRyeVNldEFjY2Vzc2libGXigIs=?= In-Reply-To: References: <64e937e7-4a60-7a09-ae6e-1fa816e510d4@oracle.com> <01ce01d2f958$a5843930$f08cab90$@apache.org> Message-ID: <4c2a7a29-a6f5-4a4f-b917-609ed96d5842@default> Right. We need an API that returns false with no warning. -----Original Message----- From: Alan Bateman Sent: Monday, July 10, 2017 5:56 AM To: C?dric Champeau Cc: jigsaw-dev Subject: Re: trySetAccessible? On 10/07/2017 09:49, C?dric Champeau wrote: > I second Uwe's comment here: I was surprised as well, I expected the > semantics of `trySetAccessible` to be: "let me know if I can do this, > respecting the semantics of modules, and if not, return false" For the example, trySetAccessible succeeds (returns `true`) because `java.lang` is open. If you run with `--illegal-access=deny` then `java.lang` will not be opened and trySetAccessible should return `false`. -Alan From cedric.champeau at gmail.com Mon Jul 10 09:59:26 2017 From: cedric.champeau at gmail.com (=?UTF-8?Q?C=C3=A9dric_Champeau?=) Date: Mon, 10 Jul 2017 11:59:26 +0200 Subject: =?UTF-8?Q?Re=3A_trySetAccessible=E2=80=8B?= In-Reply-To: References: <64e937e7-4a60-7a09-ae6e-1fa816e510d4@oracle.com> <01ce01d2f958$a5843930$f08cab90$@apache.org> Message-ID: This is not really practical. Basically it means that for every Gradle build script on earth, we would either choose to make them fail on JDK 9, or be bloated with warnings, that are actually handled. 2017-07-10 11:55 GMT+02:00 Alan Bateman : > On 10/07/2017 09:49, C?dric Champeau wrote: > >> I second Uwe's comment here: I was surprised as well, I expected the >> semantics of `trySetAccessible` to be: "let me know if I can do this, >> respecting the semantics of modules, and if not, return false" >> > For the example, trySetAccessible succeeds (returns `true`) because > `java.lang` is open. If you run with `--illegal-access=deny` then > `java.lang` will not be opened and trySetAccessible should return `false`. > > -Alan > From Alan.Bateman at oracle.com Mon Jul 10 10:02:16 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 10 Jul 2017 11:02:16 +0100 Subject: =?UTF-8?Q?Re:_trySetAccessible=e2=80=8b?= In-Reply-To: <01ce01d2f958$a5843930$f08cab90$@apache.org> References: <64e937e7-4a60-7a09-ae6e-1fa816e510d4@oracle.com> <01ce01d2f958$a5843930$f08cab90$@apache.org> Message-ID: <62b21184-4624-fec4-b83d-d18c1404b6b1@oracle.com> On 10/07/2017 09:43, Uwe Schindler wrote: > Hi Alan, > > I was trying to fix Groovy to use trySetAccessible() instead of setAccessible() and this did not change any warnings at all: The code can be found here: > > https://github.com/apache/groovy/compare/master...uschindler:java9/trySetAccessible > > It did not change anything. In fact, the code behaved as it did before - no change at all! Warnings are almost the same (actually worse, because of how I did it using MethodHandles, see bwlow). It also granted full access, like the usual call to setAccessible()! This is because the java.lang package is open at runtime in JDK 9. Once open then you can use both old and new APIs to do so-called "deep reflection" on members of all classes in the package. -Alan From Alan.Bateman at oracle.com Mon Jul 10 10:06:05 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 10 Jul 2017 11:06:05 +0100 Subject: =?UTF-8?Q?Re:_trySetAccessible=e2=80=8b?= In-Reply-To: References: <64e937e7-4a60-7a09-ae6e-1fa816e510d4@oracle.com> <01ce01d2f958$a5843930$f08cab90$@apache.org> Message-ID: <211600b7-1619-e0e5-8bbe-4d3b66206d29@oracle.com> On 10/07/2017 10:59, C?dric Champeau wrote: > This is not really practical. Basically it means that for every Gradle > build script on earth, we would either choose to make them fail on JDK > 9, or be bloated with warnings, that are actually handled. My mail was just explaining why it returns `true`. The right way to get rid of these warnings is to fix the underlying issues. -Alan From blackdrag at gmx.org Mon Jul 10 10:21:29 2017 From: blackdrag at gmx.org (Jochen Theodorou) Date: Mon, 10 Jul 2017 12:21:29 +0200 Subject: =?UTF-8?Q?Re:_trySetAccessible=e2=80=8b?= In-Reply-To: <211600b7-1619-e0e5-8bbe-4d3b66206d29@oracle.com> References: <64e937e7-4a60-7a09-ae6e-1fa816e510d4@oracle.com> <01ce01d2f958$a5843930$f08cab90$@apache.org> <211600b7-1619-e0e5-8bbe-4d3b66206d29@oracle.com> Message-ID: <86e75421-1fc8-35d0-4cce-2a79d61aa6e8@gmx.org> On 10.07.2017 12:06, Alan Bateman wrote: > On 10/07/2017 10:59, C?dric Champeau wrote: >> This is not really practical. Basically it means that for every Gradle >> build script on earth, we would either choose to make them fail on JDK >> 9, or be bloated with warnings, that are actually handled. > My mail was just explaining why it returns `true`. > > The right way to get rid of these warnings is to fix the underlying issues. see my other mail bye Jochen From Alan.Bateman at oracle.com Mon Jul 10 10:39:37 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 10 Jul 2017 11:39:37 +0100 Subject: =?UTF-8?Q?Re:_trySetAccessible=e2=80=8b?= In-Reply-To: <6f810b30-1030-1e4a-4fdf-3def884c6a27@gmx.org> References: <64e937e7-4a60-7a09-ae6e-1fa816e510d4@oracle.com> <6f810b30-1030-1e4a-4fdf-3def884c6a27@gmx.org> Message-ID: On 10/07/2017 10:44, Jochen Theodorou wrote: > : > > Example: > > module A: > > class Foo { > protected void foo(){} > } > > Groovy program: > > class X extends Foo { > def bar() {return {foo()}} > } > > if Foo is in an exported package, then it is legal for X to call foo, > even though it is protected. But bar() does not directly call foo, it > will do so in a Closure (not functional closure, not lambdas). and therein is the issue because protected members should only be accessible in the sub-class (or same package). > In a Closure the implicit this has no fixed meaning and is realized as > anonymous inner class. With our current protocol the call to foo ends > up in the meta class logic, which then executes the method call. This > will then cause a warning "WARNING: An illegal reflective access > operation has occurred". Do you have any control on the code that is generated for X? -Alan From uschindler at apache.org Mon Jul 10 15:31:20 2017 From: uschindler at apache.org (Uwe Schindler) Date: Mon, 10 Jul 2017 17:31:20 +0200 Subject: =?utf-8?Q?RE:_trySetAccessible=E2=80=8B?= In-Reply-To: References: <64e937e7-4a60-7a09-ae6e-1fa816e510d4@oracle.com> <01ce01d2f958$a5843930$f08cab90$@apache.org> Message-ID: <027401d2f991$9736c990$c5a45cb0$@apache.org> Hi Alan, we understand all this. But what you say is also not true. I started a second approach to fix the issue by using canAccess() and also checking the module stuff. For that I executed the following code on the Groovy unnamed module: import org.codehaus.groovy.reflection.CachedClass; String.getClass().getModule().isOpen(CachedClass.class.getPackage().getName(), CachedClass.class.getModule()); This returned false, so the java.base module is not open to the package and code hosting Groovy's CachedClass! But setAccessible still works with a warning. If I do the same using another class from Groovy's own unnamed module, it returns true (as expected). If I call the same with a test of StringBuilder instead of CachedClass it returns true. If I try to access sun.misc.Unsafe that way, it works (as expected, because its declared as "open" in module descriptor - for good reasons, also if you don't permit illegal accesses). So the module is definitely not "offically open" to the Groovy/unnamed module according to its metadata in java.lang.Module! Because of this, many people were under the impression that the "open" hack only applied to the "old" setAccessible API, but new Java 9 APIs would behave in the new way. Because of this I understood Mark Reinhold's original proposal mail like this: old-style setAccessible still works with warning, all new APIs (trySetAccessible and Module metadata still say "the computer says no!"). Actually only the module metadata return the correct thing, trySetAccessible behaves like the old setAccessible. So what we need to fix the issue: Give us an API that we can ask "is access possible" if I respect the module system and the module metadata? I hacked this in a second attempt to solve Groovy's issue by using the above module metadata. Whenever it figures out that a class returns false for above's call, it does not even try to call setAccessible. See the code here: https://goo.gl/JnrNyH This works but the problem is that it is then hard to figure out which methods you can still call without setAccessible. With trySetAccessible or canAccess this would be fine. The problem for Groovy with canAccess() is that you need an instance, which is not available at the time of the check. Why is this? Why do I need an instance for canAccess() checks? I have the feeling because it could be a subclass of the reflected class you try the method call on, right? Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: jigsaw-dev [mailto:jigsaw-dev-bounces at openjdk.java.net] On Behalf > Of Alan Bateman > Sent: Monday, July 10, 2017 11:56 AM > To: C?dric Champeau > Cc: jigsaw-dev > Subject: Re: trySetAccessible? > > On 10/07/2017 09:49, C?dric Champeau wrote: > > I second Uwe's comment here: I was surprised as well, I expected the > > semantics of `trySetAccessible` to be: "let me know if I can do this, > > respecting the semantics of modules, and if not, return false" > For the example, trySetAccessible succeeds (returns `true`) because > `java.lang` is open. If you run with `--illegal-access=deny` then > `java.lang` will not be opened and trySetAccessible should return `false`. > > -Alan From Alan.Bateman at oracle.com Mon Jul 10 15:40:19 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 10 Jul 2017 16:40:19 +0100 Subject: =?UTF-8?Q?Re:_trySetAccessible=e2=80=8b?= In-Reply-To: <027401d2f991$9736c990$c5a45cb0$@apache.org> References: <64e937e7-4a60-7a09-ae6e-1fa816e510d4@oracle.com> <01ce01d2f958$a5843930$f08cab90$@apache.org> <027401d2f991$9736c990$c5a45cb0$@apache.org> Message-ID: <5a9430e0-8bde-b15b-2be1-5a4337525a21@oracle.com> On 10/07/2017 16:31, Uwe Schindler wrote: > Hi Alan, > > we understand all this. But what you say is also not true. I started a second approach to fix the issue by using canAccess() and also checking the module stuff. For that I executed the following code on the Groovy unnamed module: > > import org.codehaus.groovy.reflection.CachedClass; > String.getClass().getModule().isOpen(CachedClass.class.getPackage().getName(), CachedClass.class.getModule()); > > This returned false, so the java.base module is not open to the package and code hosting Groovy's CachedClass! But setAccessible still works with a warning. This code fragment tests if java.base opens a package to CachedClass.class.getModule(). Can you say which package CachedClass is in? I ask because I would have expected to see: String.class.getModule().isOpen("java.lang", CachedClass.class.getModule()); to test if java.base opens java.lang to the Groovy module. -Alan From uschindler at apache.org Tue Jul 11 09:16:15 2017 From: uschindler at apache.org (Uwe Schindler) Date: Tue, 11 Jul 2017 11:16:15 +0200 Subject: =?utf-8?Q?RE:_trySetAccessible=E2=80=8B?= In-Reply-To: <5a9430e0-8bde-b15b-2be1-5a4337525a21@oracle.com> References: <64e937e7-4a60-7a09-ae6e-1fa816e510d4@oracle.com> <01ce01d2f958$a5843930$f08cab90$@apache.org> <027401d2f991$9736c990$c5a45cb0$@apache.org> <5a9430e0-8bde-b15b-2be1-5a4337525a21@oracle.com> Message-ID: <03f801d2fa26$5c49d710$14dd8530$@apache.org> Moin, > > we understand all this. But what you say is also not true. I started a second > approach to fix the issue by using canAccess() and also checking the module > stuff. For that I executed the following code on the Groovy unnamed > module: > > > > import org.codehaus.groovy.reflection.CachedClass; > > > String.getClass().getModule().isOpen(CachedClass.class.getPackage().getNam > e(), CachedClass.class.getModule()); > > > > This returned false, so the java.base module is not open to the package and > code hosting Groovy's CachedClass! But setAccessible still works with a > warning. > This code fragment tests if java.base opens a package to > CachedClass.class.getModule(). Can you say which package CachedClass is > in? I ask because I would have expected to see: > > String.class.getModule().isOpen("java.lang", > CachedClass.class.getModule()); > > to test if java.base opens java.lang to the Groovy module. Sorry, I mixed up the parameters. So basically the "correct" code to check if something like java.lang.String is open to Groovy would be: Module groovyModule = CachedClass.class.getModule(); // org.codehaus.groovy.reflection.CachedClass; Class clazz = String.class; // to test if open return clazz.getModule().isOpen(String.class.getPackage().getName(), groovyModule); If I do this, it returns "true" for String, Object or any other class. So the behaviour is consistent. I implemented this check as a single MethodHandle to a precompiled method that takes a Class and returns true/false if the Class is open to Groovy's module: https://goo.gl/XvdCQK By this it's possible to execute this without a Java 9 at compile time. Unfortunately, it doesn't help, because java.base is open to unnamed module But now it is impossible for us to check, if something is not open by default. So, to come back to the previous discussion, it is now impossible to make everything accessible (as if illegal-access=deny). This makes migration to Java 10 hard for some projects, because you have to live with warnings that are printed by default, but you can't check if something is allowed without printing a warning. That's not good. IMHO, this should be improved by: - adding an API to do the checks, ignoring illegal-access settings - make the runtime not open by default and instead just allow setAccessible on the java.* modules with printing a warning. Uwe From Alan.Bateman at oracle.com Tue Jul 11 10:11:42 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 11 Jul 2017 11:11:42 +0100 Subject: =?UTF-8?Q?Re:_trySetAccessible=e2=80=8b?= In-Reply-To: <03f801d2fa26$5c49d710$14dd8530$@apache.org> References: <64e937e7-4a60-7a09-ae6e-1fa816e510d4@oracle.com> <01ce01d2f958$a5843930$f08cab90$@apache.org> <027401d2f991$9736c990$c5a45cb0$@apache.org> <5a9430e0-8bde-b15b-2be1-5a4337525a21@oracle.com> <03f801d2fa26$5c49d710$14dd8530$@apache.org> Message-ID: On 11/07/2017 10:16, Uwe Schindler wrote: > : > Sorry, I mixed up the parameters. So basically the "correct" code to check if something like java.lang.String is open to Groovy would be: > > Module groovyModule = CachedClass.class.getModule(); // org.codehaus.groovy.reflection.CachedClass; > Class clazz = String.class; // to test if open > return clazz.getModule().isOpen(String.class.getPackage().getName(), groovyModule); > > If I do this, it returns "true" for String, Object or any other class. So the behaviour is consistent. Yes, it has to be consistent. As an aside, you can replace getPackage().getName() with getPackageName() - it's more efficient and avoids the NPE when the class is an array or primitive. > > I implemented this check as a single MethodHandle to a precompiled method that takes a Class and returns true/false if the Class is open to Groovy's module: https://goo.gl/XvdCQK > By this it's possible to execute this without a Java 9 at compile time. Unfortunately, it doesn't help, because java.base is open to unnamed module Right, although isOpen("java.lang") will return false because the package is not open to all modules. > > But now it is impossible for us to check, if something is not open by default. Module::getDescriptor will return the module descriptor for named modules. So in this case, Object.class.getModule().getDescriptor() returns the ModuleDescriptor for java.base so you can inspect the packages and which are exported and/or opened before being changed by runtime. So there is enough in the API to determine which packages have been opened at runtime (either via CLI options or APIs). -Alan From blackdrag at gmx.org Tue Jul 11 14:37:14 2017 From: blackdrag at gmx.org (Jochen Theodorou) Date: Tue, 11 Jul 2017 16:37:14 +0200 Subject: =?UTF-8?Q?Re:_trySetAccessible=e2=80=8b?= In-Reply-To: References: <64e937e7-4a60-7a09-ae6e-1fa816e510d4@oracle.com> <01ce01d2f958$a5843930$f08cab90$@apache.org> <027401d2f991$9736c990$c5a45cb0$@apache.org> <5a9430e0-8bde-b15b-2be1-5a4337525a21@oracle.com> <03f801d2fa26$5c49d710$14dd8530$@apache.org> Message-ID: <1de9051a-efc3-4c65-764d-39306d7fb6f6@gmx.org> On 11.07.2017 12:11, Alan Bateman wrote: > On 11/07/2017 10:16, Uwe Schindler wrote: [...] >> >> But now it is impossible for us to check, if something is not open by >> default. > Module::getDescriptor will return the module descriptor for named > modules. So in this case, Object.class.getModule().getDescriptor() > returns the ModuleDescriptor for java.base so you can inspect the > packages and which are exported and/or opened before being changed by > runtime. So there is enough in the API to determine which packages have > been opened at runtime (either via CLI options or APIs). we need that on the level of a class member. Not every method in a class from an exported package is accessible or has been made accessible via runtime mechanisms. bye Jochen From Alan.Bateman at oracle.com Tue Jul 11 17:24:28 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 11 Jul 2017 18:24:28 +0100 Subject: =?UTF-8?Q?Re:_trySetAccessible=e2=80=8b?= In-Reply-To: <1de9051a-efc3-4c65-764d-39306d7fb6f6@gmx.org> References: <64e937e7-4a60-7a09-ae6e-1fa816e510d4@oracle.com> <01ce01d2f958$a5843930$f08cab90$@apache.org> <027401d2f991$9736c990$c5a45cb0$@apache.org> <5a9430e0-8bde-b15b-2be1-5a4337525a21@oracle.com> <03f801d2fa26$5c49d710$14dd8530$@apache.org> <1de9051a-efc3-4c65-764d-39306d7fb6f6@gmx.org> Message-ID: <73121b0f-3ee0-b2d0-6f42-a66091175848@oracle.com> On 11/07/2017 15:37, Jochen Theodorou wrote: > : > > we need that on the level of a class member. Not every method in a > class from an exported package is accessible or has been made > accessible via runtime mechanisms. The CLI options don't change the class or member modifiers so you should be able to combine those with the module definitions to determine the accessibility (core reflection assumes readability so you don't need to be concerned with that). -Alan From oleg.tsalko at gmail.com Thu Jul 13 07:34:53 2017 From: oleg.tsalko at gmail.com (Oleg Tsal-Tsalko) Date: Thu, 13 Jul 2017 10:34:53 +0300 Subject: Jigsaw questions Message-ID: Dear experts, I'm from JUG UA and currently playing with new Java 9 Module System using Early Access Jigsaw build #174. As an exercise I'm modularising JUnit 5. In process I faced couple of issues and have couple of questions to you: 1. *How to compile test classes that are packaged in same packages as production code? *When I'm trying to compile test sources separately from application sources that have been already modularised (packaged in modules) I'm getting errors saying that particular packages already found in certain modules on module path. What are recommendations (best practice) here? 2. When I'm trying to run unit tests placed on classpath using modularised JUnit5 library put on module path I'm getting errors like "*Could not load class with name: org.junit.platform.commons.util.CollectionUtilsTests*". I have deduced that it is because CollectionUtilsTests class lives in same package as already exists in junit.platform.commons module placed on module path. If I run org.junit.mytests.SimpleTest from custom unique package instead everything works fine. My question is more general here though: *how to deal (access via reflection for example) with classes on classpath that use same packages as certain modules on module path?* We can't (it will be very difficult and inconvenient) ensure that no library on classpath uses same package as some of the modules on module path... Could you please clarify these aspects to me please or point me where I can read about it? Thank you, Oleg From forax at univ-mlv.fr Thu Jul 13 09:30:10 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 13 Jul 2017 11:30:10 +0200 (CEST) Subject: Jigsaw questions In-Reply-To: References: Message-ID: <1120760609.908617.1499938210050.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Oleg Tsal-Tsalko" > ?: jigsaw-dev at openjdk.java.net > Envoy?: Jeudi 13 Juillet 2017 09:34:53 > Objet: Jigsaw questions > Dear experts, > > I'm from JUG UA and currently playing with new Java 9 Module System using > Early Access Jigsaw build #174. As an exercise I'm modularising JUnit 5. In > process I faced couple of issues and have couple of questions to you: > > 1. *How to compile test classes that are packaged in same packages as > production code? *When I'm trying to compile test sources separately > from application sources that have been already modularised (packaged in > modules) I'm getting errors saying that particular packages already found > in certain modules on module path. What are recommendations (best practice) > here? --patch-module is your friend. The other solution is to put the test classes in another module and to be able to merge module (the tested module and the test module) but it requires support either by the build tool you use or by JUnit itself. > 2. When I'm trying to run unit tests placed on classpath using > modularised JUnit5 library put on module path I'm getting errors > like "*Could > not load class with > name: org.junit.platform.commons.util.CollectionUtilsTests*". I have > deduced that it is because CollectionUtilsTests class lives in same > package as already exists in junit.platform.commons module placed on > module path. If I run org.junit.mytests.SimpleTest from custom unique > package instead everything works fine. My question is more general here > though: *how to deal (access via reflection for example) with classes on > classpath that use same packages as certain modules on module path?* We > can't (it will be very difficult and inconvenient) ensure that no library > on classpath uses same package as some of the modules on module path... Christian Stein (sormuras on Github) has already played with running JUnit5 on Java 9, see https://github.com/sormuras/application-junit5-jdk9-demo and for your second question, you can't, a package should be in only one module at a time (a package in the classpath is part of the unamed module), that's why you have to use --path-module to put all the test classes with the tested classes in the same package inside the same module. > > Could you please clarify these aspects to me please or point me where I can > read about it? > > Thank you, > Oleg cheers, R?mi From peter.abeles at gmail.com Thu Jul 13 16:21:24 2017 From: peter.abeles at gmail.com (Peter A) Date: Thu, 13 Jul 2017 09:21:24 -0700 Subject: Provide access to data offset in WritableRaster in Java 9 Message-ID: Apologies since this probably not the correct list, but I was referenced here from another Java list. Background: The high level API in a BufferedImage is very very very slow. To get around that problem, in previous versions of Java, the internal rasters which were defined in sun.awt.image were accessed. Doing so enabled real-time computer vision in Java. Problem: Accessing the low level Rasters is no longer practical in Java 9. After this problem was reported by one of my users I looked into it and found a work around, for most situations. Unfortunately the higher level WritableRaster does not provide access to the offset inside its internal data array. This makes processing of subimages impossible. My suspicion is that it is most likely an oversight because it provides access to every other piece of information needed and the raw data. It would be great if getDataOffset() could be moved into WritableRaster or one of its parents instead of being hidden in children of WritableRaster. Just to clarify the raw arrays are stored inside of a DataBuffer and that data structure contains an offset. This offset is always set to zero and the offset inside of WritableRaster is what is needed, e.g. IntegerInterleavedRaster.getDataOffsets(). Thanks, - Peter -- "Now, now my good man, this is no time for making enemies." ? Voltaire (1694-1778), on his deathbed in response to a priest asking that he renounce Satan. From Alan.Bateman at oracle.com Thu Jul 13 17:47:20 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 13 Jul 2017 18:47:20 +0100 Subject: Provide access to data offset in WritableRaster in Java 9 In-Reply-To: References: Message-ID: <2fc2855b-8644-0391-4be6-93505ce3bfbc@oracle.com> The 2d-dev or awt-dev mailing lists may be a better place to bring this up. -Alan On 13/07/2017 17:21, Peter A wrote: > Apologies since this probably not the correct list, but I was referenced > here from another Java list. > > Background: > The high level API in a BufferedImage is very very very slow. To get > around that problem, in previous versions of Java, the internal rasters > which were defined in sun.awt.image were accessed. Doing so enabled > real-time computer vision in Java. > > Problem: > Accessing the low level Rasters is no longer practical in Java 9. After > this problem was reported by one of my users I looked into it and found a > work around, for most situations. Unfortunately the higher level > WritableRaster does not provide access to the offset inside its internal > data array. This makes processing of subimages impossible. My suspicion > is that it is most likely an oversight because it provides access to every > other piece of information needed and the raw data. It would be great > if getDataOffset() could be moved into WritableRaster or one of its parents > instead of being hidden in children of WritableRaster. > > Just to clarify the raw arrays are stored inside of a DataBuffer and that > data structure contains an offset. This offset is always set to zero and > the offset inside of WritableRaster is what is needed, > e.g. IntegerInterleavedRaster.getDataOffsets(). > > Thanks, > - Peter > From philip.race at oracle.com Thu Jul 13 18:22:38 2017 From: philip.race at oracle.com (Phil Race) Date: Thu, 13 Jul 2017 11:22:38 -0700 Subject: Provide access to data offset in WritableRaster in Java 9 In-Reply-To: <2fc2855b-8644-0391-4be6-93505ce3bfbc@oracle.com> References: <2fc2855b-8644-0391-4be6-93505ce3bfbc@oracle.com> Message-ID: <36f4529f-897f-0a9f-26f4-8bed6ab1789c@oracle.com> Hi Peter, 2d-dev would be the right list. Sounds like you were accessing jdk internals and found that you mostly can do away with that except for sub-images. What you should really do is file an issue at bugs.java.com as client-libs/2d for cat/subcat. If this had been raised earlier in JDK 9 development - we could have looked into it in time. Now it will have to wait for a follow on release. -phil. On 07/13/2017 10:47 AM, Alan Bateman wrote: > The 2d-dev or awt-dev mailing lists may be a better place to bring > this up. > > -Alan > > On 13/07/2017 17:21, Peter A wrote: >> Apologies since this probably not the correct list, but I was referenced >> here from another Java list. >> >> Background: >> The high level API in a BufferedImage is very very very slow. To get >> around that problem, in previous versions of Java, the internal rasters >> which were defined in sun.awt.image were accessed. Doing so enabled >> real-time computer vision in Java. >> >> Problem: >> Accessing the low level Rasters is no longer practical in Java 9. After >> this problem was reported by one of my users I looked into it and >> found a >> work around, for most situations. Unfortunately the higher level >> WritableRaster does not provide access to the offset inside its internal >> data array. This makes processing of subimages impossible. My >> suspicion >> is that it is most likely an oversight because it provides access to >> every >> other piece of information needed and the raw data. It would be great >> if getDataOffset() could be moved into WritableRaster or one of its >> parents >> instead of being hidden in children of WritableRaster. >> >> Just to clarify the raw arrays are stored inside of a DataBuffer and >> that >> data structure contains an offset. This offset is always set to zero and >> the offset inside of WritableRaster is what is needed, >> e.g. IntegerInterleavedRaster.getDataOffsets(). >> >> Thanks, >> - Peter >> > From peter.abeles at gmail.com Thu Jul 13 19:16:32 2017 From: peter.abeles at gmail.com (Peter A) Date: Thu, 13 Jul 2017 12:16:32 -0700 Subject: Provide access to data offset in WritableRaster in Java 9 In-Reply-To: <36f4529f-897f-0a9f-26f4-8bed6ab1789c@oracle.com> References: <2fc2855b-8644-0391-4be6-93505ce3bfbc@oracle.com> <36f4529f-897f-0a9f-26f4-8bed6ab1789c@oracle.com> Message-ID: Thanks! I've posted a message to that mailing list and will create a bug report after a short discussion with them. - Peter On Thu, Jul 13, 2017 at 11:22 AM, Phil Race wrote: > Hi Peter, > > 2d-dev would be the right list. > > Sounds like you were accessing jdk internals and found that you > mostly can do away with that except for sub-images. > > What you should really do is file an issue at bugs.java.com as > client-libs/2d for cat/subcat. > > If this had been raised earlier in JDK 9 development - we could have > looked into > it in time. Now it will have to wait for a follow on release. > > -phil. > > > On 07/13/2017 10:47 AM, Alan Bateman wrote: > >> The 2d-dev or awt-dev mailing lists may be a better place to bring this >> up. >> >> -Alan >> >> On 13/07/2017 17:21, Peter A wrote: >> >>> Apologies since this probably not the correct list, but I was referenced >>> here from another Java list. >>> >>> Background: >>> The high level API in a BufferedImage is very very very slow. To get >>> around that problem, in previous versions of Java, the internal rasters >>> which were defined in sun.awt.image were accessed. Doing so enabled >>> real-time computer vision in Java. >>> >>> Problem: >>> Accessing the low level Rasters is no longer practical in Java 9. After >>> this problem was reported by one of my users I looked into it and found a >>> work around, for most situations. Unfortunately the higher level >>> WritableRaster does not provide access to the offset inside its internal >>> data array. This makes processing of subimages impossible. My >>> suspicion >>> is that it is most likely an oversight because it provides access to >>> every >>> other piece of information needed and the raw data. It would be great >>> if getDataOffset() could be moved into WritableRaster or one of its >>> parents >>> instead of being hidden in children of WritableRaster. >>> >>> Just to clarify the raw arrays are stored inside of a DataBuffer and that >>> data structure contains an offset. This offset is always set to zero and >>> the offset inside of WritableRaster is what is needed, >>> e.g. IntegerInterleavedRaster.getDataOffsets(). >>> >>> Thanks, >>> - Peter >>> >>> >> > -- "Now, now my good man, this is no time for making enemies." ? Voltaire (1694-1778), on his deathbed in response to a priest asking that he renounce Satan. From stephan.herrmann at berlin.de Mon Jul 17 10:59:32 2017 From: stephan.herrmann at berlin.de (Stephan Herrmann) Date: Mon, 17 Jul 2017 12:59:32 +0200 Subject: package hierarchy? Message-ID: <14661562-84ed-32b1-4314-bf8c6fb831cb@berlin.de> This continues a discussion we had in January, but still isn't fully resolved in JLS 2017-06-26: Does the parent-sub relation of packages bear any meaning from the JLS p.o.v.? On 2017-01-10 Alex conceded: "... you can consider all packages as unrelated to each other." Still JLS 6.5.3.2 has this (my emphasis): "If a package name is of the form Q.Id, then Q must also be a package name. The package name Q.Id names a package that is the member named Id *within the package named by Q*. If Q does not name an observable package (?7.4.3), or Id is not the simple name of an observable subpackage of that package, then a compile-time error occurs. If Q.Id does not name a package that is uniquely visible to the current module (?7.4.3), then a compile-time error occurs." Now, what's the meaning of "the package named by Q"? Technically, we need to consider Q as a package name, whose meaning is determined by 6.5.3.1 or 6.5.3.2. This inevitably implies that Q must be uniquely visible. In the end, this requires, e.g., that package "java" be uniquely visible in every Java 9 program. Or: every Java 9 program (even JDK itself) is illegal. I *imagine*, the spec authors intended two different definitions of PackageName: an internal definition that is applied whenever JLS itself refers to a package name, and an external, applicable to type or package references in the source code. I imagine, only the external definition has to apply the second paragraph requiring unique visibility, whereas internal references to PackageName should be unaffected by this addition. *Perhaps*, the phrase "If Q does not name an observable package" intends to override the normal interpretation of package names, to require only observability, not unique visibility, but this doesn't work if first name resolution is obliged to check unique visibility and possibly fail compilation. Now correcting JLS in its current form will be quite tedious, like: "within a package that is identified by the name Q, by applying 6.5.3 recursively while ignoring any requirement of unique visibility". Yikes. am I missing anything? Stephan Ceterum censeo ... I'm really looking forward to the day, when JLS is refactored to specify the language with no parent-sub package relation whatsoever, leaving it entirely to any host system, to use prefixes of package names for grouping stuff in containers like folders of a file system. Wouldn't that make for a much cleaner specification? OTOH, wherever JLS and compiler messages surface the concept of a package "hierarchy", it will influence user expectations: Having learned about package hierarchies users may likely expect that exporting package "p1.p2" will also make "p1.p2.p3" accessible just like "p1.p2.MyClass". From alex.buckley at oracle.com Mon Jul 17 19:23:32 2017 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 17 Jul 2017 12:23:32 -0700 Subject: package hierarchy? In-Reply-To: <14661562-84ed-32b1-4314-bf8c6fb831cb@berlin.de> References: <14661562-84ed-32b1-4314-bf8c6fb831cb@berlin.de> Message-ID: <596D0EB4.4050102@oracle.com> The quote from 6.5.3.2 is incorrect -- the paragraph beginning "If Q does not name ..." is deleted. We discussed this in May, where I explained why the section is the way it is. See http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012779.html. I have also explained that the meaning of the qualified package name Q.Id is NOT specified in terms of the simple package name Q. See http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012488.html. That's why there is no requirement in 6.5.3.2 that Q be uniquely visible, only Q.Id. Stepping back, you seem to have a concern that the spec no longer relies on hierarchy to give meaning to packages yet continues to present subpackages as a feature of the language; and you believe this is a tension that will have deleterious effects on ordinary developers. I do not believe it will, because ordinary developers have always understood that a package-access type in package p1.p2 is NOT accessible from the "related, but not really" package p1.p2.p3. In the modular world, I do not believe that a developer who exports p1.p2 has any expectation that p1.p2.p3 is exported too. We deliberately designed the syntax of exports -- one package per 'exports', no wildcards, no duplicates -- to ensure explicit, methodical enumeration of the packages which represent the module's contract with the outside world. Alex On 7/17/2017 3:59 AM, Stephan Herrmann wrote: > This continues a discussion we had in January, but still isn't > fully resolved in JLS 2017-06-26: > > Does the parent-sub relation of packages bear any meaning > from the JLS p.o.v.? > > On 2017-01-10 Alex conceded: > "... you can consider all packages as unrelated to each other." > > Still JLS 6.5.3.2 has this (my emphasis): > > "If a package name is of the form Q.Id, then Q must also be a package name. > The package name Q.Id names a package that is the member named Id > *within the package named by Q*. > If Q does not name an observable package (?7.4.3), or Id is not the > simple name > of an observable subpackage of that package, then a compile-time error > occurs. > > If Q.Id does not name a package that is uniquely visible to the current > module (?7.4.3), then a compile-time error occurs." > > Now, what's the meaning of "the package named by Q"? > > Technically, we need to consider Q as a package name, whose meaning > is determined by 6.5.3.1 or 6.5.3.2. > This inevitably implies that Q must be uniquely visible. > > In the end, this requires, e.g., that package "java" be uniquely visible in > every Java 9 program. Or: every Java 9 program (even JDK itself) is > illegal. > > > > I *imagine*, the spec authors intended two different definitions of > PackageName: an internal definition that is applied whenever JLS > itself refers to a package name, and an external, applicable to > type or package references in the source code. > I imagine, only the external definition has to apply the second > paragraph requiring unique visibility, whereas internal references > to PackageName should be unaffected by this addition. > > *Perhaps*, the phrase "If Q does not name an observable package" > intends to override the normal interpretation of package names, to > require only observability, not unique visibility, but this doesn't > work if first name resolution is obliged to check unique visibility > and possibly fail compilation. > > Now correcting JLS in its current form will be quite tedious, like: > "within a package that is identified by the name Q, by applying > 6.5.3 recursively while ignoring any requirement of unique visibility". > Yikes. > > am I missing anything? > Stephan > > Ceterum censeo ... > I'm really looking forward to the day, when JLS is refactored to > specify the language with no parent-sub package relation whatsoever, > leaving it entirely to any host system, to use prefixes of package > names for grouping stuff in containers like folders of a file system. > Wouldn't that make for a much cleaner specification? > > OTOH, wherever JLS and compiler messages surface the concept of > a package "hierarchy", it will influence user expectations: Having > learned about package hierarchies users may likely expect that > exporting package "p1.p2" will also make "p1.p2.p3" accessible > just like "p1.p2.MyClass". From volker.simonis at gmail.com Thu Jul 27 13:31:19 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 27 Jul 2017 15:31:19 +0200 Subject: "The State of the Module System" should be marked as outdated Message-ID: Hi, I think this has been mentioned before, but "The State of the Module System" under http://openjdk.java.net/projects/jigsaw/spec/sotms/ is outdated and constantly keeps confusing people. E.g. it still uses "requires public" instead of "requires transitive" Can you please either update the document or put a banner on top of that page which mentions that it is at least partially outdated (maybe with a link to the latest version of the specification). Thank you and best regards, Volker From mark.reinhold at oracle.com Thu Jul 27 16:51:08 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 27 Jul 2017 09:51:08 -0700 Subject: "The State of the Module System" should be marked as outdated In-Reply-To: References: Message-ID: <20170727095108.356315161@eggemoggin.niobe.net> 2017/7/27 6:31:19 -0700, volker.simonis at gmail.com: > I think this has been mentioned before, but "The State of the Module > System" under http://openjdk.java.net/projects/jigsaw/spec/sotms/ is > outdated and constantly keeps confusing people. E.g. it still uses > "requires public" instead of "requires transitive" A major update of this document is in preparation. In the meantime I've added an explanatory note to the top of the current version. - Mark