Re: Exporting a package with no Java sources
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
Re: javap cannot read module-info.class
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@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@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
Re: Cleanly starting apps on Java 9 and earlier
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.
Re: javap cannot read module-info.class
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
Re: javap cannot read module-info.class
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@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@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
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
RE: Cleanly starting apps on Java 9 and earlier
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@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
gradle 3.x runs without setting _JAVA_OPTIONS on jdk-9+175 (and later)
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
Re: Cleanly starting apps on Java 9 and earlier
Il sab 1 lug 2017, 11:53 Alan Batemanha 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
Re: Exporting a package with no Java sources
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
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
Cleanly starting apps on Java 9 and earlier
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
Re: Exporting a package with no Java sources
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 >
hg: jigsaw/jake/nashorn: 2 new changesets
Changeset: b25986e36b28 Author:lana Date: 2017-06-29 17:26 + 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
hg: jigsaw/jake/corba: 2 new changesets
Changeset: 76cebcdca958 Author:lana Date: 2017-06-29 17:26 + 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
hg: jigsaw/jake/jaxp: 2 new changesets
Changeset: 332ad9f92632 Author:lana Date: 2017-06-29 17:26 + 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
hg: jigsaw/jake/hotspot: 3 new changesets
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 + 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
hg: jigsaw/jake/jdk: 4 new changesets
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.pa...@oracle.com, jonathan.gibb...@oracle.com ! make/src/classes/build/tools/taglet/ModuleGraph.java Changeset: 473db5c4c2c9 Author:lana Date: 2017-06-29 17:26 + 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
hg: jigsaw/jake/jaxws: 2 new changesets
Changeset: 880541212285 Author:lana Date: 2017-06-29 17:26 + 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
hg: jigsaw/jake/langtools: 3 new changesets
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.pa...@oracle.com, jonathan.gibb...@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 + 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