From alan.bateman at oracle.com Thu Jun 1 19:45:47 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 01 Jun 2017 19:45:47 +0000 Subject: hg: jigsaw/jake/jdk: More clean-up and additions to ServiceLoader tests Message-ID: <201706011945.v51Jjl1S004288@aojmv0008.oracle.com> Changeset: fa1a0ceecb2a Author: alanb Date: 2017-06-01 20:44 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fa1a0ceecb2a More clean-up and additions to ServiceLoader tests ! test/java/util/ServiceLoader/ModulesTest.java - test/java/util/ServiceLoader/NoInheritanceTest.java - test/java/util/ServiceLoader/NoUsesTest.java + test/java/util/ServiceLoader/classpath/pearscript/META-INF/services/javax.script.ScriptEngineFactory + test/java/util/ServiceLoader/classpath/pearscript/org/pear/PearScript.java + test/java/util/ServiceLoader/classpath/pearscript/org/pear/PearScriptEngineFactory.java + test/java/util/ServiceLoader/inheritance/NoInheritanceTest.java + test/java/util/ServiceLoader/inheritance/test/module-info.java + test/java/util/ServiceLoader/inheritance/test/p/Main.java - test/java/util/ServiceLoader/modules/noinheritance/module-info.java - test/java/util/ServiceLoader/modules/noinheritance/test/Main.java - test/java/util/ServiceLoader/modules/nouses/module-info.java - test/java/util/ServiceLoader/modules/nouses/test/Main.java + test/java/util/ServiceLoader/nouses/NoUsesTest.java + test/java/util/ServiceLoader/nouses/test/module-info.java + test/java/util/ServiceLoader/nouses/test/p/Main.java + test/java/util/ServiceLoader/security/SecurityTest.java + test/java/util/ServiceLoader/security/test/module-info.java + test/java/util/ServiceLoader/security/test/p/Tests.java - test/java/util/ServiceLoader/src/pearscript/META-INF/services/javax.script.ScriptEngineFactory - test/java/util/ServiceLoader/src/pearscript/org/pear/PearScript.java - test/java/util/ServiceLoader/src/pearscript/org/pear/PearScriptEngineFactory.java From alan.bateman at oracle.com Thu Jun 1 19:47:00 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 01 Jun 2017 19:47:00 +0000 Subject: hg: jigsaw/jake: 3 new changesets Message-ID: <201706011947.v51Jl0QF005159@aojmv0008.oracle.com> Changeset: 2c25fc241032 Author: ihse Date: 2017-05-29 09:18 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/2c25fc241032 8175824: Adapt javadoc generation to different requirements for JDK and JavaSE Reviewed-by: erikj, mchung ! make/Docs.gmk ! make/common/MakeBase.gmk Changeset: d7537347a652 Author: lana Date: 2017-06-01 18:26 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/d7537347a652 Added tag jdk-9+172 for changeset 2c25fc241032 ! .hgtags Changeset: e996ea5ccc71 Author: alanb Date: 2017-06-01 19:41 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/e996ea5ccc71 Merge ! .hgtags ! make/Docs.gmk ! make/common/MakeBase.gmk From alan.bateman at oracle.com Thu Jun 1 19:47:00 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 01 Jun 2017 19:47:00 +0000 Subject: hg: jigsaw/jake/corba: 2 new changesets Message-ID: <201706011947.v51Jl0Ik005186@aojmv0008.oracle.com> Changeset: b5f3f4fc6b93 Author: lana Date: 2017-06-01 18:26 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/b5f3f4fc6b93 Added tag jdk-9+172 for changeset 95ed14547ca9 ! .hgtags Changeset: 094bc8c2868d Author: alanb Date: 2017-06-01 19:42 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/094bc8c2868d Merge ! .hgtags From alan.bateman at oracle.com Thu Jun 1 19:47:03 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 01 Jun 2017 19:47:03 +0000 Subject: hg: jigsaw/jake/langtools: 4 new changesets Message-ID: <201706011947.v51Jl3LT005339@aojmv0008.oracle.com> Changeset: 0eedec5776e4 Author: lana Date: 2017-05-23 23:26 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/0eedec5776e4 8180167: JDK9 message drop 40 l10n resource file updates Reviewed-by: alanb, mchung, dfuchs, rfield, shinyafox, weijun, joehw Contributed-by: li.jiang at oracle.com ! src/jdk.compiler/share/classes/com/sun/tools/doclint/resources/doclint_ja.properties ! src/jdk.compiler/share/classes/com/sun/tools/doclint/resources/doclint_zh_CN.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_ja.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_ja.properties ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_zh_CN.properties ! src/jdk.javadoc/share/classes/com/sun/tools/javadoc/resources/javadoc_ja.properties ! src/jdk.javadoc/share/classes/com/sun/tools/javadoc/resources/javadoc_zh_CN.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard_ja.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard_zh_CN.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_ja.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_zh_CN.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/resources/javadoc_ja.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/resources/javadoc_zh_CN.properties ! src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/resources/jdeprscan_ja.properties ! src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/resources/jdeprscan_zh_CN.properties ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps_ja.properties ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_ja.properties ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_zh_CN.properties Changeset: 03669efa77f5 Author: lana Date: 2017-05-26 00:45 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/03669efa77f5 Merge Changeset: 16febc896c36 Author: lana Date: 2017-06-01 18:26 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/16febc896c36 Added tag jdk-9+172 for changeset 03669efa77f5 ! .hgtags Changeset: a5e8b958d3da Author: alanb Date: 2017-06-01 19:43 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/a5e8b958d3da Merge ! .hgtags From alan.bateman at oracle.com Thu Jun 1 19:47:02 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 01 Jun 2017 19:47:02 +0000 Subject: hg: jigsaw/jake/jaxws: 2 new changesets Message-ID: <201706011947.v51Jl2HG005335@aojmv0008.oracle.com> Changeset: 2bd967aa452c Author: lana Date: 2017-06-01 18:26 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/2bd967aa452c Added tag jdk-9+172 for changeset 8c615099f3e3 ! .hgtags Changeset: 0c5b2fc601da Author: alanb Date: 2017-06-01 19:48 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/0c5b2fc601da Merge ! .hgtags From alan.bateman at oracle.com Thu Jun 1 19:47:04 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 01 Jun 2017 19:47:04 +0000 Subject: hg: jigsaw/jake/nashorn: 2 new changesets Message-ID: <201706011947.v51Jl4x4005346@aojmv0008.oracle.com> Changeset: fa8e4de50e82 Author: lana Date: 2017-06-01 18:26 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/fa8e4de50e82 Added tag jdk-9+172 for changeset c8d6b740f0f7 ! .hgtags Changeset: 0da811617c4f Author: alanb Date: 2017-06-01 19:44 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/0da811617c4f Merge ! .hgtags From alan.bateman at oracle.com Thu Jun 1 19:47:05 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 01 Jun 2017 19:47:05 +0000 Subject: hg: jigsaw/jake/jaxp: 5 new changesets Message-ID: <201706011947.v51Jl5Gc005391@aojmv0008.oracle.com> Changeset: 0f9c0239ff0c Author: lana Date: 2017-05-23 23:27 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/0f9c0239ff0c 8180167: JDK9 message drop 40 l10n resource file updates Reviewed-by: alanb, mchung, dfuchs, rfield, shinyafox, weijun, joehw Contributed-by: li.jiang at oracle.com ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_ko.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_sv.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ko.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_ko.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_ko.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_sv.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ko.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_ko.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_sv.properties ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/res/XMLErrorResources_ko.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/res/XMLErrorResources_sv.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_ko.java ! src/java.xml/share/classes/javax/xml/catalog/CatalogMessages_de.properties ! src/java.xml/share/classes/javax/xml/catalog/CatalogMessages_es.properties ! src/java.xml/share/classes/javax/xml/catalog/CatalogMessages_fr.properties ! src/java.xml/share/classes/javax/xml/catalog/CatalogMessages_it.properties ! src/java.xml/share/classes/javax/xml/catalog/CatalogMessages_ja.properties ! src/java.xml/share/classes/javax/xml/catalog/CatalogMessages_ko.properties ! src/java.xml/share/classes/javax/xml/catalog/CatalogMessages_pt_BR.properties ! src/java.xml/share/classes/javax/xml/catalog/CatalogMessages_sv.properties ! src/java.xml/share/classes/javax/xml/catalog/CatalogMessages_zh_CN.properties ! src/java.xml/share/classes/javax/xml/catalog/CatalogMessages_zh_TW.properties Changeset: a208fa9beeee Author: joehw Date: 2017-05-24 14:10 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/a208fa9beeee 8180349: Review JAXP Java SE 9 API javadocs Reviewed-by: rriggs, lancea + src/java.xml/share/classes/javax/xml/catalog/package-info.java - src/java.xml/share/classes/javax/xml/catalog/package.html + src/java.xml/share/classes/javax/xml/datatype/package-info.java - src/java.xml/share/classes/javax/xml/datatype/package.html + src/java.xml/share/classes/javax/xml/namespace/package-info.java - src/java.xml/share/classes/javax/xml/namespace/package.html + src/java.xml/share/classes/javax/xml/package-info.java + src/java.xml/share/classes/javax/xml/parsers/package-info.java - src/java.xml/share/classes/javax/xml/parsers/package.html + src/java.xml/share/classes/javax/xml/stream/events/package-info.java + src/java.xml/share/classes/javax/xml/stream/package-info.java + src/java.xml/share/classes/javax/xml/stream/util/package-info.java + src/java.xml/share/classes/javax/xml/transform/dom/package-info.java - src/java.xml/share/classes/javax/xml/transform/dom/package.html + src/java.xml/share/classes/javax/xml/transform/package-info.java - src/java.xml/share/classes/javax/xml/transform/package.html + src/java.xml/share/classes/javax/xml/transform/sax/package-info.java - src/java.xml/share/classes/javax/xml/transform/sax/package.html + src/java.xml/share/classes/javax/xml/transform/stax/package-info.java - src/java.xml/share/classes/javax/xml/transform/stax/package.html + src/java.xml/share/classes/javax/xml/transform/stream/package-info.java - src/java.xml/share/classes/javax/xml/transform/stream/package.html + src/java.xml/share/classes/javax/xml/validation/package-info.java - src/java.xml/share/classes/javax/xml/validation/package.html + src/java.xml/share/classes/javax/xml/xpath/package-info.java - src/java.xml/share/classes/javax/xml/xpath/package.html + src/java.xml/share/classes/org/w3c/dom/bootstrap/package-info.java + src/java.xml/share/classes/org/w3c/dom/events/package-info.java + src/java.xml/share/classes/org/w3c/dom/ls/package-info.java + src/java.xml/share/classes/org/w3c/dom/package-info.java - src/java.xml/share/classes/org/w3c/dom/package.html + src/java.xml/share/classes/org/w3c/dom/ranges/package-info.java - src/java.xml/share/classes/org/w3c/dom/ranges/package.html + src/java.xml/share/classes/org/w3c/dom/traversal/package-info.java + src/java.xml/share/classes/org/w3c/dom/views/package-info.java + src/java.xml/share/classes/org/xml/sax/ext/package-info.java - src/java.xml/share/classes/org/xml/sax/ext/package.html + src/java.xml/share/classes/org/xml/sax/helpers/package-info.java - src/java.xml/share/classes/org/xml/sax/helpers/package.html + src/java.xml/share/classes/org/xml/sax/package-info.java - src/java.xml/share/classes/org/xml/sax/package.html Changeset: eedb6e54c8bd Author: lana Date: 2017-05-26 00:44 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/eedb6e54c8bd Merge - src/java.xml/share/classes/javax/xml/catalog/package.html - src/java.xml/share/classes/javax/xml/datatype/package.html - src/java.xml/share/classes/javax/xml/namespace/package.html - src/java.xml/share/classes/javax/xml/parsers/package.html - src/java.xml/share/classes/javax/xml/transform/dom/package.html - src/java.xml/share/classes/javax/xml/transform/package.html - src/java.xml/share/classes/javax/xml/transform/sax/package.html - src/java.xml/share/classes/javax/xml/transform/stax/package.html - src/java.xml/share/classes/javax/xml/transform/stream/package.html - src/java.xml/share/classes/javax/xml/validation/package.html - src/java.xml/share/classes/javax/xml/xpath/package.html - src/java.xml/share/classes/org/w3c/dom/package.html - src/java.xml/share/classes/org/w3c/dom/ranges/package.html - src/java.xml/share/classes/org/xml/sax/ext/package.html - src/java.xml/share/classes/org/xml/sax/helpers/package.html - src/java.xml/share/classes/org/xml/sax/package.html Changeset: 9788347e0629 Author: lana Date: 2017-06-01 18:26 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/9788347e0629 Added tag jdk-9+172 for changeset eedb6e54c8bd ! .hgtags Changeset: 2e938b4ca413 Author: alanb Date: 2017-06-01 19:43 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/2e938b4ca413 Merge ! .hgtags - src/java.xml/share/classes/javax/xml/catalog/package.html - src/java.xml/share/classes/javax/xml/datatype/package.html - src/java.xml/share/classes/javax/xml/namespace/package.html - src/java.xml/share/classes/javax/xml/parsers/package.html - src/java.xml/share/classes/javax/xml/transform/dom/package.html - src/java.xml/share/classes/javax/xml/transform/package.html - src/java.xml/share/classes/javax/xml/transform/sax/package.html - src/java.xml/share/classes/javax/xml/transform/stax/package.html - src/java.xml/share/classes/javax/xml/transform/stream/package.html - src/java.xml/share/classes/javax/xml/validation/package.html - src/java.xml/share/classes/javax/xml/xpath/package.html - src/java.xml/share/classes/org/w3c/dom/package.html - src/java.xml/share/classes/org/w3c/dom/ranges/package.html - src/java.xml/share/classes/org/xml/sax/ext/package.html - src/java.xml/share/classes/org/xml/sax/helpers/package.html - src/java.xml/share/classes/org/xml/sax/package.html From alan.bateman at oracle.com Thu Jun 1 19:47:07 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 01 Jun 2017 19:47:07 +0000 Subject: hg: jigsaw/jake/hotspot: 5 new changesets Message-ID: <201706011947.v51Jl7vv005396@aojmv0008.oracle.com> Changeset: 63ac6d565c21 Author: thartmann Date: 2017-05-24 16:53 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/63ac6d565c21 8180813: Null pointer dereference of CodeCache::find_blob() result Summary: Fixed missing null checks on the result of CodeCache::find_blob() found by Parfait. Reviewed-by: shade, kvn ! src/share/vm/code/relocInfo.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 531cb9202a0f Author: lana Date: 2017-05-26 00:45 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/531cb9202a0f Merge Changeset: 1ae9e84f68b3 Author: zmajo Date: 2017-05-29 10:32 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1ae9e84f68b3 8180855: Null pointer dereference in OopMapSet::all_do of oopMap.cpp:394 Summary: Check for possible null-point dereference. Reviewed-by: kvn ! src/share/vm/compiler/oopMap.cpp Changeset: d5ed1e34de8b Author: lana Date: 2017-06-01 18:26 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d5ed1e34de8b Added tag jdk-9+172 for changeset 1ae9e84f68b3 ! .hgtags Changeset: b7de86ca4cc5 Author: alanb Date: 2017-06-01 19:43 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b7de86ca4cc5 Merge ! .hgtags ! src/share/vm/runtime/sharedRuntime.cpp From alan.bateman at oracle.com Thu Jun 1 19:47:13 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 01 Jun 2017 19:47:13 +0000 Subject: hg: jigsaw/jake/jdk: 31 new changesets Message-ID: <201706011947.v51JlElM005568@aojmv0008.oracle.com> Changeset: 82ab8dec02ae Author: dfuchs Date: 2017-05-23 11:33 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/82ab8dec02ae 8180428: Clarify implementation note in Clock.java to match implementation changes made by JDK-8068730 Reviewed-by: dholmes, scolebourne ! src/java.base/share/classes/java/time/Clock.java Changeset: 54e8bad0022c Author: bpb Date: 2017-05-23 11:47 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/54e8bad0022c 8180353: FileOutputStream documentation does not indicate properly whether files get truncated or not Summary: Update documentation of FileOutputStream(String) Reviewed-by: chegar, dfuchs ! src/java.base/share/classes/java/io/FileOutputStream.java Changeset: 321f66c89406 Author: lancea Date: 2017-05-23 16:14 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/321f66c89406 8180728: DatabaseMeta.getRowIdLifetime returns an enum but javadoc refers to int Reviewed-by: joehw, rriggs ! src/java.sql/share/classes/java/sql/DatabaseMetaData.java Changeset: 47032f7eebb1 Author: darcy Date: 2017-05-23 14:34 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/47032f7eebb1 8074977: Constructor.getAnnotatedParameterTypes returns wrong value Summary: Additional comments from plevart and forax Reviewed-by: mchung, alanb ! src/java.base/share/classes/java/lang/reflect/Constructor.java ! src/java.base/share/classes/java/lang/reflect/Executable.java ! src/java.base/share/classes/java/lang/reflect/Method.java ! src/java.base/share/classes/sun/reflect/annotation/TypeAnnotationParser.java + test/java/lang/annotation/TestConstructorParameterAnnotations.java + test/java/lang/annotation/typeAnnotations/TestConstructorParameterTypeAnnotations.java Changeset: d0d971960744 Author: robm Date: 2017-05-24 17:25 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d0d971960744 8175131: sun.rmi.transport.tcp.TCPChannel.createConnection close connection on timeout Reviewed-by: rriggs, msheppar ! src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java Changeset: c162df937880 Author: bpb Date: 2017-05-24 10:52 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c162df937880 8180885: Create test to detect if TimeZone.setDefault affects File.setLastModifiedTime Summary: Check whether File.lastModified is affected by not setting the default time zone or by setting to any of the available time zones. Reviewed-by: dfuchs, rriggs + test/java/io/File/TimeZoneLastModified.java Changeset: e3446d4c7fd2 Author: lana Date: 2017-05-23 23:25 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e3446d4c7fd2 8180167: JDK9 message drop 40 l10n resource file updates Reviewed-by: alanb, mchung, dfuchs, rfield, shinyafox, weijun, joehw Contributed-by: li.jiang at oracle.com ! src/java.base/share/classes/sun/launcher/resources/launcher_de.properties ! src/java.base/share/classes/sun/launcher/resources/launcher_es.properties ! src/java.base/share/classes/sun/launcher/resources/launcher_fr.properties ! src/java.base/share/classes/sun/launcher/resources/launcher_it.properties ! src/java.base/share/classes/sun/launcher/resources/launcher_ja.properties ! src/java.base/share/classes/sun/launcher/resources/launcher_ko.properties ! src/java.base/share/classes/sun/launcher/resources/launcher_pt_BR.properties ! src/java.base/share/classes/sun/launcher/resources/launcher_sv.properties ! src/java.base/share/classes/sun/launcher/resources/launcher_zh_CN.properties ! src/java.base/share/classes/sun/launcher/resources/launcher_zh_TW.properties ! src/java.base/share/classes/sun/security/tools/keytool/Resources_de.java ! src/java.base/share/classes/sun/security/tools/keytool/Resources_es.java ! src/java.base/share/classes/sun/security/tools/keytool/Resources_fr.java ! src/java.base/share/classes/sun/security/tools/keytool/Resources_it.java ! src/java.base/share/classes/sun/security/tools/keytool/Resources_ja.java ! src/java.base/share/classes/sun/security/tools/keytool/Resources_ko.java ! src/java.base/share/classes/sun/security/tools/keytool/Resources_pt_BR.java ! src/java.base/share/classes/sun/security/tools/keytool/Resources_sv.java ! src/java.base/share/classes/sun/security/tools/keytool/Resources_zh_CN.java ! src/java.base/share/classes/sun/security/tools/keytool/Resources_zh_TW.java ! src/java.base/share/classes/sun/security/util/AuthResources_ko.java ! src/java.base/share/classes/sun/security/util/AuthResources_sv.java ! src/java.base/share/classes/sun/security/util/Resources_sv.java ! src/java.desktop/share/classes/com/sun/accessibility/internal/resources/accessibility_sv.properties ! src/java.desktop/share/classes/sun/applet/resources/MsgAppletViewer_ko.java ! src/java.desktop/share/classes/sun/awt/resources/awt_sv.properties ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_ko.properties ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_sv.properties ! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_de.properties ! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_es.properties ! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_fr.properties ! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_it.properties ! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_ja.properties ! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_ko.properties ! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_pt_BR.properties ! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_sv.properties ! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_zh_CN.properties ! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_zh_TW.properties ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_ja.properties ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_zh_CN.properties ! src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod_ja.properties ! src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod_zh_CN.properties ! src/jdk.policytool/share/classes/sun/security/tools/policytool/Resources_sv.java Changeset: 3f350fe1bec8 Author: robm Date: 2017-05-24 22:07 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3f350fe1bec8 8180949: Correctly handle exception in TCPChannel.createConnection Reviewed-by: rriggs ! src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java Changeset: 4e167bc5be91 Author: mli Date: 2017-05-24 19:02 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4e167bc5be91 8180807: java.io.Serializable class-level readObject description error Reviewed-by: chegar, rriggs ! src/java.base/share/classes/java/io/Serializable.java Changeset: bdf91a08aa79 Author: dfuchs Date: 2017-05-25 11:54 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/bdf91a08aa79 8180279: java/net/httpclient/whitebox/Driver.java failed due to timeout Summary: fixed a race condition in RawChannelTest.java Reviewed-by: prappo, michaelm ! test/java/net/httpclient/whitebox/jdk.incubator.httpclient/jdk/incubator/http/RawChannelTest.java Changeset: 400428c4be8b Author: mchung Date: 2017-05-25 10:40 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/400428c4be8b 8181033: Confusing message: A JNI error has occurred, please check your installation and try again Reviewed-by: alanb, dholmes, ksrini ! src/java.base/share/classes/sun/launcher/LauncherHelper.java ! src/java.base/share/classes/sun/launcher/resources/launcher.properties ! test/tools/launcher/MainClassCantBeLoadedTest.java Changeset: 8c879b07e43e Author: lana Date: 2017-05-26 00:45 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8c879b07e43e Merge Changeset: 7b5027da67f7 Author: serb Date: 2017-05-06 13:17 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7b5027da67f7 8178383: Validation of FileIO in the tests for JavaSound should be stricter Reviewed-by: prr ! test/ProblemList.txt ! test/javax/sound/midi/Gervill/RiffReaderWriter/Available.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/Close.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/GetFilePointer.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/GetSize.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/HasNextChunk.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/Read.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadByte.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadByteArrayIntInt.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadInt.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadLong.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadShort.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadString.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadUnsignedByte.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadUnsignedInt.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadUnsignedShort.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/Skip.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/WriteOutputStream.java ! test/javax/sound/sampled/AudioInputStream/FrameLengthAfterConversion.java ! test/javax/sound/sampled/spi/AudioFileReader/ShortHeader.java ! test/javax/sound/sampled/spi/AudioFileWriter/WriterCloseInput.java Changeset: b0d3c98013d0 Author: prr Date: 2017-05-09 12:19 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b0d3c98013d0 Merge ! test/ProblemList.txt - test/sample/TEST.properties - test/sample/chatserver/ChatTest.java - test/sample/mergesort/MergeSortTest.java Changeset: a7c8147f1891 Author: pkbalakr Date: 2017-05-11 12:41 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a7c8147f1891 8179014: JFileChooser with Windows look and feel crashes on win 10 Reviewed-by: prr, serb Contributed-by: ajit.ghaisas at oracle.com ! src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp + test/javax/swing/JFileChooser/GodMode/JFileChooserTest.java Changeset: e4d6ad2be5df Author: psadhukhan Date: 2017-05-12 12:28 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e4d6ad2be5df 8169897: [PIT] javax/swing/plaf/basic/BasicGraphicsUtils/8132119/bug8132119.java fails Reviewed-by: alexsch ! test/javax/swing/plaf/basic/BasicGraphicsUtils/8132119/bug8132119.java Changeset: 4a610c6d0b9c Author: azvegint Date: 2017-05-12 15:01 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4a610c6d0b9c 8178996: [macos] JComboBox doesn't display popup in mixed JavaFX Swing Application on 8u131 and Mac OS 10.12 Reviewed-by: serb, ssadetsky ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java Changeset: 828d3f3728a2 Author: mcherkas Date: 2017-05-15 15:32 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/828d3f3728a2 8175915: NullPointerException from JComboBox and JList when Accessibility enabled Reviewed-by: serb, prr ! src/jdk.accessibility/windows/classes/com/sun/java/accessibility/internal/AccessBridge.java Changeset: 85d12636d9f6 Author: prr Date: 2017-05-17 11:01 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/85d12636d9f6 Merge - src/java.base/share/specs/serialization/changelog.md - src/java.base/share/specs/serialization/images/class.gif Changeset: 046ac3fa2792 Author: ssadetsky Date: 2017-05-19 07:06 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/046ac3fa2792 8179665: [Windows] java.awt.IllegalComponentStateException: component must be showing on the screen to determine its location Reviewed-by: prr, serb ! src/java.desktop/windows/classes/sun/awt/windows/WInputMethod.java ! src/java.desktop/windows/native/libawt/windows/awt_Component.cpp + test/javax/swing/JFrame/AlwaysOnTop/AlwaysOnTopImeTest.java Changeset: c1ddb97ee2ab Author: prr Date: 2017-05-19 14:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c1ddb97ee2ab 8177393: Result of RescaleOp for 4BYTE_ABGR images may be 25% black Reviewed-by: flar, psadhukhan ! src/java.desktop/share/classes/java/awt/image/RescaleOp.java + test/java/awt/image/RescaleOp/ImageRescaleOpTest.java Changeset: a09827296150 Author: prr Date: 2017-05-22 08:54 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a09827296150 Merge - make/data/docs-resources/specs/resources/jdk-default.css Changeset: e748c6a2d2e6 Author: serb Date: 2017-05-22 19:54 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e748c6a2d2e6 8177628: Opensource unit/regression tests for ImageIO Reviewed-by: prr, pnarayanan + test/javax/imageio/AllowSearch.java + test/javax/imageio/AppContextTest.java + test/javax/imageio/AppletResourceTest.html + test/javax/imageio/AppletResourceTest.java + test/javax/imageio/GetNumImages.java + test/javax/imageio/GetReaderWriterInfo.java + test/javax/imageio/IIOImageConstructor.java + test/javax/imageio/ITSDataType.java + test/javax/imageio/ImageIOGetImageReaders.java + test/javax/imageio/ImageIOWriteFile.java + test/javax/imageio/ImageIOWriteNull.java + test/javax/imageio/ImageReadParamPasses.java + test/javax/imageio/ImageReaderGetDestination.java + test/javax/imageio/ImageReaderReadAll.java + test/javax/imageio/ImageStreamFromRAF.java + test/javax/imageio/ImageTypeSpecifierBitsPerBand.java + test/javax/imageio/ImageTypeSpecifierTest.java + test/javax/imageio/ImageWriteParamMisc.java + test/javax/imageio/NullInputOutput.java + test/javax/imageio/PNGSpiStreamMetadata.java + test/javax/imageio/PNGSuffixes.java + test/javax/imageio/ReadBitsTest.java + test/javax/imageio/SetOutput.java + test/javax/imageio/WriteNullImageTest.java + test/javax/imageio/event/WriteProgressListenerTest.java + test/javax/imageio/plugins/bmp/BMPCompressionTest.java + test/javax/imageio/plugins/bmp/BMPPluginTest.java + test/javax/imageio/plugins/bmp/BMPWriteParamTest.java + test/javax/imageio/plugins/bmp/BmpBigDestinationTest.java + test/javax/imageio/plugins/bmp/BmpDefaultImageMetadataTest.java + test/javax/imageio/plugins/bmp/CompressionModeTest.java + test/javax/imageio/plugins/bmp/EmbeddedFormatTest.java + test/javax/imageio/plugins/bmp/EmptyInputBmpMetadataTest.java + test/javax/imageio/plugins/bmp/NoExtraBytesTest.java + test/javax/imageio/plugins/bmp/RLECompressionTest.java + test/javax/imageio/plugins/bmp/ReaderListenersTest.java + test/javax/imageio/plugins/bmp/RleEncodingTest.java + test/javax/imageio/plugins/bmp/TestCompressionBI_BITFIELDS.java + test/javax/imageio/plugins/bmp/Write3ByteBgrTest.java + test/javax/imageio/plugins/bmp/WriteProgressListenerTest.java + test/javax/imageio/plugins/bmp/WritingColorChangeTest.java + test/javax/imageio/plugins/gif/AnimationTest.java + test/javax/imageio/plugins/gif/DisableCompressionTest.java + test/javax/imageio/plugins/gif/EndWriteSequenceTest.java + test/javax/imageio/plugins/gif/IndexingTest.java + test/javax/imageio/plugins/gif/LogicalScreenDimensionTest.java + test/javax/imageio/plugins/gif/OddPaletteTest.java + test/javax/imageio/plugins/gif/PrepareWriteSequenceTest.java + test/javax/imageio/plugins/gif/RGBAnimationTest.java + test/javax/imageio/plugins/gif/RGBImageTest.java + test/javax/imageio/plugins/gif/StreamMetadataTest.java + test/javax/imageio/plugins/gif/TransparencyTest.java + test/javax/imageio/plugins/gif/UshortOutOfMemoryTest.java + test/javax/imageio/plugins/gif/WriteMetadataTest.java + test/javax/imageio/plugins/gif/WriterResetTest.java + test/javax/imageio/plugins/gif/WriterReuseTest.java + test/javax/imageio/plugins/jpeg/ByteBinaryTest.java + test/javax/imageio/plugins/jpeg/CanEncodeIndexed.java + test/javax/imageio/plugins/jpeg/CompressionBug.java + test/javax/imageio/plugins/jpeg/CompressionVals.java + test/javax/imageio/plugins/jpeg/CrashAfterDispose.java + test/javax/imageio/plugins/jpeg/DestTypeTest.java + test/javax/imageio/plugins/jpeg/JPEGsNotAcceleratedTest.java + test/javax/imageio/plugins/jpeg/MergeTreeTest.java + test/javax/imageio/plugins/jpeg/RasterWithMinXTest.java + test/javax/imageio/plugins/jpeg/ResetOutOfMemory.java + test/javax/imageio/plugins/jpeg/UshortGrayTest.java + test/javax/imageio/plugins/png/CanEncodeShort.java + test/javax/imageio/plugins/png/ImageCompare.java + test/javax/imageio/plugins/png/PngPremultAlphaTest.java + test/javax/imageio/plugins/png/ShortPaletteTest.java + test/javax/imageio/plugins/png/WriteProgressive.java + test/javax/imageio/plugins/wbmp/EmptyInputWbmpMetadataTest.java + test/javax/imageio/plugins/wbmp/GetImageTypesTest.java + test/javax/imageio/plugins/wbmp/ValidWbmpTest.java + test/javax/imageio/plugins/wbmp/WBMPPluginTest.java + test/javax/imageio/plugins/wbmp/WbmpBigDestinationTest.java + test/javax/imageio/plugins/wbmp/WbmpDefaultImageMetadataTest.java + test/javax/imageio/spi/AppletContextTest/BadPluginConfigurationTest.sh + test/javax/imageio/spi/AppletContextTest/DummyReaderPluginSpi.java + test/javax/imageio/spi/AppletContextTest/IIOPluginTest.java + test/javax/imageio/spi/CreateMemoryCacheOutputStream.java + test/javax/imageio/spi/DeregisterAllSpiTest.java + test/javax/imageio/spi/DeregisterOrderedSpiTest.java + test/javax/imageio/spi/OrderingTest.java + test/javax/imageio/spi/PluginSpiTest.java + test/javax/imageio/spi/RegisterPluginTwiceTest.java + test/javax/imageio/spi/SpiTest.java + test/javax/imageio/spi/SpiVersionNumbers.java + test/javax/imageio/stream/BitPadding.java + test/javax/imageio/stream/DeleteOnExitTest.java + test/javax/imageio/stream/DeleteOnExitTest.sh + test/javax/imageio/stream/FileCacheImageInputStreamNullTest.java + test/javax/imageio/stream/FlushBefore.java + test/javax/imageio/stream/MemoryCacheImageOutputStreamTest.java + test/javax/imageio/stream/ReadBytesIIOByteBuffer.java + test/javax/imageio/stream/ReadFullyTest.java + test/javax/imageio/stream/ReadUnsignedIntTest.java + test/javax/imageio/stream/StreamFlush.java + test/javax/imageio/stream/WriteBitsTest.java Changeset: de18b4a5ded2 Author: prr Date: 2017-05-26 08:22 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/de18b4a5ded2 Merge Changeset: b41e9d22a754 Author: serb Date: 2017-05-24 13:53 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b41e9d22a754 8066005: java.awt.event.KeyEvent.originalSource doesn't have "since" tag in Serialized Form Reviewed-by: prr ! src/java.desktop/share/classes/java/awt/event/KeyEvent.java Changeset: 99014f394c0c Author: prr Date: 2017-05-26 09:07 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/99014f394c0c Merge Changeset: 92d5e94796d9 Author: mchung Date: 2017-05-26 21:20 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/92d5e94796d9 8180574: tools/launcher/modules/patch/systemmodules/PatchSystemModules.java failed in upgradeHashedModule() and patchHashedModule() intermittently Reviewed-by: alanb, bchristi ! test/tools/launcher/modules/patch/systemmodules/PatchSystemModules.java + test/tools/launcher/modules/patch/systemmodules/src1/m1/module-info.java + test/tools/launcher/modules/patch/systemmodules/src1/m1/p1/Main.java Changeset: 0ff9ad7d067c Author: ihse Date: 2017-05-29 09:18 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0ff9ad7d067c 8175824: Adapt javadoc generation to different requirements for JDK and JavaSE Reviewed-by: erikj, mchung - src/java.base/share/classes/overview-core.html Changeset: a2894068c221 Author: lana Date: 2017-06-01 18:26 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a2894068c221 Added tag jdk-9+172 for changeset 0ff9ad7d067c ! .hgtags Changeset: 770a7f74e51e Author: alanb Date: 2017-06-01 19:42 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/770a7f74e51e Merge ! .hgtags ! src/java.base/share/classes/java/lang/reflect/Constructor.java ! src/java.base/share/classes/java/lang/reflect/Method.java - src/java.base/share/classes/overview-core.html ! src/java.base/share/classes/sun/launcher/LauncherHelper.java ! src/java.base/share/classes/sun/launcher/resources/launcher.properties ! test/ProblemList.txt ! test/tools/launcher/modules/patch/systemmodules/PatchSystemModules.java Changeset: 35e0b4a2651b Author: alanb Date: 2017-06-01 20:44 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/35e0b4a2651b Merge - test/java/util/ServiceLoader/NoInheritanceTest.java - test/java/util/ServiceLoader/NoUsesTest.java - test/java/util/ServiceLoader/modules/noinheritance/module-info.java - test/java/util/ServiceLoader/modules/noinheritance/test/Main.java - test/java/util/ServiceLoader/modules/nouses/module-info.java - test/java/util/ServiceLoader/modules/nouses/test/Main.java - test/java/util/ServiceLoader/src/pearscript/META-INF/services/javax.script.ScriptEngineFactory - test/java/util/ServiceLoader/src/pearscript/org/pear/PearScript.java - test/java/util/ServiceLoader/src/pearscript/org/pear/PearScriptEngineFactory.java From alex.buckley at oracle.com Fri Jun 2 00:13:11 2017 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 01 Jun 2017 17:13:11 -0700 Subject: JPMS Access Checks, Verification and the Security Manager In-Reply-To: References: <13bb0dc2-9518-b72c-385f-1db95a8edab9@oracle.com> <59249529.3030103@oracle.com> Message-ID: <5930AD97.3090406@oracle.com> On 5/24/2017 12:13 AM, Volker Simonis wrote: > OK, so from what you say I understand that the verification errors I > see with the Security Manager enabled are an implementation detail of > HotSpot (because verification uses the same class loading mechanism > like the runtime) which is not required but still acceptable under the > JVMS. Is that correct? The JVMS is precise about which exceptions are allowed to be thrown by a JVM implementation during verification, and AccessControlException is not one of them. However, the JVMS is only one part of the Java SE Platform Specification. It is quite proper if another part specifies an AccessControlException when a class in a restricted package is referenced by a class without permission. I'm thinking in particular of the API specification for SecurityManager::checkPackageAccess. It states, "This method is called by the loadClass method of class loaders." Plainly, the intention is that a class (Tricky) which initiates the loading of another class (com.sun.crypto.provider.SunJCE) can do so only if it has permission to reference the other class. Unfortunately, the statement as written is only guaranteed to be true for the built-in class loaders of the Java SE Platform and not for user-defined class loaders. Accordingly, we will update the API specification to clarify how a JVM implementation may support the Security Manager in checking permissions when classes are loaded and resolved. But to answer your original question, an application CAN fail because the verifier can't load classes due to Security Manager restrictions; you may have to grant additional permissions if application classes wish to reference certain JDK 9 packages. Alex From volker.simonis at gmail.com Fri Jun 2 08:41:13 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 2 Jun 2017 10:41:13 +0200 Subject: JPMS Access Checks, Verification and the Security Manager In-Reply-To: <5930AD97.3090406@oracle.com> References: <13bb0dc2-9518-b72c-385f-1db95a8edab9@oracle.com> <59249529.3030103@oracle.com> <5930AD97.3090406@oracle.com> Message-ID: Thanks Alex, that makes sense. Regards, Volker On Fri, Jun 2, 2017 at 2:13 AM, Alex Buckley wrote: > On 5/24/2017 12:13 AM, Volker Simonis wrote: >> >> OK, so from what you say I understand that the verification errors I >> see with the Security Manager enabled are an implementation detail of >> HotSpot (because verification uses the same class loading mechanism >> like the runtime) which is not required but still acceptable under the >> JVMS. Is that correct? > > > The JVMS is precise about which exceptions are allowed to be thrown by a JVM > implementation during verification, and AccessControlException is not one of > them. However, the JVMS is only one part of the Java SE Platform > Specification. It is quite proper if another part specifies an > AccessControlException when a class in a restricted package is referenced by > a class without permission. > > I'm thinking in particular of the API specification for > SecurityManager::checkPackageAccess. It states, "This method is called by > the loadClass method of class loaders." Plainly, the intention is that a > class (Tricky) which initiates the loading of another class > (com.sun.crypto.provider.SunJCE) can do so only if it has permission to > reference the other class. Unfortunately, the statement as written is only > guaranteed to be true for the built-in class loaders of the Java SE Platform > and not for user-defined class loaders. Accordingly, we will update the API > specification to clarify how a JVM implementation may support the Security > Manager in checking permissions when classes are loaded and resolved. But to > answer your original question, an application CAN fail because the verifier > can't load classes due to Security Manager restrictions; you may have to > grant additional permissions if application classes wish to reference > certain JDK 9 packages. > > Alex From jan.lahoda at oracle.com Fri Jun 2 15:04:49 2017 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Fri, 02 Jun 2017 15:04:49 +0000 Subject: hg: jigsaw/jake/langtools: Adding tests for Automatic-Module-Name, checking the name validity. Message-ID: <201706021504.v52F4oa6001179@aojmv0008.oracle.com> Changeset: 09276c87a4be Author: jlahoda Date: 2017-06-02 17:02 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/09276c87a4be Adding tests for Automatic-Module-Name, checking the name validity. ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java ! test/tools/javac/modules/AutomaticModules.java From alan.bateman at oracle.com Fri Jun 2 16:35:34 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 02 Jun 2017 16:35:34 +0000 Subject: hg: jigsaw/jake/hotspot: Allow illegal access by default Message-ID: <201706021635.v52GZYvH001177@aojmv0008.oracle.com> Changeset: ced5969cff68 Author: alanb Date: 2017-06-02 17:31 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ced5969cff68 Allow illegal access by default ! src/share/vm/runtime/arguments.cpp From alan.bateman at oracle.com Fri Jun 2 16:35:45 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 02 Jun 2017 16:35:45 +0000 Subject: hg: jigsaw/jake/jdk: Allow illegal access by default Message-ID: <201706021635.v52GZjtx001262@aojmv0008.oracle.com> Changeset: 1499c22dfc8b Author: alanb Date: 2017-06-02 17:32 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1499c22dfc8b Allow illegal access by default ! src/java.base/share/classes/java/lang/Module.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java ! src/java.base/share/classes/jdk/internal/misc/JavaLangAccess.java ! src/java.base/share/classes/jdk/internal/module/IllegalAccessLogger.java + src/java.base/share/classes/jdk/internal/module/IllegalAccessMaps.java ! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java ! src/java.base/share/classes/jdk/internal/module/SystemModules.java + src/java.base/share/classes/jdk/internal/module/jdk8_packages.dat ! src/java.base/share/classes/sun/launcher/LauncherHelper.java ! src/java.base/share/classes/sun/launcher/resources/launcher.properties ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java ! test/java/lang/ModuleTests/BasicModuleTest.java ! test/java/lang/instrument/RedefineModuleTest.java ! test/java/lang/reflect/AccessibleObject/CanAccessTest.java ! test/java/lang/reflect/AccessibleObject/ModuleSetAccessibleTest.java ! test/java/lang/reflect/AccessibleObject/TrySetAccessibleTest.java ! test/java/util/ResourceBundle/modules/cache/CacheTest.java ! test/jdk/modules/open/Basic.java ! test/tools/launcher/modules/addexports/manifest/AddExportsAndOpensInManifest.java + test/tools/launcher/modules/illegalaccess/IllegalAccessTest.java + test/tools/launcher/modules/illegalaccess/TryAccess.java + test/tools/launcher/modules/illegalaccess/src/m/module-info.java + test/tools/launcher/modules/illegalaccess/src/m/p/Type.java + test/tools/launcher/modules/illegalaccess/upgradesrc/java.activation/javax/activation/MimeTypeParameterList.java + test/tools/launcher/modules/illegalaccess/upgradesrc/java.activation/module-info.java ! test/tools/launcher/modules/patch/systemmodules/src1/java.base/jdk/internal/modules/SystemModules.java - test/tools/launcher/modules/permit/AttemptAccess.java - test/tools/launcher/modules/permit/PermitIllegalAccess.java From stephen.felts at oracle.com Sat Jun 3 04:11:43 2017 From: stephen.felts at oracle.com (Stephen Felts) Date: Fri, 2 Jun 2017 21:11:43 -0700 (PDT) Subject: jigsaw/jake/jdk: Allow illegal access by default In-Reply-To: <<201706021635.v52GZjtx001262@aojmv0008.oracle.com>> References: <<201706021635.v52GZjtx001262@aojmv0008.oracle.com>> Message-ID: <00754256-9f9c-401b-af1b-89a17d32b053@default> The latest version of Jigsaw available from http://jdk.java.net/jigsaw/ (jdk-9+172 on 06-02-2017 (#6472)) has --illegal-access= permit or deny access to members of types in named modules by code in unnamed modules. is one of "deny", "permit", "warn", or "debug" This option will be removed in a future release. Note that --permit-illegal-access is removed. This is what the output looks like. Ironically, this code in the standalone bind implementation jar has fall-back code for running correctly on JDK9. WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by com.sun.xml.bind.v2.runtime.reflect.opt.Injector (file:/mydirectory/modules/com.sun.xml.bind.jaxb-impl.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int) WARNING: Please consider reporting this to the maintainers of com.sun.xml.bind.v2.runtime.reflect.opt.Injector 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 Running with java --illegal-access=warn produces the following output. WARNING: Illegal reflective access by com.sun.xml.bind.v2.runtime.reflect.opt.Injector (file:/mydirectory/modules/com.sun.xml.bind.jaxb-impl.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int) WARNING: Illegal reflective access by com.sun.xml.bind.v2.runtime.reflect.opt.Injector (file:/mydirectory/modules/com.sun.xml.bind.jaxb-impl.jar) to method java.lang.ClassLoader.resolveClass(java.lang.Class) WARNING: Illegal reflective access by com.sun.xml.bind.v2.runtime.reflect.opt.Injector (file:/mydirectory/modules/com.sun.xml.bind.jaxb-impl.jar) to method java.lang.ClassLoader.findLoadedClass(java.lang.String) There is no quiet option. To get rid of these warnings, you need to explicitly run with java --illegal-access=deny (assuming there are no other illegal access problems). I would like to see a mechanism that allows the developer to work around the warning. Either disable the warning for trySetAccessible() or add a new API if(method.willSetAccessibleWork()) method.setAccessible(true); -----Original Message----- From: jigsaw-dev [mailto:jigsaw-dev-bounces at openjdk.java.net] On Behalf Of alan.bateman at oracle.com Sent: Friday, June 2, 2017 12:36 PM To: jigsaw-dev at openjdk.java.net Subject: hg: jigsaw/jake/jdk: Allow illegal access by default Changeset: 1499c22dfc8b Author: alanb Date: 2017-06-02 17:32 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1499c22dfc8b Allow illegal access by default ! src/java.base/share/classes/java/lang/Module.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java ! src/java.base/share/classes/jdk/internal/misc/JavaLangAccess.java ! src/java.base/share/classes/jdk/internal/module/IllegalAccessLogger.java + src/java.base/share/classes/jdk/internal/module/IllegalAccessMaps.java ! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java ! src/java.base/share/classes/jdk/internal/module/SystemModules.java + src/java.base/share/classes/jdk/internal/module/jdk8_packages.dat ! src/java.base/share/classes/sun/launcher/LauncherHelper.java ! src/java.base/share/classes/sun/launcher/resources/launcher.properties ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java ! test/java/lang/ModuleTests/BasicModuleTest.java ! test/java/lang/instrument/RedefineModuleTest.java ! test/java/lang/reflect/AccessibleObject/CanAccessTest.java ! test/java/lang/reflect/AccessibleObject/ModuleSetAccessibleTest.java ! test/java/lang/reflect/AccessibleObject/TrySetAccessibleTest.java ! test/java/util/ResourceBundle/modules/cache/CacheTest.java ! test/jdk/modules/open/Basic.java ! test/tools/launcher/modules/addexports/manifest/AddExportsAndOpensInManifest.java + test/tools/launcher/modules/illegalaccess/IllegalAccessTest.java + test/tools/launcher/modules/illegalaccess/TryAccess.java + test/tools/launcher/modules/illegalaccess/src/m/module-info.java + test/tools/launcher/modules/illegalaccess/src/m/p/Type.java + test/tools/launcher/modules/illegalaccess/upgradesrc/java.activation/javax/activation/MimeTypeParameterList.java + test/tools/launcher/modules/illegalaccess/upgradesrc/java.activation/module-info.java ! test/tools/launcher/modules/patch/systemmodules/src1/java.base/jdk/internal/modules/SystemModules.java - test/tools/launcher/modules/permit/AttemptAccess.java - test/tools/launcher/modules/permit/PermitIllegalAccess.java From Alan.Bateman at oracle.com Sat Jun 3 06:36:44 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 3 Jun 2017 07:36:44 +0100 Subject: --illegal-access to allow illegal access by default In-Reply-To: <00754256-9f9c-401b-af1b-89a17d32b053@default> References: <<201706021635.v52GZjtx001262@aojmv0008.oracle.com> <00754256-9f9c-401b-af1b-89a17d32b053@default> Message-ID: On 03/06/2017 05:11, Stephen Felts wrote: > The latest version of Jigsaw available from http://jdk.java.net/jigsaw/ (jdk-9+172 on 06-02-2017 (#6472)) has > > > > --illegal-access= > > permit or deny access to members of types in named modules > > by code in unnamed modules. > > is one of "deny", "permit", "warn", or "debug" > > This option will be removed in a future release. > > > > Note that --permit-illegal-access is removed. No, it's has not been removed, at least not yet. For now, `--permit-illegal-access` is an alias for `--illegal-access=warn` in the Jigsaw EA builds. > > > > This is what the output looks like. Ironically, this code in the standalone bind implementation jar has fall-back code for running correctly on JDK9. I think the issue you are running into is missing or incorrect version detection in the standalone JAXB implementation. From what I can tell then it relies on the InaccessibleObjectExceptionto to detect it is on JDK 9. I'm sure that can be easily fixed. > : > > > > There is no quiet option. To get rid of these warnings, you need to explicitly run with java --illegal-access=deny (assuming there are no other illegal access problems). > > Mark will be sending a summary/update on the proposal soon. It's probably best to wait for that write-up. -Alan From stephen.felts at oracle.com Sun Jun 4 03:26:14 2017 From: stephen.felts at oracle.com (Stephen Felts) Date: Sat, 3 Jun 2017 20:26:14 -0700 (PDT) Subject: --illegal-access to allow illegal access by default In-Reply-To: References: <<201706021635.v52GZjtx001262@aojmv0008.oracle.com> <00754256-9f9c-401b-af1b-89a17d32b053@default> Message-ID: <4f6e0088-a21f-4d1b-8146-b401415fd288@default> I have seen multiple cases in software where getting an Exception on a setAccessible or related API is not used to detect JDK9 but simply to fall back to an alternative approach or to attempt to open as many objects as possible but not fail if one or more get an Exception (they are swallowed silently). This code was around long before JDK9, it works with JDK9, and it would be a big change to change the logic. For example, Jython does setAccessible on all methods when it first accesses a class and ignores any Exception; the only time that it's an error is if the application tries to use a method that isn't accessible. Changing the code to be lazy would be a fair amount of work. This Jython use case shows up as a warning and there are no API's to avoid that other than redesigning the tool. -----Original Message----- From: Alan Bateman Sent: Saturday, June 3, 2017 2:37 AM To: Stephen Felts; jigsaw-dev at openjdk.java.net Subject: Re: --illegal-access to allow illegal access by default > This is what the output looks like. Ironically, this code in the standalone bind implementation jar has fall-back code for running correctly on JDK9. I think the issue you are running into is missing or incorrect version detection in the standalone JAXB implementation. From what I can tell then it relies on the InaccessibleObjectExceptionto to detect it is on JDK 9. I'm sure that can be easily fixed. From mark.reinhold at oracle.com Mon Jun 5 18:45:27 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 5 Jun 2017 11:45:27 -0700 (PDT) Subject: Proposal (revised): Allow illegal access to internal APIs by default in JDK 9 Message-ID: <20170605184527.6BD13EE310@eggemoggin.niobe.net> (Thanks for all the feedback on the initial proposal [1]. Here's a revised version, which incorporates some of the suggestions received and includes a bit more advice. An implementation is already available for testing in the Jigsaw EA builds [2]. Further comments welcome!) Over time, as we've gotten closer and closer to the JDK 9 GA date, more and more developers have begun paying attention to the actual changes in this release. The strong encapsulation of JDK-internal APIs has, in particular, triggered many worried expressions of concern that code that works on JDK 8 today will not work on JDK 9 tomorrow, yet no advance warning of this change was given at run time in JDK 8. To help the entire ecosystem migrate to the modular Java platform at a more relaxed pace I hereby propose to allow illegal-access operations to internal APIs from code on the class path by default in JDK 9, and to disallow them in a future release. This will enable smoother application migration in the near term, yet still enable and motivate the maintainers of libraries and frameworks that use JDK-internal APIs to fix their code to use proper exported APIs. New command-line option: `--illegal-access` ------------------------------------------- The recently-introduced `--permit-illegal-access` option [3] will be replaced by a more-general option, `--illegal-access`. This option takes a single keyword parameter to specify a mode of operation, as follows: `--illegal-access=permit` This mode opens each package in each module in the run-time image to code in all unnamed modules, i.e., code on the class path, if that package existed in JDK 8. This enables both static access, i.e., by compiled bytecode, and deep reflective access, via the platform's various reflection APIs. The first reflective-access operation to any such package causes a warning to be issued, but no warnings are issued after that point. This single warning describes how to enable further warnings. This mode will be the default for JDK 9. It will be removed in a future release. `--illegal-access=warn` This mode is identical to `permit` except that a warning message is issued for each illegal reflective-access operation. This is roughly equivalent to the current `--permit-illegal-access` option. `--illegal-access=debug` This mode is identical to `warn` except both a warning message and a stack trace are issued for each illegal reflective-access operation. This is roughly equivalent to combining `--permit-illegal-access` with `-Dsun.reflect.debugModuleAccessChecks`. `--illegal-access=deny` This mode disables all illegal-access operations except for those enabled by other command-line options, e.g., `--add-opens`. This mode will become the default in a future release. When `deny` becomes the default mode then `permit` will likely remain supported for at least one release, so that developers can continue to migrate their code. The `permit`, `warn`, and `debug` modes will, over time, be removed, as will the `--illegal-access` option itself. (For launch-script compatibility the unsupported modes will most likely just be ignored, after issuing a warning to that effect.) How to prepare for the future ----------------------------- The default mode, `--illegal-access=permit`, is intended to make you aware when you have code on the class path that reflectively accesses some JDK-internal API at least once. To learn about all such accesses you can use the `warn` or `debug` modes. For each library or framework on the class path that requires illegal access you have two options: - If the component's maintainers have already released a new, fixed version that no longer uses JDK-internal APIs then you can consider upgrading to that version. - If the component still needs to be fixed then we encourage you to contact its maintainers and ask them to replace their use of JDK-internal APIs with proper exported APIs [4]. If you must continue to use a component that requires illegal access then you can eliminate the warning messages by using one or more `--add-opens` options to open just those internal packages to which access is required. To verify that your application is ready for the future, run it with `--illegal-access=deny` along with any necessary `--add-opens` options. Any remaining illegal-access errors will most likely be due to static references from compiled code to JDK-internal APIs. You can identify those by running the `jdeps` tool with the `--jdk-internals` option. (JDK 9 does not issue warnings for illegal static-access operations because that would require deep JVM changes and degrade performance.) Warning messages ---------------- The warning message issued when an illegal reflective-access operation is detected has the following form: WARNING: Illegal reflective access by $PERPETRATOR to $VICTIM where: - $PERPETRATOR is the fully-qualified name of the type containing the code that invoked the reflective operation in question plus the code source (i.e., JAR-file path), if available, and - $VICTIM is a string that describes the member being accessed, including the fully-qualified name of the enclosing type In JDK 9's default mode, `--illegal-access=permit`, at most one of these warning messages will be issued, accompanied by additional instructive text. Here is an example, from running Jython on the current Jigsaw EA build [2]: $ java -jar jython-standalone-2.7.0.jar WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by jnr.posix.JavaLibCHelper (file:/tmp/jython-standalone-2.7.0.jar) to method sun.nio.ch.SelChImpl.getFD() WARNING: Please consider reporting this to the maintainers of jnr.posix.JavaLibCHelper 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 Jython 2.7.0 (default:9987c746f838, Apr 29 2015, 02:25:11) [OpenJDK 64-Bit Server VM (Oracle Corporation)] on java9-internal Type "help", "copyright", "credits" or "license" for more information. >>> ^D $ If `--illegal-access=warn` is used then only warnings are displayed, with no instructive text. The run-time system makes a best-effort attempt to suppress duplicate warnings for the same $PERPETRATOR and $VICTIM. Here is an example, again running Jython: $ java --illegal-access=warn -jar jython-standalone-2.7.0.jar WARNING: Illegal reflective access by jnr.posix.JavaLibCHelper (file:/tmp/jython-standalone-2.7.0.jar) to method sun.nio.ch.SelChImpl.getFD() WARNING: Illegal reflective access by jnr.posix.JavaLibCHelper (file:/tmp/jython-standalone-2.7.0.jar) to field sun.nio.ch.FileChannelImpl.fd WARNING: Illegal reflective access by jnr.posix.JavaLibCHelper (file:/tmp/jython-standalone-2.7.0.jar) to field java.io.FileDescriptor.fd WARNING: Illegal reflective access by org.python.core.PySystemState (file:/tmp/jython-standalone-2.7.0.jar) to method java.io.Console.encoding() Jython 2.7.0 (default:9987c746f838, Apr 29 2015, 02:25:11) [OpenJDK 64-Bit Server VM (Oracle Corporation)] on java9-internal Type "help", "copyright", "credits" or "license" for more information. >>> ^D $ Notes ----- - There is no `--illegal-access` mode that suppresses all warnings. This is intentional: It ensures that developers know that all illegal-access operations will be denied by default in a future release, at which time code that generates warnings today will fail. Warnings can be suppressed completely via one or more `--add-opens` options. - The first proposal [1] opened every package in every explicit module, rather than just the packages in modules in the run-time image, to every unnamed module. Peter Levart pointed out [5] that this could tempt developers to use internal APIs that are new in JDK 9 (e.g., `jdk.internal.misc.Unsafe`) and thus make the eventual transition from JDK 9 no less painful than that from JDK 8. This proposal thus only opens internal packages that existed in JDK 8. - This proposal will require adjustments to JEP 260, "Encapsulate Most Internal APIs" [6]. APIs that are internal to the JDK will still be strongly encapsulated from the standpoint of code in modules, whether those modules are automatic or explicit, but they will not appear to be encapsulated at run time from the standpoint of code on the class path. - This change will not magically solve every JDK 9 adoption problem. The concrete types of the built-in class loaders are still different, `rt.jar` is still gone, the layout of a system image is still not the same, and the version string still has a new format. [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012673.html [2] http://jdk.java.net/jigsaw/ [3] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-March/011763.html [4] This will usually but not always be possible, since there are still a few critical internal APIs without exported replacements [6]. [5] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012708.html [6] http://openjdk.java.net/jeps/260 From dblevins at tomitribe.com Mon Jun 5 23:41:49 2017 From: dblevins at tomitribe.com (David Blevins) Date: Mon, 5 Jun 2017 16:41:49 -0700 Subject: Proposal (revised): Allow illegal access to internal APIs by default in JDK 9 In-Reply-To: <20170605184527.6BD13EE310@eggemoggin.niobe.net> References: <20170605184527.6BD13EE310@eggemoggin.niobe.net> Message-ID: <3CB8EC99-D7C0-4447-B35D-88CA3866D78E@tomitribe.com> I think this is the most pragmatic and reasoned middle ground one could possibly imagine. I agree with the finely-tuned choices, specifically: - Not going completely silent. Some asked for the ability to completely shut off the warnings. This goes a little too far to one extreme. There has to be some cost or discomfort or there won?t be the right movement. IMHO, it would have been too far back the other way to go silent. People will see these messages, they will post them to StackOverflow and get an education on how to go forward. We need that. - Not choosing `--illegal-access=deny` by default for this version. Some cited this as a setback. There is an argument to be made that it would have been the bigger setback to go too strict too soon. The danger would be when developers who don?t know this conversation and the details behind it learn ?use this flag to make problems go away?. At which point it becomes cargo cult and they?ll be afraid to stop using it because they never understood it completely in the first place. Worse, we?re now buried under 3 years of lazy StackOverflow answers effectively telling people how to go backwards. So although it feels less strict, one set of choices creates a conversation on how to move forward and one creates a conversation on how to go backward. Of course time will tell, but I believe this proposal gets us what we want the soonest. -David > On Jun 5, 2017, at 11:45 AM, mark.reinhold at oracle.com wrote: > > (Thanks for all the feedback on the initial proposal [1]. Here's a > revised version, which incorporates some of the suggestions received and > includes a bit more advice. An implementation is already available for > testing in the Jigsaw EA builds [2]. Further comments welcome!) > > Over time, as we've gotten closer and closer to the JDK 9 GA date, more > and more developers have begun paying attention to the actual changes in > this release. The strong encapsulation of JDK-internal APIs has, in > particular, triggered many worried expressions of concern that code that > works on JDK 8 today will not work on JDK 9 tomorrow, yet no advance > warning of this change was given at run time in JDK 8. > > To help the entire ecosystem migrate to the modular Java platform at a > more relaxed pace I hereby propose to allow illegal-access operations to > internal APIs from code on the class path by default in JDK 9, and to > disallow them in a future release. This will enable smoother application > migration in the near term, yet still enable and motivate the maintainers > of libraries and frameworks that use JDK-internal APIs to fix their code > to use proper exported APIs. > > New command-line option: `--illegal-access` > ------------------------------------------- > > The recently-introduced `--permit-illegal-access` option [3] will be > replaced by a more-general option, `--illegal-access`. This option takes > a single keyword parameter to specify a mode of operation, as follows: > > `--illegal-access=permit` > > This mode opens each package in each module in the run-time image to > code in all unnamed modules, i.e., code on the class path, if that > package existed in JDK 8. This enables both static access, i.e., by > compiled bytecode, and deep reflective access, via the platform's > various reflection APIs. > > The first reflective-access operation to any such package causes a > warning to be issued, but no warnings are issued after that point. > This single warning describes how to enable further warnings. > > This mode will be the default for JDK 9. It will be removed in a > future release. > > `--illegal-access=warn` > > This mode is identical to `permit` except that a warning message is > issued for each illegal reflective-access operation. This is roughly > equivalent to the current `--permit-illegal-access` option. > > `--illegal-access=debug` > > This mode is identical to `warn` except both a warning message and a > stack trace are issued for each illegal reflective-access operation. > This is roughly equivalent to combining `--permit-illegal-access` > with `-Dsun.reflect.debugModuleAccessChecks`. > > `--illegal-access=deny` > > This mode disables all illegal-access operations except for those > enabled by other command-line options, e.g., `--add-opens`. > > This mode will become the default in a future release. > > When `deny` becomes the default mode then `permit` will likely remain > supported for at least one release, so that developers can continue to > migrate their code. The `permit`, `warn`, and `debug` modes will, over > time, be removed, as will the `--illegal-access` option itself. (For > launch-script compatibility the unsupported modes will most likely just > be ignored, after issuing a warning to that effect.) > > How to prepare for the future > ----------------------------- > > The default mode, `--illegal-access=permit`, is intended to make you > aware when you have code on the class path that reflectively accesses > some JDK-internal API at least once. To learn about all such accesses > you can use the `warn` or `debug` modes. For each library or framework > on the class path that requires illegal access you have two options: > > - If the component's maintainers have already released a new, > fixed version that no longer uses JDK-internal APIs then you > can consider upgrading to that version. > > - If the component still needs to be fixed then we encourage you > to contact its maintainers and ask them to replace their use > of JDK-internal APIs with proper exported APIs [4]. > > If you must continue to use a component that requires illegal access then > you can eliminate the warning messages by using one or more `--add-opens` > options to open just those internal packages to which access is required. > > To verify that your application is ready for the future, run it with > `--illegal-access=deny` along with any necessary `--add-opens` options. > Any remaining illegal-access errors will most likely be due to static > references from compiled code to JDK-internal APIs. You can identify > those by running the `jdeps` tool with the `--jdk-internals` option. > (JDK 9 does not issue warnings for illegal static-access operations > because that would require deep JVM changes and degrade performance.) > > Warning messages > ---------------- > > The warning message issued when an illegal reflective-access operation is > detected has the following form: > > WARNING: Illegal reflective access by $PERPETRATOR to $VICTIM > > where: > > - $PERPETRATOR is the fully-qualified name of the type containing > the code that invoked the reflective operation in question plus > the code source (i.e., JAR-file path), if available, and > > - $VICTIM is a string that describes the member being accessed, > including the fully-qualified name of the enclosing type > > In JDK 9's default mode, `--illegal-access=permit`, at most one of these > warning messages will be issued, accompanied by additional instructive > text. Here is an example, from running Jython on the current Jigsaw EA > build [2]: > > $ java -jar jython-standalone-2.7.0.jar > WARNING: An illegal reflective access operation has occurred > WARNING: Illegal reflective access by jnr.posix.JavaLibCHelper (file:/tmp/jython-standalone-2.7.0.jar) to method sun.nio.ch.SelChImpl.getFD() > WARNING: Please consider reporting this to the maintainers of jnr.posix.JavaLibCHelper > 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 > Jython 2.7.0 (default:9987c746f838, Apr 29 2015, 02:25:11) > [OpenJDK 64-Bit Server VM (Oracle Corporation)] on java9-internal > Type "help", "copyright", "credits" or "license" for more information. >>>> ^D > $ > > If `--illegal-access=warn` is used then only warnings are displayed, with > no instructive text. The run-time system makes a best-effort attempt to > suppress duplicate warnings for the same $PERPETRATOR and $VICTIM. Here > is an example, again running Jython: > > $ java --illegal-access=warn -jar jython-standalone-2.7.0.jar > WARNING: Illegal reflective access by jnr.posix.JavaLibCHelper (file:/tmp/jython-standalone-2.7.0.jar) to method sun.nio.ch.SelChImpl.getFD() > WARNING: Illegal reflective access by jnr.posix.JavaLibCHelper (file:/tmp/jython-standalone-2.7.0.jar) to field sun.nio.ch.FileChannelImpl.fd > WARNING: Illegal reflective access by jnr.posix.JavaLibCHelper (file:/tmp/jython-standalone-2.7.0.jar) to field java.io.FileDescriptor.fd > WARNING: Illegal reflective access by org.python.core.PySystemState (file:/tmp/jython-standalone-2.7.0.jar) to method java.io.Console.encoding() > Jython 2.7.0 (default:9987c746f838, Apr 29 2015, 02:25:11) > [OpenJDK 64-Bit Server VM (Oracle Corporation)] on java9-internal > Type "help", "copyright", "credits" or "license" for more information. >>>> ^D > $ > > Notes > ----- > > - There is no `--illegal-access` mode that suppresses all warnings. > This is intentional: It ensures that developers know that all > illegal-access operations will be denied by default in a future > release, at which time code that generates warnings today will fail. > Warnings can be suppressed completely via one or more `--add-opens` > options. > > - The first proposal [1] opened every package in every explicit module, > rather than just the packages in modules in the run-time image, to > every unnamed module. Peter Levart pointed out [5] that this could > tempt developers to use internal APIs that are new in JDK 9 (e.g., > `jdk.internal.misc.Unsafe`) and thus make the eventual transition > from JDK 9 no less painful than that from JDK 8. This proposal thus > only opens internal packages that existed in JDK 8. > > - This proposal will require adjustments to JEP 260, "Encapsulate Most > Internal APIs" [6]. APIs that are internal to the JDK will still be > strongly encapsulated from the standpoint of code in modules, whether > those modules are automatic or explicit, but they will not appear to > be encapsulated at run time from the standpoint of code on the class > path. > > - This change will not magically solve every JDK 9 adoption problem. > The concrete types of the built-in class loaders are still different, > `rt.jar` is still gone, the layout of a system image is still not the > same, and the version string still has a new format. > > > [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012673.html > [2] http://jdk.java.net/jigsaw/ > [3] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-March/011763.html > [4] This will usually but not always be possible, since there are still a > few critical internal APIs without exported replacements [6]. > [5] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012708.html > [6] http://openjdk.java.net/jeps/260 From pepper at gradle.com Tue Jun 6 00:12:54 2017 From: pepper at gradle.com (Pepper Lebeck-Jobe) Date: Tue, 06 Jun 2017 00:12:54 +0000 Subject: Proposal (revised): Allow illegal access to internal APIs by default in JDK 9 In-Reply-To: <3CB8EC99-D7C0-4447-B35D-88CA3866D78E@tomitribe.com> References: <20170605184527.6BD13EE310@eggemoggin.niobe.net> <3CB8EC99-D7C0-4447-B35D-88CA3866D78E@tomitribe.com> Message-ID: Hi, I'm a new poster to this list. I'm actively working on getting Gradle to work on JDK 9, and I also think this proposal strikes a very good balance between pragmatism (don't just break people today) and getting developers motivated to clean up their code for the future. Thank you, Pepper Lebeck-Jobe On Tue, Jun 6, 2017 at 8:53 AM David Blevins wrote: > I think this is the most pragmatic and reasoned middle ground one could > possibly imagine. > > I agree with the finely-tuned choices, specifically: > > - Not going completely silent. Some asked for the ability to completely > shut off the warnings. This goes a little too far to one extreme. There > has to be some cost or discomfort or there won?t be the right movement. > IMHO, it would have been too far back the other way to go silent. People > will see these messages, they will post them to StackOverflow and get an > education on how to go forward. We need that. > > - Not choosing `--illegal-access=deny` by default for this version. > Some cited this as a setback. There is an argument to be made that it > would have been the bigger setback to go too strict too soon. The danger > would be when developers who don?t know this conversation and the details > behind it learn ?use this flag to make problems go away?. At which point > it becomes cargo cult and they?ll be afraid to stop using it because they > never understood it completely in the first place. Worse, we?re now buried > under 3 years of lazy StackOverflow answers effectively telling people how > to go backwards. > > So although it feels less strict, one set of choices creates a > conversation on how to move forward and one creates a conversation on how > to go backward. > > Of course time will tell, but I believe this proposal gets us what we want > the soonest. > > > -David > > > > On Jun 5, 2017, at 11:45 AM, mark.reinhold at oracle.com wrote: > > > > (Thanks for all the feedback on the initial proposal [1]. Here's a > > revised version, which incorporates some of the suggestions received and > > includes a bit more advice. An implementation is already available for > > testing in the Jigsaw EA builds [2]. Further comments welcome!) > > > > Over time, as we've gotten closer and closer to the JDK 9 GA date, more > > and more developers have begun paying attention to the actual changes in > > this release. The strong encapsulation of JDK-internal APIs has, in > > particular, triggered many worried expressions of concern that code that > > works on JDK 8 today will not work on JDK 9 tomorrow, yet no advance > > warning of this change was given at run time in JDK 8. > > > > To help the entire ecosystem migrate to the modular Java platform at a > > more relaxed pace I hereby propose to allow illegal-access operations to > > internal APIs from code on the class path by default in JDK 9, and to > > disallow them in a future release. This will enable smoother application > > migration in the near term, yet still enable and motivate the maintainers > > of libraries and frameworks that use JDK-internal APIs to fix their code > > to use proper exported APIs. > > > > New command-line option: `--illegal-access` > > ------------------------------------------- > > > > The recently-introduced `--permit-illegal-access` option [3] will be > > replaced by a more-general option, `--illegal-access`. This option takes > > a single keyword parameter to specify a mode of operation, as follows: > > > > `--illegal-access=permit` > > > > This mode opens each package in each module in the run-time image to > > code in all unnamed modules, i.e., code on the class path, if that > > package existed in JDK 8. This enables both static access, i.e., by > > compiled bytecode, and deep reflective access, via the platform's > > various reflection APIs. > > > > The first reflective-access operation to any such package causes a > > warning to be issued, but no warnings are issued after that point. > > This single warning describes how to enable further warnings. > > > > This mode will be the default for JDK 9. It will be removed in a > > future release. > > > > `--illegal-access=warn` > > > > This mode is identical to `permit` except that a warning message is > > issued for each illegal reflective-access operation. This is roughly > > equivalent to the current `--permit-illegal-access` option. > > > > `--illegal-access=debug` > > > > This mode is identical to `warn` except both a warning message and a > > stack trace are issued for each illegal reflective-access operation. > > This is roughly equivalent to combining `--permit-illegal-access` > > with `-Dsun.reflect.debugModuleAccessChecks`. > > > > `--illegal-access=deny` > > > > This mode disables all illegal-access operations except for those > > enabled by other command-line options, e.g., `--add-opens`. > > > > This mode will become the default in a future release. > > > > When `deny` becomes the default mode then `permit` will likely remain > > supported for at least one release, so that developers can continue to > > migrate their code. The `permit`, `warn`, and `debug` modes will, over > > time, be removed, as will the `--illegal-access` option itself. (For > > launch-script compatibility the unsupported modes will most likely just > > be ignored, after issuing a warning to that effect.) > > > > How to prepare for the future > > ----------------------------- > > > > The default mode, `--illegal-access=permit`, is intended to make you > > aware when you have code on the class path that reflectively accesses > > some JDK-internal API at least once. To learn about all such accesses > > you can use the `warn` or `debug` modes. For each library or framework > > on the class path that requires illegal access you have two options: > > > > - If the component's maintainers have already released a new, > > fixed version that no longer uses JDK-internal APIs then you > > can consider upgrading to that version. > > > > - If the component still needs to be fixed then we encourage you > > to contact its maintainers and ask them to replace their use > > of JDK-internal APIs with proper exported APIs [4]. > > > > If you must continue to use a component that requires illegal access then > > you can eliminate the warning messages by using one or more `--add-opens` > > options to open just those internal packages to which access is required. > > > > To verify that your application is ready for the future, run it with > > `--illegal-access=deny` along with any necessary `--add-opens` options. > > Any remaining illegal-access errors will most likely be due to static > > references from compiled code to JDK-internal APIs. You can identify > > those by running the `jdeps` tool with the `--jdk-internals` option. > > (JDK 9 does not issue warnings for illegal static-access operations > > because that would require deep JVM changes and degrade performance.) > > > > Warning messages > > ---------------- > > > > The warning message issued when an illegal reflective-access operation is > > detected has the following form: > > > > WARNING: Illegal reflective access by $PERPETRATOR to $VICTIM > > > > where: > > > > - $PERPETRATOR is the fully-qualified name of the type containing > > the code that invoked the reflective operation in question plus > > the code source (i.e., JAR-file path), if available, and > > > > - $VICTIM is a string that describes the member being accessed, > > including the fully-qualified name of the enclosing type > > > > In JDK 9's default mode, `--illegal-access=permit`, at most one of these > > warning messages will be issued, accompanied by additional instructive > > text. Here is an example, from running Jython on the current Jigsaw EA > > build [2]: > > > > $ java -jar jython-standalone-2.7.0.jar > > WARNING: An illegal reflective access operation has occurred > > WARNING: Illegal reflective access by jnr.posix.JavaLibCHelper > (file:/tmp/jython-standalone-2.7.0.jar) to method > sun.nio.ch.SelChImpl.getFD() > > WARNING: Please consider reporting this to the maintainers of > jnr.posix.JavaLibCHelper > > 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 > > Jython 2.7.0 (default:9987c746f838, Apr 29 2015, 02:25:11) > > [OpenJDK 64-Bit Server VM (Oracle Corporation)] on java9-internal > > Type "help", "copyright", "credits" or "license" for more information. > >>>> ^D > > $ > > > > If `--illegal-access=warn` is used then only warnings are displayed, with > > no instructive text. The run-time system makes a best-effort attempt to > > suppress duplicate warnings for the same $PERPETRATOR and $VICTIM. Here > > is an example, again running Jython: > > > > $ java --illegal-access=warn -jar jython-standalone-2.7.0.jar > > WARNING: Illegal reflective access by jnr.posix.JavaLibCHelper > (file:/tmp/jython-standalone-2.7.0.jar) to method > sun.nio.ch.SelChImpl.getFD() > > WARNING: Illegal reflective access by jnr.posix.JavaLibCHelper > (file:/tmp/jython-standalone-2.7.0.jar) to field > sun.nio.ch.FileChannelImpl.fd > > WARNING: Illegal reflective access by jnr.posix.JavaLibCHelper > (file:/tmp/jython-standalone-2.7.0.jar) to field java.io.FileDescriptor.fd > > WARNING: Illegal reflective access by org.python.core.PySystemState > (file:/tmp/jython-standalone-2.7.0.jar) to method java.io.Console.encoding() > > Jython 2.7.0 (default:9987c746f838, Apr 29 2015, 02:25:11) > > [OpenJDK 64-Bit Server VM (Oracle Corporation)] on java9-internal > > Type "help", "copyright", "credits" or "license" for more information. > >>>> ^D > > $ > > > > Notes > > ----- > > > > - There is no `--illegal-access` mode that suppresses all warnings. > > This is intentional: It ensures that developers know that all > > illegal-access operations will be denied by default in a future > > release, at which time code that generates warnings today will fail. > > Warnings can be suppressed completely via one or more `--add-opens` > > options. > > > > - The first proposal [1] opened every package in every explicit module, > > rather than just the packages in modules in the run-time image, to > > every unnamed module. Peter Levart pointed out [5] that this could > > tempt developers to use internal APIs that are new in JDK 9 (e.g., > > `jdk.internal.misc.Unsafe`) and thus make the eventual transition > > from JDK 9 no less painful than that from JDK 8. This proposal thus > > only opens internal packages that existed in JDK 8. > > > > - This proposal will require adjustments to JEP 260, "Encapsulate Most > > Internal APIs" [6]. APIs that are internal to the JDK will still be > > strongly encapsulated from the standpoint of code in modules, whether > > those modules are automatic or explicit, but they will not appear to > > be encapsulated at run time from the standpoint of code on the class > > path. > > > > - This change will not magically solve every JDK 9 adoption problem. > > The concrete types of the built-in class loaders are still different, > > `rt.jar` is still gone, the layout of a system image is still not the > > same, and the version string still has a new format. > > > > > > [1] > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012673.html > > [2] http://jdk.java.net/jigsaw/ > > [3] > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-March/011763.html > > [4] This will usually but not always be possible, since there are still a > > few critical internal APIs without exported replacements [6]. > > [5] > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012708.html > > [6] http://openjdk.java.net/jeps/260 > > From stephen.felts at oracle.com Tue Jun 6 03:34:06 2017 From: stephen.felts at oracle.com (Stephen Felts) Date: Mon, 5 Jun 2017 20:34:06 -0700 (PDT) Subject: Proposal (revised): Allow illegal access to internal APIs by default in JDK 9 In-Reply-To: <<20170605184527.6BD13EE310@eggemoggin.niobe.net>> References: <<20170605184527.6BD13EE310@eggemoggin.niobe.net>> Message-ID: The new format is missing information that was useful in the earlier -Dsun.reflect.debugModuleAccessChecks=true. It printed something like 'java.base does not "opens java.text" to unnamed module ...' so it was really obvious what option was needed. -----Original Message----- From: jigsaw-dev [mailto:jigsaw-dev-bounces at openjdk.java.net] On Behalf Of mark.reinhold at oracle.com Sent: Monday, June 5, 2017 2:45 PM To: jigsaw-dev at openjdk.java.net Subject: Proposal (revised): Allow illegal access to internal APIs by default in JDK 9 (Thanks for all the feedback on the initial proposal [1]. Here's a revised version, which incorporates some of the suggestions received and includes a bit more advice. An implementation is already available for testing in the Jigsaw EA builds [2]. Further comments welcome!) Over time, as we've gotten closer and closer to the JDK 9 GA date, more and more developers have begun paying attention to the actual changes in this release. The strong encapsulation of JDK-internal APIs has, in particular, triggered many worried expressions of concern that code that works on JDK 8 today will not work on JDK 9 tomorrow, yet no advance warning of this change was given at run time in JDK 8. To help the entire ecosystem migrate to the modular Java platform at a more relaxed pace I hereby propose to allow illegal-access operations to internal APIs from code on the class path by default in JDK 9, and to disallow them in a future release. This will enable smoother application migration in the near term, yet still enable and motivate the maintainers of libraries and frameworks that use JDK-internal APIs to fix their code to use proper exported APIs. New command-line option: `--illegal-access` ------------------------------------------- The recently-introduced `--permit-illegal-access` option [3] will be replaced by a more-general option, `--illegal-access`. This option takes a single keyword parameter to specify a mode of operation, as follows: `--illegal-access=permit` This mode opens each package in each module in the run-time image to code in all unnamed modules, i.e., code on the class path, if that package existed in JDK 8. This enables both static access, i.e., by compiled bytecode, and deep reflective access, via the platform's various reflection APIs. The first reflective-access operation to any such package causes a warning to be issued, but no warnings are issued after that point. This single warning describes how to enable further warnings. This mode will be the default for JDK 9. It will be removed in a future release. `--illegal-access=warn` This mode is identical to `permit` except that a warning message is issued for each illegal reflective-access operation. This is roughly equivalent to the current `--permit-illegal-access` option. `--illegal-access=debug` This mode is identical to `warn` except both a warning message and a stack trace are issued for each illegal reflective-access operation. This is roughly equivalent to combining `--permit-illegal-access` with `-Dsun.reflect.debugModuleAccessChecks`. `--illegal-access=deny` This mode disables all illegal-access operations except for those enabled by other command-line options, e.g., `--add-opens`. This mode will become the default in a future release. When `deny` becomes the default mode then `permit` will likely remain supported for at least one release, so that developers can continue to migrate their code. The `permit`, `warn`, and `debug` modes will, over time, be removed, as will the `--illegal-access` option itself. (For launch-script compatibility the unsupported modes will most likely just be ignored, after issuing a warning to that effect.) How to prepare for the future ----------------------------- The default mode, `--illegal-access=permit`, is intended to make you aware when you have code on the class path that reflectively accesses some JDK-internal API at least once. To learn about all such accesses you can use the `warn` or `debug` modes. For each library or framework on the class path that requires illegal access you have two options: - If the component's maintainers have already released a new, fixed version that no longer uses JDK-internal APIs then you can consider upgrading to that version. - If the component still needs to be fixed then we encourage you to contact its maintainers and ask them to replace their use of JDK-internal APIs with proper exported APIs [4]. If you must continue to use a component that requires illegal access then you can eliminate the warning messages by using one or more `--add-opens` options to open just those internal packages to which access is required. To verify that your application is ready for the future, run it with `--illegal-access=deny` along with any necessary `--add-opens` options. Any remaining illegal-access errors will most likely be due to static references from compiled code to JDK-internal APIs. You can identify those by running the `jdeps` tool with the `--jdk-internals` option. (JDK 9 does not issue warnings for illegal static-access operations because that would require deep JVM changes and degrade performance.) Warning messages ---------------- The warning message issued when an illegal reflective-access operation is detected has the following form: WARNING: Illegal reflective access by $PERPETRATOR to $VICTIM where: - $PERPETRATOR is the fully-qualified name of the type containing the code that invoked the reflective operation in question plus the code source (i.e., JAR-file path), if available, and - $VICTIM is a string that describes the member being accessed, including the fully-qualified name of the enclosing type In JDK 9's default mode, `--illegal-access=permit`, at most one of these warning messages will be issued, accompanied by additional instructive text. Here is an example, from running Jython on the current Jigsaw EA build [2]: $ java -jar jython-standalone-2.7.0.jar WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by jnr.posix.JavaLibCHelper (file:/tmp/jython-standalone-2.7.0.jar) to method sun.nio.ch.SelChImpl.getFD() WARNING: Please consider reporting this to the maintainers of jnr.posix.JavaLibCHelper 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 Jython 2.7.0 (default:9987c746f838, Apr 29 2015, 02:25:11) [OpenJDK 64-Bit Server VM (Oracle Corporation)] on java9-internal Type "help", "copyright", "credits" or "license" for more information. >>> ^D $ If `--illegal-access=warn` is used then only warnings are displayed, with no instructive text. The run-time system makes a best-effort attempt to suppress duplicate warnings for the same $PERPETRATOR and $VICTIM. Here is an example, again running Jython: $ java --illegal-access=warn -jar jython-standalone-2.7.0.jar WARNING: Illegal reflective access by jnr.posix.JavaLibCHelper (file:/tmp/jython-standalone-2.7.0.jar) to method sun.nio.ch.SelChImpl.getFD() WARNING: Illegal reflective access by jnr.posix.JavaLibCHelper (file:/tmp/jython-standalone-2.7.0.jar) to field sun.nio.ch.FileChannelImpl.fd WARNING: Illegal reflective access by jnr.posix.JavaLibCHelper (file:/tmp/jython-standalone-2.7.0.jar) to field java.io.FileDescriptor.fd WARNING: Illegal reflective access by org.python.core.PySystemState (file:/tmp/jython-standalone-2.7.0.jar) to method java.io.Console.encoding() Jython 2.7.0 (default:9987c746f838, Apr 29 2015, 02:25:11) [OpenJDK 64-Bit Server VM (Oracle Corporation)] on java9-internal Type "help", "copyright", "credits" or "license" for more information. >>> ^D $ Notes ----- - There is no `--illegal-access` mode that suppresses all warnings. This is intentional: It ensures that developers know that all illegal-access operations will be denied by default in a future release, at which time code that generates warnings today will fail. Warnings can be suppressed completely via one or more `--add-opens` options. - The first proposal [1] opened every package in every explicit module, rather than just the packages in modules in the run-time image, to every unnamed module. Peter Levart pointed out [5] that this could tempt developers to use internal APIs that are new in JDK 9 (e.g., `jdk.internal.misc.Unsafe`) and thus make the eventual transition from JDK 9 no less painful than that from JDK 8. This proposal thus only opens internal packages that existed in JDK 8. - This proposal will require adjustments to JEP 260, "Encapsulate Most Internal APIs" [6]. APIs that are internal to the JDK will still be strongly encapsulated from the standpoint of code in modules, whether those modules are automatic or explicit, but they will not appear to be encapsulated at run time from the standpoint of code on the class path. - This change will not magically solve every JDK 9 adoption problem. The concrete types of the built-in class loaders are still different, `rt.jar` is still gone, the layout of a system image is still not the same, and the version string still has a new format. [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012673.html [2] http://jdk.java.net/jigsaw/ [3] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-March/011763.html [4] This will usually but not always be possible, since there are still a few critical internal APIs without exported replacements [6]. [5] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012708.html [6] http://openjdk.java.net/jeps/260 From Alan.Bateman at oracle.com Tue Jun 6 06:09:03 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 6 Jun 2017 07:09:03 +0100 Subject: Proposal (revised): Allow illegal access to internal APIs by default in JDK 9 In-Reply-To: References: <<20170605184527.6BD13EE310@eggemoggin.niobe.net> Message-ID: <1f60415e-c22c-76b6-5d17-4a5aa6d9a14f@oracle.com> On 06/06/2017 04:34, Stephen Felts wrote: > The new format is missing information that was useful in the earlier -Dsun.reflect.debugModuleAccessChecks=true. It printed something like > 'java.base does not "opens java.text" to unnamed module ...' so it was really obvious what option was needed. > > `-Dsun.reflect.debugModuleAccessChecks=true` can still be used to hunt code that swallows IllegalAccessException or InaccessibleObjectException, particularly useful when running with `--illegal-access=deny`. -Alan From stephan.herrmann at berlin.de Tue Jun 6 08:15:13 2017 From: stephan.herrmann at berlin.de (Stephan Herrmann) Date: Tue, 6 Jun 2017 10:15:13 +0200 Subject: Java Platform Module System In-Reply-To: <5903CF7D.9060803@oracle.com> References: <20170424091831.557135740@eggemoggin.niobe.net> <58FEAB69.2080008@oracle.com> <58FF812E.1010006@oracle.com> <1b984d15-2056-5860-a0b0-40d85edffe42@berlin.de> <5903CF7D.9060803@oracle.com> Message-ID: A quick editorial comment: On 29.04.2017 01:25, Alex Buckley wrote: > [...] I have changed 7.3 to state: > > "The host system must use the Java Platform Module System (as if by execution of the 'resolve' method of > java.lang.module.Configuration) to determine which modules are read by M (?7.7.1). It is a compile-time error if the Java Platform > Module System is unable to determine which modules are read by M." As of spec version 2017-05-25 I can confirm this issue to be resolved. Just the location of this definition seems strange to me. When reading section 7.4, in the very end (in 7.4.3) "reads" is used with no obvious connection to any definition of what it means. 7.7.1 would have been a more natural location for the definition, IMHO. Stephan From stephan.herrmann at berlin.de Tue Jun 6 08:40:38 2017 From: stephan.herrmann at berlin.de (Stephan Herrmann) Date: Tue, 6 Jun 2017 10:40:38 +0200 Subject: Java Platform Module System In-Reply-To: References: <20170424091831.557135740@eggemoggin.niobe.net> <58FEAB69.2080008@oracle.com> <58FF812E.1010006@oracle.com> <1b984d15-2056-5860-a0b0-40d85edffe42@berlin.de> <5903CF7D.9060803@oracle.com> Message-ID: <30583dc8-b0e3-8d32-4282-0d1936ce54d8@berlin.de> On 06.06.2017 10:15, Stephan Herrmann wrote: > A quick editorial comment: > > On 29.04.2017 01:25, Alex Buckley wrote: > > [...] I have changed 7.3 to state: > > > > "The host system must use the Java Platform Module System (as if by execution of the 'resolve' method of > > java.lang.module.Configuration) to determine which modules are read by M (?7.7.1). It is a compile-time error if the Java Platform > > Module System is unable to determine which modules are read by M." > > As of spec version 2017-05-25 I can confirm this issue to be resolved. This was viewed from the JLS p.o.v. But "read by M" is still not well-defined. All we see in the documentation of the referenced method is: "a readability graph is computed" With some further searching, we find "readability graph" explained in the toplevel documentation of class Configuration. But where in the specification (combination of JLS and API doc) should we learn the connection between "read" and "requires"? As far as I can see this fundamental connection is totally implicit. I know what is meant, but for the final specification this is still needs to be improved. The specification shouldn't expect the reader to already know what is specified prior to reading :) Additionally, this missing link in the specification hides the fact that it is unspecified how "transitive" contributes to "reads", which is more severe than the editorial aspect of it. Stephan From Alan.Bateman at oracle.com Tue Jun 6 09:03:15 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 6 Jun 2017 10:03:15 +0100 Subject: Java Platform Module System In-Reply-To: <30583dc8-b0e3-8d32-4282-0d1936ce54d8@berlin.de> References: <20170424091831.557135740@eggemoggin.niobe.net> <58FEAB69.2080008@oracle.com> <58FF812E.1010006@oracle.com> <1b984d15-2056-5860-a0b0-40d85edffe42@berlin.de> <5903CF7D.9060803@oracle.com> <30583dc8-b0e3-8d32-4282-0d1936ce54d8@berlin.de> Message-ID: On 06/06/2017 09:40, Stephan Herrmann wrote: > > This was viewed from the JLS p.o.v. But "read by M" is still not > well-defined. > All we see in the documentation of the referenced method is: > > "a readability graph is computed" > > With some further searching, we find "readability graph" explained in the > toplevel documentation of class Configuration. > > But where in the specification (combination of JLS and API doc) should we > learn the connection between "read" and "requires"? As far as I can see > this fundamental connection is totally implicit. > > I know what is meant, but for the final specification this is still needs > to be improved. The specification shouldn't expect the reader to already > know what is specified prior to reading :) > > Additionally, this missing link in the specification hides the fact > that it is unspecified how "transitive" contributes to "reads", > which is more severe than the editorial aspect of it. Resolution is specified in the java.lang.module package description (remember this package description was re-worked to address #ResolutionAtCompileTime [1]). In the JSR's working draft specification, you can find it here: http://cr.openjdk.java.net/~mr/jigsaw/spec/api/java/lang/module/package-summary.html It's identical to the javadoc that is published with the Jigsaw EA builds. -Alan. [1] http://openjdk.java.net/projects/jigsaw/spec/issues/#ResolutionAtCompileTime From stephan.herrmann at berlin.de Tue Jun 6 10:24:55 2017 From: stephan.herrmann at berlin.de (Stephan Herrmann) Date: Tue, 6 Jun 2017 12:24:55 +0200 Subject: Compiling with automatic modules In-Reply-To: <592DE76A.5000304@oracle.com> References: <59249BD1.6090402@oracle.com> <67048c13-1468-3ff3-4462-3e2b593f108d@berlin.de> <592762E5.9030709@oracle.com> <2e8235b4-4143-a0c6-dd42-152b363ec6e0@gmx.org> <592DCB20.9020307@oracle.com> <91bff900-3e66-921d-ed20-687a9d4a9252@gmx.org> <592DE76A.5000304@oracle.com> Message-ID: On 30.05.2017 23:43, Alex Buckley wrote: > On 5/30/2017 2:08 PM, Jochen Theodorou wrote: >> On 30.05.2017 21:42, Alex Buckley wrote: >>> On 5/26/2017 4:12 AM, Jochen Theodorou wrote: >>>> On 26.05.2017 01:04, Alex Buckley wrote: [...] >>>>> The semantics of an observed JAR without module-info.class are >>>>> specified as part of JPMS resolution, and JLS 7.3 explicitly >>>>> defers to that, so I believe it is clear how a compiler must >>>>> behave when a modular compilation unit 'requires' a module that >>>>> turns out to be automatic. (Of course a big part of the >>>>> migration story is that the requirer is unaware of whether the >>>>> requiree is automatic or explicit.) >>>> >>>> Isn't the consequence that I can write a compiler which does only >>>> allow named modules? >>> >>> You mean a compiler that understands named module and does not >>> understand unnamed modules? >> >> actually I was wondering more about automatic modules and inexact in >> my question. >> >>> No, per JLS 7.7.5: "An implementation of the Java SE Platform must >>> support at least one unnamed module." The mandates for unnamed >>> modules in 7.7.5 are essentially identical to the historical >>> mandates for unnamed packages in 7.4.2. >> >> """ An implementation of the Java SE Platform must support at least >> one unnamed module. An implementation may support more than one >> unnamed module, but is not required to do so. Which ordinary >> compilation units are associated with each unnamed module is >> determined by the host system. >> >> The host system may associate ordinary compilation units in a named >> package with an unnamed module. """ >> >> OK, from this I understand there must be at least one unnamed module. >> Nothing about automatic modules. > > Correct. Automatic modules are named modules known to the JPMS, just declared implicitly by the JPMS rather than explicitly in the > Java language. Where a named module IS declared explicitly in the Java language, it may reference, in its 'requires' directives, any > other named module known to the JPMS, regardless of whether that other named module is declared implicitly or explicitly. OK, to conform to JLS, a tool doesn't need to know about automatic modules, but a "host system" must support this notion, right? Or will vendors develop their own concepts of automatic modules? The comparison to jar files doesn't help. Not specifying how to interpret a jar file doesn't help standardization, but this is tolerable since the task is trivial: the tool only needs to extract .class files from the zip. For automatic modules the task is not trivial, since a missing module descriptor must be generated. IMHO, a not-optimal situation in the past cannot justify a worse situation (in terms of standardization) going forward. An IDE cannot be expected to run on JRE 9 right now. Hence, the new API may not be available for use in the implementation of the IDE. Thus it is crucial to know, which parts of the API are expected to be implemented by the IDE as part of the "host system" that drives the compiler. The same obviously holds for any other (build) system that drives a compiler. I still hold that the term JPMS is not well-defined. The document at http://cr.openjdk.java.net/~mr/jigsaw/spec/ - which claims to define JPMS - contains a link titled "Java SE Platform API Specification", but I can't find a definition listing which parts of that API define JPMS. What exactly is the extent of JPMS? Stephan From stephan.herrmann at berlin.de Tue Jun 6 10:37:27 2017 From: stephan.herrmann at berlin.de (Stephan Herrmann) Date: Tue, 6 Jun 2017 12:37:27 +0200 Subject: Java Platform Module System - Xlint? In-Reply-To: <5967e898-588d-16dd-b398-831c05ee1766@berlin.de> References: <20170424091831.557135740@eggemoggin.niobe.net> <58FEAB69.2080008@oracle.com> <58FF812E.1010006@oracle.com> <1b984d15-2056-5860-a0b0-40d85edffe42@berlin.de> <5903CF7D.9060803@oracle.com> <1ef5ce0d-f092-b81a-5fb8-c1ea577064d2@berlin.de> <1184f228-0a6d-b2b3-55c5-6123a68ba196@oracle.com> <5967e898-588d-16dd-b398-831c05ee1766@berlin.de> Message-ID: <1545f23a-eaf9-ae66-dce6-364cca20eac9@berlin.de> I didn't see an answer to this question: On 30.04.2017 23:45, Stephan Herrmann wrote: > On 30.04.2017 17:47, Alan Bateman wrote: >> On 30/04/2017 12:10, Stephan Herrmann wrote: >> >>> : >>> >>> Java 9 could make "API leaks" either illegal or ineffective and thus rule out >>> an entire category of ill-formed programs, which to-date must unfortunately >>> be accepted by module-unaware compilers: >>> >>> (A) Java 9 has the opportunity to say that the declaration of m1 is illegal, >>> because it publicly exposes a non-accessible type, which is broken in >>> every regard. >> FWIW, this is -Xlint:exports when using javac, e.g: public class in a non-exported package: >> >> src/m/p/C1.java:4: warning: [exports] class C2 in module m is not exported >> public q.C2 hello() { return null; } >> ^ >> 1 warning >> >> or a non-public class in an exported package: >> >> src/m/p/C1.java:4: warning: [exports] class C2 in module m is not accessible to clients that require this module >> public C2 hello() { return null; } >> ^ >> 1 warning >> >> -Alan > > Thanks for the hint. > > My obvious question: Is this specified (where?), or javac's own deliberation? > Even if the latter, it would be great to see a list of jigsaw related lints. I see several additions to Xlint in https://docs.oracle.com/javase/9/tools/javac.htm Are these Xlint tokens also supported as @SuppressWarnings tokens? If so, we should definitely coordinate between compilers, which requires more specific descriptions of the warnings in each of those categories. "Issues regarding ..." is not very specific :) Stephan From stephan.herrmann at berlin.de Tue Jun 6 11:29:03 2017 From: stephan.herrmann at berlin.de (Stephan Herrmann) Date: Tue, 6 Jun 2017 13:29:03 +0200 Subject: Java Platform Module System In-Reply-To: References: <20170424091831.557135740@eggemoggin.niobe.net> <58FEAB69.2080008@oracle.com> <58FF812E.1010006@oracle.com> <1b984d15-2056-5860-a0b0-40d85edffe42@berlin.de> <5903CF7D.9060803@oracle.com> <30583dc8-b0e3-8d32-4282-0d1936ce54d8@berlin.de> Message-ID: <92b5a382-3e24-e677-03c0-4d4840706f42@berlin.de> On 06.06.2017 11:03, Alan Bateman wrote: > On 06/06/2017 09:40, Stephan Herrmann wrote: >> >> This was viewed from the JLS p.o.v. But "read by M" is still not well-defined. >> All we see in the documentation of the referenced method is: >> >> "a readability graph is computed" >> >> With some further searching, we find "readability graph" explained in the >> toplevel documentation of class Configuration. >> >> But where in the specification (combination of JLS and API doc) should we >> learn the connection between "read" and "requires"? As far as I can see >> this fundamental connection is totally implicit. >> >> I know what is meant, but for the final specification this is still needs >> to be improved. The specification shouldn't expect the reader to already >> know what is specified prior to reading :) >> >> Additionally, this missing link in the specification hides the fact >> that it is unspecified how "transitive" contributes to "reads", >> which is more severe than the editorial aspect of it. > Resolution is specified in the java.lang.module package description (remember this package description was re-worked to address > #ResolutionAtCompileTime [1]). In the JSR's working draft specification, you can find it here: > > http://cr.openjdk.java.net/~mr/jigsaw/spec/api/java/lang/module/package-summary.html > > It's identical to the javadoc that is published with the Jigsaw EA builds. > > -Alan. > > [1] http://openjdk.java.net/projects/jigsaw/spec/issues/#ResolutionAtCompileTime Thanks, found it. For those who already know, the specification is probably sufficient. For those you read JLS, the above definition is not in scope, thus more specific references are still needed. At the bottom line this is another instance of what I just wrote nearby: JPMS lacks precise definition of its extent: what is part of the JPMS and what isn't? I can't be required to read the entire Java SE Platform API Specification. Stephan From jay.a at outlook.in Tue Jun 6 14:24:58 2017 From: jay.a at outlook.in (Jayaprakash Artanareeswaran) Date: Tue, 6 Jun 2017 14:24:58 +0000 Subject: What does a qualified name mean for a module? Message-ID: Hello, The newly introduced ModuleElement has two APIs to get a module's name, namely getQualifiedName() and getSimpleName(). The JLS, though says a module only has one name. "A module name consists of one or more Java identifiers (?3.8) separated by "." tokens." I also see this in the "JPMS: Modules in the Java Language and JVM": ModuleName: Identifier ModuleName . Identifier I am not really sure what a qualifier for a module is. In the given example Module M.N {} are 'M' and 'N' separate names and if so, what do they denote? Jay From alan.bateman at oracle.com Tue Jun 6 15:10:25 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 06 Jun 2017 15:10:25 +0000 Subject: hg: jigsaw/jake/jdk: 2 new changesets Message-ID: <201706061510.v56FAQG5022944@aojmv0008.oracle.com> Changeset: 71dbbbb9d4bd Author: alanb Date: 2017-06-06 13:17 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/71dbbbb9d4bd SL doesn't correct reject a provider two more than one factory method ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/util/ServiceLoader.java ! src/java.base/share/classes/jdk/internal/misc/JavaLangAccess.java ! test/java/util/ServiceLoader/BadProvidersTest.java Changeset: f94b98804c79 Author: alanb Date: 2017-06-06 16:06 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f94b98804c79 Update SL spec to clarify when SCE is thrown ! src/java.base/share/classes/java/util/ServiceConfigurationError.java ! src/java.base/share/classes/java/util/ServiceLoader.java From alex.buckley at oracle.com Tue Jun 6 16:59:31 2017 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 06 Jun 2017 09:59:31 -0700 Subject: What does a qualified name mean for a module? In-Reply-To: References: Message-ID: <5936DF73.1030406@oracle.com> A module name has the same structure as a package name, so ModuleElement has the same shape as PackageElement: each inherits getSimpleName() from Element, and getQualifiedName() from getQualifiedName() from QualifiedNameable. Alex On 6/6/2017 7:24 AM, Jayaprakash Artanareeswaran wrote: > Hello, > > > The newly introduced ModuleElement has two APIs to get a module's name, namely getQualifiedName() and getSimpleName(). The JLS, though says a module only has one name. > > > "A module name consists of one or more Java identifiers (?3.8) separated by "." > tokens." > > > I also see this in the "JPMS: Modules in the Java Language and JVM": > > ModuleName: > Identifier > ModuleName . Identifier > > I am not really sure what a qualifier for a module is. In the given example > > Module M.N {} > > are 'M' and 'N' separate names and if so, what do they denote? > > Jay > From stephan.herrmann at berlin.de Tue Jun 6 17:14:00 2017 From: stephan.herrmann at berlin.de (Stephan Herrmann) Date: Tue, 6 Jun 2017 19:14:00 +0200 Subject: What does a qualified name mean for a module? In-Reply-To: <5936DF73.1030406@oracle.com> References: <5936DF73.1030406@oracle.com> Message-ID: <9fb46a2c-c11f-a1fa-576f-00797c2d9aa0@berlin.de> On 06.06.2017 18:59, Alex Buckley wrote: > A module name has the same structure as a package name, so ModuleElement has the same shape as PackageElement: each inherits > getSimpleName() from Element, and getQualifiedName() from getQualifiedName() from QualifiedNameable. Syntactically you're right, but ... Normally, a qualified name denotes two things: a parent element and a child. The package name "java.lang" has a qualifier "java" which denotes a top-level package and "lang" can be used relative to that package to denote a member package etc. For a module - say "java.base" - the qualifier "java" denotes nothing. And hence, the simple name "base" cannot be resolved in any context. So the question is: should ModuleElement.getSimpleName() answer the totally useless last segment of the name, or should it answer the same as getQualifiedName()? Stephan > > Alex > > On 6/6/2017 7:24 AM, Jayaprakash Artanareeswaran wrote: >> Hello, >> >> >> The newly introduced ModuleElement has two APIs to get a module's name, namely getQualifiedName() and getSimpleName(). The JLS, >> though says a module only has one name. >> >> >> "A module name consists of one or more Java identifiers (?3.8) separated by "." >> tokens." >> >> >> I also see this in the "JPMS: Modules in the Java Language and JVM": >> >> ModuleName: >> Identifier >> ModuleName . Identifier >> >> I am not really sure what a qualifier for a module is. In the given example >> >> Module M.N {} >> >> are 'M' and 'N' separate names and if so, what do they denote? >> >> Jay >> From david.lloyd at redhat.com Tue Jun 6 17:35:18 2017 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 6 Jun 2017 12:35:18 -0500 Subject: What does a qualified name mean for a module? In-Reply-To: <9fb46a2c-c11f-a1fa-576f-00797c2d9aa0@berlin.de> References: <5936DF73.1030406@oracle.com> <9fb46a2c-c11f-a1fa-576f-00797c2d9aa0@berlin.de> Message-ID: On 06/06/2017 12:14 PM, Stephan Herrmann wrote: > On 06.06.2017 18:59, Alex Buckley wrote: >> A module name has the same structure as a package name, so >> ModuleElement has the same shape as PackageElement: each inherits >> getSimpleName() from Element, and getQualifiedName() from >> getQualifiedName() from QualifiedNameable. > > Syntactically you're right, but ... > > Normally, a qualified name denotes two things: a parent element and a > child. > The package name "java.lang" has a qualifier "java" which denotes a > top-level package > and "lang" can be used relative to that package to denote a member > package etc. > > For a module - say "java.base" - the qualifier "java" denotes nothing. > And hence, the simple name "base" cannot be resolved in any context. > > So the question is: should ModuleElement.getSimpleName() answer the > totally useless last segment of the name, or should it answer the same > as getQualifiedName()? The answer to that question should apply to PackageElement too, for identical reasons. However, PackageElement is established API already... -- - DML From misterm at gmail.com Tue Jun 6 17:46:29 2017 From: misterm at gmail.com (Michael Nascimento) Date: Tue, 6 Jun 2017 14:46:29 -0300 Subject: What does a qualified name mean for a module? In-Reply-To: References: <5936DF73.1030406@oracle.com> <9fb46a2c-c11f-a1fa-576f-00797c2d9aa0@berlin.de> Message-ID: It'd be quite odd if ModuleElement and PackageElement implementations of getSimpleName() differed. Since PackageElement.getSimpleName() is around and has defined behaviour, ModuleElement must follow it imho. Regards, Michael On Tue, Jun 6, 2017 at 2:35 PM, David M. Lloyd wrote: > On 06/06/2017 12:14 PM, Stephan Herrmann wrote: > >> On 06.06.2017 18:59, Alex Buckley wrote: >> >>> A module name has the same structure as a package name, so ModuleElement >>> has the same shape as PackageElement: each inherits getSimpleName() from >>> Element, and getQualifiedName() from getQualifiedName() from >>> QualifiedNameable. >>> >> >> Syntactically you're right, but ... >> >> Normally, a qualified name denotes two things: a parent element and a >> child. >> The package name "java.lang" has a qualifier "java" which denotes a >> top-level package >> and "lang" can be used relative to that package to denote a member >> package etc. >> >> For a module - say "java.base" - the qualifier "java" denotes nothing. >> And hence, the simple name "base" cannot be resolved in any context. >> >> So the question is: should ModuleElement.getSimpleName() answer the >> totally useless last segment of the name, or should it answer the same >> as getQualifiedName()? >> > > The answer to that question should apply to PackageElement too, for > identical reasons. However, PackageElement is established API already... > > -- > - DML > From stephan.herrmann at berlin.de Tue Jun 6 18:28:01 2017 From: stephan.herrmann at berlin.de (Stephan Herrmann) Date: Tue, 6 Jun 2017 20:28:01 +0200 Subject: What does a qualified name mean for a module? In-Reply-To: References: <5936DF73.1030406@oracle.com> <9fb46a2c-c11f-a1fa-576f-00797c2d9aa0@berlin.de> Message-ID: <5ff72f0d-c39e-fabe-895a-f7d5304ed260@berlin.de> On 06.06.2017 19:35, David M. Lloyd wrote: > On 06/06/2017 12:14 PM, Stephan Herrmann wrote: >> On 06.06.2017 18:59, Alex Buckley wrote: >>> A module name has the same structure as a package name, so ModuleElement has the same shape as PackageElement: each inherits >>> getSimpleName() from Element, and getQualifiedName() from getQualifiedName() from QualifiedNameable. >> >> Syntactically you're right, but ... >> >> Normally, a qualified name denotes two things: a parent element and a child. >> The package name "java.lang" has a qualifier "java" which denotes a top-level package >> and "lang" can be used relative to that package to denote a member package etc. >> >> For a module - say "java.base" - the qualifier "java" denotes nothing. >> And hence, the simple name "base" cannot be resolved in any context. >> >> So the question is: should ModuleElement.getSimpleName() answer the >> totally useless last segment of the name, or should it answer the same >> as getQualifiedName()? > > The answer to that question should apply to PackageElement too, for identical reasons. However, PackageElement is established API > already... > For packages it is established confusion that some say, a package "java.lang" has a parent package "java" so that "lang" can be resolved as a member of that parent, and others say that the structure of package names bears no semantic significance. For the former group the simple name of a package has significance, for the latter it doesn't. Both are right For modules there is only the latter view, there is no JLS 6.5.3.2 for modules. But if some spec will say what a simple name of a module is, it's of course trivial to implement (and hopefully nobody will be tempted to use that method). Stephan From alex.buckley at oracle.com Tue Jun 6 19:51:26 2017 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 06 Jun 2017 12:51:26 -0700 Subject: What does a qualified name mean for a module? In-Reply-To: <9fb46a2c-c11f-a1fa-576f-00797c2d9aa0@berlin.de> References: <5936DF73.1030406@oracle.com> <9fb46a2c-c11f-a1fa-576f-00797c2d9aa0@berlin.de> Message-ID: <593707BE.1050700@oracle.com> On 6/6/2017 10:14 AM, Stephan Herrmann wrote: > Normally, a qualified name denotes two things: a parent element and a > child. The package name "java.lang" has a qualifier "java" which > denotes a top-level package and "lang" can be used relative to that > package to denote a member package etc. > > For a module - say "java.base" - the qualifier "java" denotes > nothing. And hence, the simple name "base" cannot be resolved in any > context. > > So the question is: should ModuleElement.getSimpleName() answer the > totally useless last segment of the name, or should it answer the > same as getQualifiedName()? When Joe asked for feedback on this API two months ago [1], I made essentially the same point [2], and a bug was filed [3]. Alex [1] http://mail.openjdk.java.net/pipermail/compiler-dev/2017-April/010896.html [2] http://mail.openjdk.java.net/pipermail/compiler-dev/2017-April/010905.html [3] https://bugs.openjdk.java.net/browse/JDK-8163989 From stephan.herrmann at berlin.de Tue Jun 6 21:28:58 2017 From: stephan.herrmann at berlin.de (Stephan Herrmann) Date: Tue, 6 Jun 2017 23:28:58 +0200 Subject: "The unnamed module reads every other module." Message-ID: <9a66ad2b-ad06-4dbd-c6cf-702ab9ddde2a@berlin.de> SOTMS says: "The unnamed module reads every other module." I am unable to find any similar statement in any specification. Where should I be looking? Stephan From alex.buckley at oracle.com Tue Jun 6 21:40:52 2017 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 06 Jun 2017 14:40:52 -0700 Subject: "The unnamed module reads every other module." In-Reply-To: <9a66ad2b-ad06-4dbd-c6cf-702ab9ddde2a@berlin.de> References: <9a66ad2b-ad06-4dbd-c6cf-702ab9ddde2a@berlin.de> Message-ID: <59372164.5080502@oracle.com> On 6/6/2017 2:28 PM, Stephan Herrmann wrote: > SOTMS says: "The unnamed module reads every other module." > > I am unable to find any similar statement in any specification. > Where should I be looking? The unnamed module is never resolved, so it doesn't feature in the reworked spec for Resolution in java.lang.module. Instead, the dependences and exports of unnamed modules are specified in new text in JLS 7.7.5 and JVMS 5.3.6. Alex From stephan.herrmann at berlin.de Tue Jun 6 21:55:29 2017 From: stephan.herrmann at berlin.de (Stephan Herrmann) Date: Tue, 6 Jun 2017 23:55:29 +0200 Subject: "The unnamed module reads every other module." In-Reply-To: <59372164.5080502@oracle.com> References: <9a66ad2b-ad06-4dbd-c6cf-702ab9ddde2a@berlin.de> <59372164.5080502@oracle.com> Message-ID: <7ef75315-f3b4-6a72-f155-b5346c564114@berlin.de> On 06.06.2017 23:40, Alex Buckley wrote: > On 6/6/2017 2:28 PM, Stephan Herrmann wrote: >> SOTMS says: "The unnamed module reads every other module." >> >> I am unable to find any similar statement in any specification. >> Where should I be looking? > > The unnamed module is never resolved, so it doesn't feature in the reworked spec for Resolution in java.lang.module. Instead, the > dependences and exports of unnamed modules are specified in new text in JLS 7.7.5 and JVMS 5.3.6. > > Alex Show me. I don't see anything relating to "dependences and exports of unnamed modules" in either document, versions 2017-05-25 and 2017-02-22 respectively, which for me are the current versions linked from http://cr.openjdk.java.net/~mr/jigsaw/spec/ Stephan From alex.buckley at oracle.com Tue Jun 6 21:58:55 2017 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 06 Jun 2017 14:58:55 -0700 Subject: "The unnamed module reads every other module." In-Reply-To: <7ef75315-f3b4-6a72-f155-b5346c564114@berlin.de> References: <9a66ad2b-ad06-4dbd-c6cf-702ab9ddde2a@berlin.de> <59372164.5080502@oracle.com> <7ef75315-f3b4-6a72-f155-b5346c564114@berlin.de> Message-ID: <5937259F.4090802@oracle.com> On 6/6/2017 2:55 PM, Stephan Herrmann wrote: > On 06.06.2017 23:40, Alex Buckley wrote: >> On 6/6/2017 2:28 PM, Stephan Herrmann wrote: >>> SOTMS says: "The unnamed module reads every other module." >>> >>> I am unable to find any similar statement in any specification. >>> Where should I be looking? >> >> The unnamed module is never resolved, so it doesn't feature in the >> reworked spec for Resolution in java.lang.module. Instead, the >> dependences and exports of unnamed modules are specified in new text >> in JLS 7.7.5 and JVMS 5.3.6. >> >> Alex > > Show me. > > I don't see anything relating to "dependences and exports of unnamed > modules" > in either document, versions 2017-05-25 and 2017-02-22 respectively, > which for me are the current versions linked from > http://cr.openjdk.java.net/~mr/jigsaw/spec/ It's new text, it hasn't been published yet. From peter.levart at gmail.com Wed Jun 7 06:02:34 2017 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 7 Jun 2017 08:02:34 +0200 Subject: Proposal (revised): Allow illegal access to internal APIs by default in JDK 9 In-Reply-To: <20170605184527.6BD13EE310@eggemoggin.niobe.net> References: <20170605184527.6BD13EE310@eggemoggin.niobe.net> Message-ID: Hi, I think the fine-tuning is right to the point now. Allows most of what was allowed in JDK8, but no more than that. Regards, Peter On 06/05/2017 08:45 PM, mark.reinhold at oracle.com wrote: > (Thanks for all the feedback on the initial proposal [1]. Here's a > revised version, which incorporates some of the suggestions received and > includes a bit more advice. An implementation is already available for > testing in the Jigsaw EA builds [2]. Further comments welcome!) > > Over time, as we've gotten closer and closer to the JDK 9 GA date, more > and more developers have begun paying attention to the actual changes in > this release. The strong encapsulation of JDK-internal APIs has, in > particular, triggered many worried expressions of concern that code that > works on JDK 8 today will not work on JDK 9 tomorrow, yet no advance > warning of this change was given at run time in JDK 8. > > To help the entire ecosystem migrate to the modular Java platform at a > more relaxed pace I hereby propose to allow illegal-access operations to > internal APIs from code on the class path by default in JDK 9, and to > disallow them in a future release. This will enable smoother application > migration in the near term, yet still enable and motivate the maintainers > of libraries and frameworks that use JDK-internal APIs to fix their code > to use proper exported APIs. > > New command-line option: `--illegal-access` > ------------------------------------------- > > The recently-introduced `--permit-illegal-access` option [3] will be > replaced by a more-general option, `--illegal-access`. This option takes > a single keyword parameter to specify a mode of operation, as follows: > > `--illegal-access=permit` > > This mode opens each package in each module in the run-time image to > code in all unnamed modules, i.e., code on the class path, if that > package existed in JDK 8. This enables both static access, i.e., by > compiled bytecode, and deep reflective access, via the platform's > various reflection APIs. > > The first reflective-access operation to any such package causes a > warning to be issued, but no warnings are issued after that point. > This single warning describes how to enable further warnings. > > This mode will be the default for JDK 9. It will be removed in a > future release. > > `--illegal-access=warn` > > This mode is identical to `permit` except that a warning message is > issued for each illegal reflective-access operation. This is roughly > equivalent to the current `--permit-illegal-access` option. > > `--illegal-access=debug` > > This mode is identical to `warn` except both a warning message and a > stack trace are issued for each illegal reflective-access operation. > This is roughly equivalent to combining `--permit-illegal-access` > with `-Dsun.reflect.debugModuleAccessChecks`. > > `--illegal-access=deny` > > This mode disables all illegal-access operations except for those > enabled by other command-line options, e.g., `--add-opens`. > > This mode will become the default in a future release. > > When `deny` becomes the default mode then `permit` will likely remain > supported for at least one release, so that developers can continue to > migrate their code. The `permit`, `warn`, and `debug` modes will, over > time, be removed, as will the `--illegal-access` option itself. (For > launch-script compatibility the unsupported modes will most likely just > be ignored, after issuing a warning to that effect.) > > How to prepare for the future > ----------------------------- > > The default mode, `--illegal-access=permit`, is intended to make you > aware when you have code on the class path that reflectively accesses > some JDK-internal API at least once. To learn about all such accesses > you can use the `warn` or `debug` modes. For each library or framework > on the class path that requires illegal access you have two options: > > - If the component's maintainers have already released a new, > fixed version that no longer uses JDK-internal APIs then you > can consider upgrading to that version. > > - If the component still needs to be fixed then we encourage you > to contact its maintainers and ask them to replace their use > of JDK-internal APIs with proper exported APIs [4]. > > If you must continue to use a component that requires illegal access then > you can eliminate the warning messages by using one or more `--add-opens` > options to open just those internal packages to which access is required. > > To verify that your application is ready for the future, run it with > `--illegal-access=deny` along with any necessary `--add-opens` options. > Any remaining illegal-access errors will most likely be due to static > references from compiled code to JDK-internal APIs. You can identify > those by running the `jdeps` tool with the `--jdk-internals` option. > (JDK 9 does not issue warnings for illegal static-access operations > because that would require deep JVM changes and degrade performance.) > > Warning messages > ---------------- > > The warning message issued when an illegal reflective-access operation is > detected has the following form: > > WARNING: Illegal reflective access by $PERPETRATOR to $VICTIM > > where: > > - $PERPETRATOR is the fully-qualified name of the type containing > the code that invoked the reflective operation in question plus > the code source (i.e., JAR-file path), if available, and > > - $VICTIM is a string that describes the member being accessed, > including the fully-qualified name of the enclosing type > > In JDK 9's default mode, `--illegal-access=permit`, at most one of these > warning messages will be issued, accompanied by additional instructive > text. Here is an example, from running Jython on the current Jigsaw EA > build [2]: > > $ java -jar jython-standalone-2.7.0.jar > WARNING: An illegal reflective access operation has occurred > WARNING: Illegal reflective access by jnr.posix.JavaLibCHelper (file:/tmp/jython-standalone-2.7.0.jar) to method sun.nio.ch.SelChImpl.getFD() > WARNING: Please consider reporting this to the maintainers of jnr.posix.JavaLibCHelper > 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 > Jython 2.7.0 (default:9987c746f838, Apr 29 2015, 02:25:11) > [OpenJDK 64-Bit Server VM (Oracle Corporation)] on java9-internal > Type "help", "copyright", "credits" or "license" for more information. > >>> ^D > $ > > If `--illegal-access=warn` is used then only warnings are displayed, with > no instructive text. The run-time system makes a best-effort attempt to > suppress duplicate warnings for the same $PERPETRATOR and $VICTIM. Here > is an example, again running Jython: > > $ java --illegal-access=warn -jar jython-standalone-2.7.0.jar > WARNING: Illegal reflective access by jnr.posix.JavaLibCHelper (file:/tmp/jython-standalone-2.7.0.jar) to method sun.nio.ch.SelChImpl.getFD() > WARNING: Illegal reflective access by jnr.posix.JavaLibCHelper (file:/tmp/jython-standalone-2.7.0.jar) to field sun.nio.ch.FileChannelImpl.fd > WARNING: Illegal reflective access by jnr.posix.JavaLibCHelper (file:/tmp/jython-standalone-2.7.0.jar) to field java.io.FileDescriptor.fd > WARNING: Illegal reflective access by org.python.core.PySystemState (file:/tmp/jython-standalone-2.7.0.jar) to method java.io.Console.encoding() > Jython 2.7.0 (default:9987c746f838, Apr 29 2015, 02:25:11) > [OpenJDK 64-Bit Server VM (Oracle Corporation)] on java9-internal > Type "help", "copyright", "credits" or "license" for more information. > >>> ^D > $ > > Notes > ----- > > - There is no `--illegal-access` mode that suppresses all warnings. > This is intentional: It ensures that developers know that all > illegal-access operations will be denied by default in a future > release, at which time code that generates warnings today will fail. > Warnings can be suppressed completely via one or more `--add-opens` > options. > > - The first proposal [1] opened every package in every explicit module, > rather than just the packages in modules in the run-time image, to > every unnamed module. Peter Levart pointed out [5] that this could > tempt developers to use internal APIs that are new in JDK 9 (e.g., > `jdk.internal.misc.Unsafe`) and thus make the eventual transition > from JDK 9 no less painful than that from JDK 8. This proposal thus > only opens internal packages that existed in JDK 8. > > - This proposal will require adjustments to JEP 260, "Encapsulate Most > Internal APIs" [6]. APIs that are internal to the JDK will still be > strongly encapsulated from the standpoint of code in modules, whether > those modules are automatic or explicit, but they will not appear to > be encapsulated at run time from the standpoint of code on the class > path. > > - This change will not magically solve every JDK 9 adoption problem. > The concrete types of the built-in class loaders are still different, > `rt.jar` is still gone, the layout of a system image is still not the > same, and the version string still has a new format. > > > [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012673.html > [2] http://jdk.java.net/jigsaw/ > [3] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-March/011763.html > [4] This will usually but not always be possible, since there are still a > few critical internal APIs without exported replacements [6]. > [5] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012708.html > [6] http://openjdk.java.net/jeps/260 From Alan.Bateman at oracle.com Wed Jun 7 10:36:11 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 7 Jun 2017 11:36:11 +0100 Subject: Request Review: JDK-8181639 Add tool and services information to module summary In-Reply-To: <31753324-11A0-419F-BB8B-76FF9E01A258@oracle.com> References: <31753324-11A0-419F-BB8B-76FF9E01A258@oracle.com> Message-ID: (Moving this review thread to jigsaw-dev as this is module descriptions). On 07/06/2017 06:49, Mandy Chung wrote: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8181639/webrev.00 > > Updated javadoc: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8181639/api/ > > This patch mainly adds @uses, @provides and description of providers and tools. This uses description list ?dl? to list ?Providers?, ?Specifications?, ?Tool Guides? in JDK 9. In the future this can be converted to custom taglets. > I agree a taglet would be useful here, especially as the style specified to the "dl" tag is copied to many places. One question for Jon on javadoc: Should the Uses and Provides in the javadoc print the fully qualified name rather than the simple name? I found myself several times needing to click on the simple name to see which area the provider interface is defined in. I went through all of the updates and have a number of comments/suggestions: jdk.hotspot.agent - I think this would be a bit easier to read if we replace "that can attach" with "to attach". java.base - To date, we've used "jrt file system provider" rather than "JRT FileSystem provider" and it should be good to keep that consistent. - The URI should be "jrt:/" rather than "jrt". - What would you think about "to enumerate" rather than "than can enumerate". - "can be loaded" -> "can be created". java.desktop - I'm in two minds so to whether the @provides should be documented in this module. This is a case where the docs should make it clear that the java.desktop includes built-in implementations and list the image and sound formats that are supported. java.rmi - What would you think about trimming this down to: "The JDK implementation of this module includes the rmiregistry tool to start a remote object registry, and the rmid tool to start the activation system daemon". (I've switched the order too because rmid is less interesting to know about). java.scripting - There's a spurious "*" in the description - Typo "language" -> "languages". jdk.jartool - The sentence starting "Instances are ..." follows from the previous sentence so I think the paragraph break should be removed. - The statement that jarsigner does not provide an API is confusing as the module exports two APIs for JAR signing. I think you mean the ToolProvider and maybe it would be simpler to just drop the sentence. jdk.jlink - it might be simpler to list the tools at the start so that it reads: "Defines the jlink tool for creating run-time images, the jmod tool for creating and manipulating JMOD files, and the jimage tool for inspecting the JDK-internal container file for classes and resources". This ordering then matches the links to the man pages. jdk.management.agent - it might be better to say "allows" rather than "enables" as it needs configuration to enable. jdk.zipfs - "and the ability" - I assume this should be "and provides the ability". - I think we should remove the reference to FileSystemProviders.installedProviders() as that is not the API that applications will use to create a zip file system. Instead we can link to FileSystems.newFileSystem. I also think we need a table in this javadoc to document the "create" and "encoding" properties. jdk.security.auth - your update looks fine but we should probably submit a bug to get package descriptions added or maybe more text as it's not immediately obvious what one can do with this module. jdk.scripting.nashorn - the existing module-info.java is inconsistent with the other module descriptions. Now might be the opportunity to reformat this. jdk.scripting.nashorn.shell - it might be better to say "the command line tool" rather than "a command line tool". I think that is all that I have. -Alan. From mandy.chung at oracle.com Wed Jun 7 17:58:45 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 7 Jun 2017 10:58:45 -0700 Subject: Request Review: JDK-8181639 Add tool and services information to module summary In-Reply-To: References: <31753324-11A0-419F-BB8B-76FF9E01A258@oracle.com> Message-ID: <855EE474-81B5-40BB-900A-A758C5CA61C8@oracle.com> I updated the javadoc per your comment/suggestion. My reply to some of your comments are inlined below. Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8181639/webrev.01/ Module summary pages: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8181639/api/ > On Jun 7, 2017, at 3:36 AM, Alan Bateman wrote: > java.desktop > - I'm in two minds so to whether the @provides should be documented in this module. This is a case where the docs should make it clear that the java.desktop includes built-in implementations and list the image and sound formats that are supported. > That?s a fair point. I took out @provides and will file a JBS issue for the client team to document the builtin providers as appropriate. > jdk.zipfs > I also think we need a table in this javadoc to document the "create" and "encoding" properties. > I agree. I will file a JBS issue for this. > jdk.security.auth > - your update looks fine but we should probably submit a bug to get package descriptions added or maybe more text as it's not immediately obvious what one can do with this module. > and jdk.xml.dom as well. Will file issues to track this. > jdk.scripting.nashorn > - the existing module-info.java is inconsistent with the other module descriptions. Now might be the opportunity to reformat this. I was tempted to reformat it and now I have done it in webrev.01. Mandy From jonathan.gibbons at oracle.com Wed Jun 7 18:10:18 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 07 Jun 2017 11:10:18 -0700 Subject: Request Review: JDK-8181639 Add tool and services information to module summary In-Reply-To: References: <31753324-11A0-419F-BB8B-76FF9E01A258@oracle.com> Message-ID: <5938418A.1020202@oracle.com> On 06/07/2017 03:36 AM, Alan Bateman wrote: > I agree a taglet would be useful here, especially as the style > specified to the "dl" tag is copied to many places. Agreed, but it seemed too late to add that. We'll need to do a round of cleanup for javadoc support for modules. -- Jon From lance.andersen at oracle.com Wed Jun 7 19:38:14 2017 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 7 Jun 2017 15:38:14 -0400 Subject: Request Review: JDK-8181639 Add tool and services information to module summary In-Reply-To: <855EE474-81B5-40BB-900A-A758C5CA61C8@oracle.com> References: <31753324-11A0-419F-BB8B-76FF9E01A258@oracle.com> <855EE474-81B5-40BB-900A-A758C5CA61C8@oracle.com> Message-ID: <8ACAC69E-BA75-40DF-B800-D82C3A410049@oracle.com> Looks good Mandy > On Jun 7, 2017, at 1:58 PM, Mandy Chung wrote: > > I updated the javadoc per your comment/suggestion. My reply to some > of your comments are inlined below. > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8181639/webrev.01/ > > Module summary pages: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8181639/api/ > > >> On Jun 7, 2017, at 3:36 AM, Alan Bateman wrote: >> java.desktop >> - I'm in two minds so to whether the @provides should be documented in this module. This is a case where the docs should make it clear that the java.desktop includes built-in implementations and list the image and sound formats that are supported. >> > > That?s a fair point. I took out @provides and will file a JBS issue > for the client team to document the builtin providers as appropriate. > >> jdk.zipfs >> I also think we need a table in this javadoc to document the "create" and "encoding" properties. >> > > I agree. I will file a JBS issue for this. > >> jdk.security.auth >> - your update looks fine but we should probably submit a bug to get package descriptions added or maybe more text as it's not immediately obvious what one can do with this module. >> > > and jdk.xml.dom as well. Will file issues to track this. > >> jdk.scripting.nashorn >> - the existing module-info.java is inconsistent with the other module descriptions. Now might be the opportunity to reformat this. > > I was tempted to reformat it and now I have done it in webrev.01. > > Mandy > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From Alan.Bateman at oracle.com Wed Jun 7 20:39:27 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 7 Jun 2017 21:39:27 +0100 Subject: Request Review: JDK-8181639 Add tool and services information to module summary In-Reply-To: <855EE474-81B5-40BB-900A-A758C5CA61C8@oracle.com> References: <31753324-11A0-419F-BB8B-76FF9E01A258@oracle.com> <855EE474-81B5-40BB-900A-A758C5CA61C8@oracle.com> Message-ID: <1c084195-df2a-6afc-282a-630166016304@oracle.com> On 07/06/2017 18:58, Mandy Chung wrote: > I updated the javadoc per your comment/suggestion. My reply to some > of your comments are inlined below. > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8181639/webrev.01/ > > Module summary pages: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8181639/api/ > I went through all the module descriptions and everything looks good. One small typo in java.base where it says "of jrt file ..." when I think it should be "of the jrt file ..." -Alan From mandy.chung at oracle.com Thu Jun 8 01:51:53 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 7 Jun 2017 18:51:53 -0700 Subject: Request Review: JDK-8181639 Add tool and services information to module summary In-Reply-To: <1c084195-df2a-6afc-282a-630166016304@oracle.com> References: <31753324-11A0-419F-BB8B-76FF9E01A258@oracle.com> <855EE474-81B5-40BB-900A-A758C5CA61C8@oracle.com> <1c084195-df2a-6afc-282a-630166016304@oracle.com> Message-ID: > On Jun 7, 2017, at 1:39 PM, Alan Bateman wrote: > > On 07/06/2017 18:58, Mandy Chung wrote: >> I updated the javadoc per your comment/suggestion. My reply to some >> of your comments are inlined below. >> >> Webrev: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8181639/webrev.01/ >> >> Module summary pages: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8181639/api/ >> > I went through all the module descriptions and everything looks good. One small typo in java.base where it says "of jrt file ..." when I think it should be "of the jrt file ?" Will fix this before pushing it. Mandy From alan.bateman at oracle.com Thu Jun 8 18:50:55 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 08 Jun 2017 18:50:55 +0000 Subject: hg: jigsaw/jake: 4 new changesets Message-ID: <201706081850.v58Iot3Y024231@aojmv0008.oracle.com> Changeset: 3ad8b22b022c Author: rriggs Date: 2017-06-01 10:21 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/3ad8b22b022c 8181156: html5 issues in java.base javadoc Reviewed-by: ihse, erikj ! make/CompileJavaModules.gmk Changeset: 88d7fd969e7d Author: lana Date: 2017-06-01 18:48 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/88d7fd969e7d Merge Changeset: 4cdfea93f3f4 Author: lana Date: 2017-06-08 16:32 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/4cdfea93f3f4 Added tag jdk-9+173 for changeset 88d7fd969e7d ! .hgtags Changeset: c3747a90c058 Author: alanb Date: 2017-06-08 18:34 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/c3747a90c058 Merge ! .hgtags ! make/CompileJavaModules.gmk From alan.bateman at oracle.com Thu Jun 8 18:50:53 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 08 Jun 2017 18:50:53 +0000 Subject: hg: jigsaw/jake/jaxp: 2 new changesets Message-ID: <201706081850.v58IorYa024145@aojmv0008.oracle.com> Changeset: 67ce05675aaf Author: lana Date: 2017-06-08 16:32 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/67ce05675aaf Added tag jdk-9+173 for changeset 9788347e0629 ! .hgtags Changeset: 21950dd23de4 Author: alanb Date: 2017-06-08 18:38 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/21950dd23de4 Merge ! .hgtags From alan.bateman at oracle.com Thu Jun 8 18:50:52 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 08 Jun 2017 18:50:52 +0000 Subject: hg: jigsaw/jake/jaxws: 2 new changesets Message-ID: <201706081850.v58IoqHn024103@aojmv0008.oracle.com> Changeset: 40b9dc95ccbb Author: lana Date: 2017-06-08 16:32 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/40b9dc95ccbb Added tag jdk-9+173 for changeset 2bd967aa452c ! .hgtags Changeset: e59303e8d946 Author: alanb Date: 2017-06-08 18:38 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/e59303e8d946 Merge ! .hgtags From alan.bateman at oracle.com Thu Jun 8 18:50:56 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 08 Jun 2017 18:50:56 +0000 Subject: hg: jigsaw/jake/langtools: 5 new changesets Message-ID: <201706081850.v58IovX3024252@aojmv0008.oracle.com> Changeset: 5be57bc01147 Author: mchung Date: 2017-05-30 14:11 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/5be57bc01147 8181148: Update the jdeps tool to list exported packages instead of just internal APIs Reviewed-by: psandoz - make/src/classes/build/tools/listjdkinternals/ListJDKInternals.java Changeset: eaee37d37d51 Author: lana Date: 2017-06-01 18:49 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/eaee37d37d51 Merge - make/src/classes/build/tools/listjdkinternals/ListJDKInternals.java Changeset: 123eb0956a45 Author: ksrini Date: 2017-06-02 13:38 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/123eb0956a45 8181441: Fix minor typo/link in the old standard doclet API documentation Reviewed-by: jjg ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/Taglet.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/standard/Standard.java Changeset: ff9b23e56b10 Author: lana Date: 2017-06-08 16:32 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/ff9b23e56b10 Added tag jdk-9+173 for changeset 123eb0956a45 ! .hgtags Changeset: 89a9c0aca926 Author: alanb Date: 2017-06-08 18:37 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/89a9c0aca926 Merge ! .hgtags - make/src/classes/build/tools/listjdkinternals/ListJDKInternals.java From alan.bateman at oracle.com Thu Jun 8 18:50:57 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 08 Jun 2017 18:50:57 +0000 Subject: hg: jigsaw/jake/hotspot: 8 new changesets Message-ID: <201706081850.v58Iovi7024257@aojmv0008.oracle.com> Changeset: e939acda146e Author: vlivanov Date: 2017-05-30 21:35 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e939acda146e 8179882: C2: Stale control info after cast node elimination during loop optimization pass Reviewed-by: kvn, roland ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopopts.cpp Changeset: c0501ae2ceda Author: lana Date: 2017-06-01 18:48 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c0501ae2ceda Merge Changeset: 3ee42d818496 Author: roland Date: 2017-06-02 09:08 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3ee42d818496 8179678: ArrayCopy with same src and dst can cause incorrect execution or compiler crash Summary: Replacing load on dst with load on src only valid if copy doesn't modify src element to load Reviewed-by: kvn, thartmann ! src/share/vm/opto/arraycopynode.cpp ! src/share/vm/opto/arraycopynode.hpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/macroArrayCopy.cpp ! src/share/vm/opto/memnode.cpp + test/compiler/arraycopy/TestACSameSrcDst.java Changeset: e5192b08213c Author: ihse Date: 2017-06-02 14:29 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e5192b08213c 8180322: Move JNI spec to specs directory Reviewed-by: mchung, dholmes ! src/share/vm/prims/jvmti.xml Changeset: e271f2b09a39 Author: bobv Date: 2017-06-02 10:35 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e271f2b09a39 8181093: assert(si->is_ldr_literal()) failed on arm64 test nsk/jdi/.../returnValue004 Reviewed-by: kvn, dlong ! src/cpu/arm/vm/relocInfo_arm.cpp Changeset: e64b1cb48d6e Author: bobv Date: 2017-06-02 10:37 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e64b1cb48d6e Merge Changeset: 7f45d3d72a9b Author: lana Date: 2017-06-08 16:32 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7f45d3d72a9b Added tag jdk-9+173 for changeset e64b1cb48d6e ! .hgtags Changeset: 9ace2316ce1c Author: alanb Date: 2017-06-08 18:39 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9ace2316ce1c Merge ! .hgtags ! src/share/vm/prims/jvmti.xml From alan.bateman at oracle.com Thu Jun 8 18:50:56 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 08 Jun 2017 18:50:56 +0000 Subject: hg: jigsaw/jake/nashorn: 2 new changesets Message-ID: <201706081850.v58IouDr024245@aojmv0008.oracle.com> Changeset: df6109f734e8 Author: lana Date: 2017-06-08 16:32 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/df6109f734e8 Added tag jdk-9+173 for changeset fa8e4de50e82 ! .hgtags Changeset: 53da60749b59 Author: alanb Date: 2017-06-08 18:38 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/53da60749b59 Merge ! .hgtags From alan.bateman at oracle.com Thu Jun 8 18:50:58 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 08 Jun 2017 18:50:58 +0000 Subject: hg: jigsaw/jake/jdk: 13 new changesets Message-ID: <201706081850.v58IowrT024306@aojmv0008.oracle.com> Changeset: 54551ea84184 Author: mchung Date: 2017-05-30 14:12 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/54551ea84184 8181148: Update the jdeps tool to list exported packages instead of just internal APIs Reviewed-by: psandoz + make/src/classes/build/tools/jigsaw/ListPackages.java Changeset: 4c0054896900 Author: jjg Date: 2017-05-30 15:48 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4c0054896900 8181290: Invalid HTML 5 in core-libs docs Reviewed-by: mchung, lancea ! src/java.base/share/classes/java/lang/invoke/package-info.java ! src/java.base/share/classes/java/lang/module/package-info.java ! src/java.base/share/classes/java/lang/package-info.java ! src/java.base/share/classes/java/net/doc-files/net-properties.html ! src/java.base/share/classes/java/nio/channels/package-info.java ! src/java.base/share/classes/java/nio/file/package-info.java ! src/java.base/share/classes/java/nio/package-info.java ! src/java.base/share/classes/java/util/package-info.java ! src/java.base/share/classes/java/util/zip/package-info.java Changeset: 02bd39544ff1 Author: mli Date: 2017-05-31 19:54 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/02bd39544ff1 8181082: class-level since tag issues in java.base & java.datatransfer module Reviewed-by: alanb, serb ! src/java.base/share/classes/java/lang/RuntimePermission.java ! src/java.base/share/classes/java/lang/reflect/Array.java ! src/java.base/share/classes/java/lang/reflect/Constructor.java ! src/java.base/share/classes/java/lang/reflect/Field.java ! src/java.base/share/classes/java/lang/reflect/InvocationTargetException.java ! src/java.base/share/classes/java/lang/reflect/Member.java ! src/java.base/share/classes/java/lang/reflect/Method.java ! src/java.base/share/classes/java/lang/reflect/Modifier.java ! src/java.base/share/classes/java/math/BigDecimal.java ! src/java.base/share/classes/java/net/NetPermission.java ! src/java.base/share/classes/java/net/SocketOptions.java ! src/java.base/share/classes/java/net/SocketPermission.java ! src/java.base/share/classes/java/security/AccessControlContext.java ! src/java.base/share/classes/java/security/AccessControlException.java ! src/java.base/share/classes/java/security/AccessController.java ! src/java.base/share/classes/java/security/AllPermission.java ! src/java.base/share/classes/java/security/BasicPermission.java ! src/java.base/share/classes/java/security/Certificate.java ! src/java.base/share/classes/java/security/CodeSource.java ! src/java.base/share/classes/java/security/DigestException.java ! src/java.base/share/classes/java/security/DigestInputStream.java ! src/java.base/share/classes/java/security/DigestOutputStream.java ! src/java.base/share/classes/java/security/GeneralSecurityException.java ! src/java.base/share/classes/java/security/Guard.java ! src/java.base/share/classes/java/security/GuardedObject.java ! src/java.base/share/classes/java/security/Identity.java ! src/java.base/share/classes/java/security/IdentityScope.java ! src/java.base/share/classes/java/security/InvalidKeyException.java ! src/java.base/share/classes/java/security/InvalidParameterException.java ! src/java.base/share/classes/java/security/Key.java ! src/java.base/share/classes/java/security/KeyException.java ! src/java.base/share/classes/java/security/KeyManagementException.java ! src/java.base/share/classes/java/security/KeyPair.java ! src/java.base/share/classes/java/security/KeyPairGenerator.java ! src/java.base/share/classes/java/security/KeyPairGeneratorSpi.java ! src/java.base/share/classes/java/security/MessageDigest.java ! src/java.base/share/classes/java/security/MessageDigestSpi.java ! src/java.base/share/classes/java/security/NoSuchAlgorithmException.java ! src/java.base/share/classes/java/security/NoSuchProviderException.java ! src/java.base/share/classes/java/security/Permission.java ! src/java.base/share/classes/java/security/PermissionCollection.java ! src/java.base/share/classes/java/security/Permissions.java ! src/java.base/share/classes/java/security/Policy.java ! src/java.base/share/classes/java/security/Principal.java ! src/java.base/share/classes/java/security/PrivateKey.java ! src/java.base/share/classes/java/security/PrivilegedAction.java ! src/java.base/share/classes/java/security/PrivilegedActionException.java ! src/java.base/share/classes/java/security/PrivilegedExceptionAction.java ! src/java.base/share/classes/java/security/ProtectionDomain.java ! src/java.base/share/classes/java/security/Provider.java ! src/java.base/share/classes/java/security/ProviderException.java ! src/java.base/share/classes/java/security/PublicKey.java ! src/java.base/share/classes/java/security/SecureClassLoader.java ! src/java.base/share/classes/java/security/SecureRandom.java ! src/java.base/share/classes/java/security/Security.java ! src/java.base/share/classes/java/security/SecurityPermission.java ! src/java.base/share/classes/java/security/Signature.java ! src/java.base/share/classes/java/security/SignatureException.java ! src/java.base/share/classes/java/security/SignatureSpi.java ! src/java.base/share/classes/java/security/SignedObject.java ! src/java.base/share/classes/java/security/Signer.java ! src/java.base/share/classes/java/security/UnresolvedPermission.java ! src/java.base/share/classes/java/security/UnresolvedPermissionCollection.java ! src/java.base/share/classes/java/security/acl/Acl.java ! src/java.base/share/classes/java/security/acl/AclEntry.java ! src/java.base/share/classes/java/security/acl/AclNotFoundException.java ! src/java.base/share/classes/java/security/acl/Group.java ! src/java.base/share/classes/java/security/acl/LastOwnerException.java ! src/java.base/share/classes/java/security/acl/NotOwnerException.java ! src/java.base/share/classes/java/security/acl/Owner.java ! src/java.base/share/classes/java/security/acl/Permission.java ! src/java.base/share/classes/java/security/cert/CRLException.java ! src/java.base/share/classes/java/security/cert/Certificate.java ! src/java.base/share/classes/java/security/cert/CertificateEncodingException.java ! src/java.base/share/classes/java/security/cert/CertificateException.java ! src/java.base/share/classes/java/security/cert/CertificateExpiredException.java ! src/java.base/share/classes/java/security/cert/CertificateNotYetValidException.java ! src/java.base/share/classes/java/security/cert/CertificateParsingException.java ! src/java.base/share/classes/java/security/cert/X509CRL.java ! src/java.base/share/classes/java/security/cert/X509CRLEntry.java ! src/java.base/share/classes/java/security/cert/X509Certificate.java ! src/java.base/share/classes/java/security/cert/X509Extension.java ! src/java.base/share/classes/java/security/interfaces/DSAKey.java ! src/java.base/share/classes/java/security/interfaces/DSAKeyPairGenerator.java ! src/java.base/share/classes/java/security/interfaces/DSAParams.java ! src/java.base/share/classes/java/security/interfaces/DSAPrivateKey.java ! src/java.base/share/classes/java/security/interfaces/DSAPublicKey.java ! src/java.base/share/classes/java/security/interfaces/RSAPrivateCrtKey.java ! src/java.base/share/classes/java/security/interfaces/RSAPrivateKey.java ! src/java.base/share/classes/java/security/interfaces/RSAPublicKey.java ! src/java.base/share/classes/java/security/spec/RSAPrivateCrtKeySpec.java ! src/java.base/share/classes/java/security/spec/RSAPrivateKeySpec.java ! src/java.base/share/classes/java/security/spec/RSAPublicKeySpec.java ! src/java.base/share/classes/java/text/BreakIterator.java ! src/java.base/share/classes/java/text/CharacterIterator.java ! src/java.base/share/classes/java/text/ChoiceFormat.java ! src/java.base/share/classes/java/text/CollationElementIterator.java ! src/java.base/share/classes/java/text/CollationKey.java ! src/java.base/share/classes/java/text/Collator.java ! src/java.base/share/classes/java/text/DateFormat.java ! src/java.base/share/classes/java/text/DateFormatSymbols.java ! src/java.base/share/classes/java/text/DecimalFormat.java ! src/java.base/share/classes/java/text/DecimalFormatSymbols.java ! src/java.base/share/classes/java/text/FieldPosition.java ! src/java.base/share/classes/java/text/Format.java ! src/java.base/share/classes/java/text/MessageFormat.java ! src/java.base/share/classes/java/text/NumberFormat.java ! src/java.base/share/classes/java/text/ParseException.java ! src/java.base/share/classes/java/text/ParsePosition.java ! src/java.base/share/classes/java/text/RuleBasedCollator.java ! src/java.base/share/classes/java/text/SimpleDateFormat.java ! src/java.base/share/classes/java/text/StringCharacterIterator.java ! src/java.base/share/classes/java/util/concurrent/CompletionService.java ! src/java.base/share/classes/java/util/concurrent/ExecutorCompletionService.java ! src/java.base/share/classes/java/util/concurrent/locks/LockSupport.java ! src/java.base/share/classes/java/util/jar/JarEntry.java ! src/java.base/share/classes/java/util/zip/Adler32.java ! src/java.base/share/classes/java/util/zip/CRC32.java ! src/java.base/share/classes/java/util/zip/CheckedInputStream.java ! src/java.base/share/classes/java/util/zip/CheckedOutputStream.java ! src/java.base/share/classes/java/util/zip/Checksum.java ! src/java.base/share/classes/java/util/zip/DataFormatException.java ! src/java.base/share/classes/java/util/zip/Deflater.java ! src/java.base/share/classes/java/util/zip/DeflaterOutputStream.java ! src/java.base/share/classes/java/util/zip/GZIPInputStream.java ! src/java.base/share/classes/java/util/zip/GZIPOutputStream.java ! src/java.base/share/classes/java/util/zip/Inflater.java ! src/java.base/share/classes/java/util/zip/InflaterInputStream.java ! src/java.base/share/classes/java/util/zip/ZipConstants.java ! src/java.base/share/classes/java/util/zip/ZipEntry.java ! src/java.base/share/classes/java/util/zip/ZipFile.java ! src/java.base/share/classes/java/util/zip/ZipInputStream.java ! src/java.base/share/classes/java/util/zip/ZipOutputStream.java ! src/java.base/share/classes/javax/security/auth/AuthPermission.java ! src/java.base/share/classes/javax/security/auth/DestroyFailedException.java ! src/java.base/share/classes/javax/security/auth/Destroyable.java ! src/java.base/share/classes/javax/security/auth/Policy.java ! src/java.base/share/classes/javax/security/auth/PrivateCredentialPermission.java ! src/java.base/share/classes/javax/security/auth/RefreshFailedException.java ! src/java.base/share/classes/javax/security/auth/Refreshable.java ! src/java.base/share/classes/javax/security/auth/Subject.java ! src/java.base/share/classes/javax/security/auth/SubjectDomainCombiner.java ! src/java.base/share/classes/javax/security/auth/callback/Callback.java ! src/java.base/share/classes/javax/security/auth/callback/CallbackHandler.java ! src/java.base/share/classes/javax/security/auth/callback/ChoiceCallback.java ! src/java.base/share/classes/javax/security/auth/callback/ConfirmationCallback.java ! src/java.base/share/classes/javax/security/auth/callback/LanguageCallback.java ! src/java.base/share/classes/javax/security/auth/callback/NameCallback.java ! src/java.base/share/classes/javax/security/auth/callback/PasswordCallback.java ! src/java.base/share/classes/javax/security/auth/callback/TextInputCallback.java ! src/java.base/share/classes/javax/security/auth/callback/TextOutputCallback.java ! src/java.base/share/classes/javax/security/auth/callback/UnsupportedCallbackException.java ! src/java.base/share/classes/javax/security/auth/login/AccountExpiredException.java ! src/java.base/share/classes/javax/security/auth/login/AppConfigurationEntry.java ! src/java.base/share/classes/javax/security/auth/login/Configuration.java ! src/java.base/share/classes/javax/security/auth/login/CredentialExpiredException.java ! src/java.base/share/classes/javax/security/auth/login/FailedLoginException.java ! src/java.base/share/classes/javax/security/auth/login/LoginContext.java ! src/java.base/share/classes/javax/security/auth/login/LoginException.java ! src/java.base/share/classes/javax/security/auth/spi/LoginModule.java ! src/java.base/share/classes/javax/security/auth/x500/X500PrivateCredential.java ! src/java.datatransfer/share/classes/java/awt/datatransfer/Clipboard.java ! src/java.datatransfer/share/classes/java/awt/datatransfer/ClipboardOwner.java ! src/java.datatransfer/share/classes/java/awt/datatransfer/DataFlavor.java ! src/java.datatransfer/share/classes/java/awt/datatransfer/StringSelection.java ! src/java.datatransfer/share/classes/java/awt/datatransfer/Transferable.java ! src/java.datatransfer/share/classes/java/awt/datatransfer/UnsupportedFlavorException.java Changeset: 6435d673ea25 Author: valeriep Date: 2017-06-01 03:26 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6435d673ea25 8180635: (doc) Clarify the compatibility and interoperability issue when using provider default values Summary: updated the javadoc of KeyPairGenerator, KeyGenerator, AlgorithmParameterGenerator and their Spi classes Reviewed-by: mullan ! src/java.base/share/classes/java/security/AlgorithmParameterGenerator.java ! src/java.base/share/classes/java/security/AlgorithmParameterGeneratorSpi.java ! src/java.base/share/classes/java/security/KeyPairGenerator.java ! src/java.base/share/classes/java/security/KeyPairGeneratorSpi.java ! src/java.base/share/classes/javax/crypto/KeyGenerator.java ! src/java.base/share/classes/javax/crypto/KeyGeneratorSpi.java Changeset: 1f820f4aff3e Author: rriggs Date: 2017-05-31 23:45 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1f820f4aff3e 8180582: The bind to rmiregistry is rejected by registryFilter even though registryFilter is set Summary: The Registry MAXDEPTH should allow binding more complex objects Reviewed-by: dfuchs, smarks ! src/java.rmi/share/classes/sun/rmi/registry/RegistryImpl.java ! test/java/rmi/registry/serialFilter/RegistryFilterTest.java Changeset: a24583f5e4bf Author: rriggs Date: 2017-06-01 09:28 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a24583f5e4bf 8181156: html5 issues in java.base javadoc Reviewed-by: alanb ! src/java.base/share/classes/java/lang/invoke/package-info.java ! src/java.base/share/classes/java/net/InetAddress.java ! src/java.base/share/classes/java/net/URI.java ! src/java.base/share/classes/java/nio/channels/package-info.java ! src/java.base/share/classes/java/nio/charset/package-info.java ! src/java.base/share/classes/java/nio/file/attribute/package-info.java ! src/java.base/share/classes/java/nio/package-info.java ! src/java.base/share/classes/java/util/spi/CalendarNameProvider.java Changeset: 3a73b3d5318e Author: lana Date: 2017-06-01 18:48 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3a73b3d5318e Merge Changeset: fb80de0ea690 Author: naoto Date: 2017-06-01 14:52 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fb80de0ea690 8180375: Rename Provider to .spi.Provider Reviewed-by: mchung ! src/java.base/share/classes/java/util/ResourceBundle.java ! src/java.base/share/classes/java/util/spi/ResourceBundleProvider.java ! test/java/util/ResourceBundle/modules/appbasic/src/asiabundles/jdk/test/resources/asia/MyResourcesAsia.java ! test/java/util/ResourceBundle/modules/appbasic/src/asiabundles/module-info.java ! test/java/util/ResourceBundle/modules/appbasic/src/eubundles/jdk/test/resources/eu/MyResourcesEU.java ! test/java/util/ResourceBundle/modules/appbasic/src/eubundles/module-info.java - test/java/util/ResourceBundle/modules/appbasic/src/test/jdk/test/resources/MyResourcesProvider.java ! test/java/util/ResourceBundle/modules/appbasic/src/test/jdk/test/resources/MyResourcesProviderImpl.java + test/java/util/ResourceBundle/modules/appbasic/src/test/jdk/test/resources/spi/MyResourcesProvider.java ! test/java/util/ResourceBundle/modules/appbasic/src/test/module-info.java ! test/java/util/ResourceBundle/modules/appbasic2/src/asiabundles/jdk/test/resources/asia/MyResourcesAsia.java ! test/java/util/ResourceBundle/modules/appbasic2/src/asiabundles/module-info.java ! test/java/util/ResourceBundle/modules/appbasic2/src/eubundles/jdk/test/resources/eu/MyResourcesEU.java ! test/java/util/ResourceBundle/modules/appbasic2/src/eubundles/module-info.java - test/java/util/ResourceBundle/modules/appbasic2/src/test/jdk/test/resources/MyResourcesProvider.java ! test/java/util/ResourceBundle/modules/appbasic2/src/test/jdk/test/resources/MyResourcesProviderImpl.java + test/java/util/ResourceBundle/modules/appbasic2/src/test/jdk/test/resources/spi/MyResourcesProvider.java ! test/java/util/ResourceBundle/modules/appbasic2/src/test/module-info.java ! test/java/util/ResourceBundle/modules/basic/src/asiabundles/jdk/test/resources/asia/MyResourcesAsia.java ! test/java/util/ResourceBundle/modules/basic/src/asiabundles/module-info.java ! test/java/util/ResourceBundle/modules/basic/src/eubundles/jdk/test/resources/eu/MyResourcesEU.java ! test/java/util/ResourceBundle/modules/basic/src/eubundles/module-info.java ! test/java/util/ResourceBundle/modules/basic/src/mainbundles/jdk/test/resources/MyResourcesMain.java - test/java/util/ResourceBundle/modules/basic/src/mainbundles/jdk/test/resources/MyResourcesProvider.java + test/java/util/ResourceBundle/modules/basic/src/mainbundles/jdk/test/resources/spi/MyResourcesProvider.java ! test/java/util/ResourceBundle/modules/basic/src/mainbundles/module-info.java ! test/java/util/ResourceBundle/modules/basic/src/test/module-info.java + test/java/util/ResourceBundle/modules/layer/run.sh + test/java/util/ResourceBundle/modules/layer/src/Main.java + test/java/util/ResourceBundle/modules/layer/src/m1/module-info.java + test/java/util/ResourceBundle/modules/layer/src/m1/p/Main.java + test/java/util/ResourceBundle/modules/layer/src/m1/p/internal/BundleProvider.java + test/java/util/ResourceBundle/modules/layer/src/m1/p/resources/MyResource.properties + test/java/util/ResourceBundle/modules/layer/src/m1/p/resources/spi/MyResourceProvider.java + test/java/util/ResourceBundle/modules/layer/src/m2/module-info.java + test/java/util/ResourceBundle/modules/layer/src/m2/p/internal/BundleProvider.java + test/java/util/ResourceBundle/modules/layer/src/m2/p/resources/MyResource_ja.properties - test/java/util/ResourceBundle/modules/simple/src/bundles/jdk/test/resources/MyResourcesProvider.java + test/java/util/ResourceBundle/modules/simple/src/bundles/jdk/test/resources/spi/MyResourcesProvider.java ! test/java/util/ResourceBundle/modules/simple/src/bundles/module-info.java ! test/java/util/ResourceBundle/modules/simple/src/test/module-info.java - test/java/util/ResourceBundle/modules/visibility/src/exported.named.bundles/jdk/test/resources/exported/classes/MyResourcesProvider.java + test/java/util/ResourceBundle/modules/visibility/src/exported.named.bundles/jdk/test/resources/exported/classes/spi/MyResourcesProvider.java ! test/java/util/ResourceBundle/modules/visibility/src/exported.named.bundles/module-info.java - test/java/util/ResourceBundle/modules/visibility/src/named.bundles/jdk/test/resources/classes/MyResourcesProvider.java + test/java/util/ResourceBundle/modules/visibility/src/named.bundles/jdk/test/resources/classes/spi/MyResourcesProvider.java - test/java/util/ResourceBundle/modules/visibility/src/named.bundles/jdk/test/resources/props/MyResourcesProvider.java + test/java/util/ResourceBundle/modules/visibility/src/named.bundles/jdk/test/resources/props/spi/MyResourcesProvider.java ! test/java/util/ResourceBundle/modules/visibility/src/named.bundles/module-info.java ! test/java/util/ResourceBundle/modules/visibility/src/test/module-info.java - test/java/util/ResourceBundle/modules/xmlformat/src/bundles/jdk/test/resources/MyResourcesProvider.java + test/java/util/ResourceBundle/modules/xmlformat/src/bundles/jdk/test/resources/spi/MyResourcesProvider.java ! test/java/util/ResourceBundle/modules/xmlformat/src/bundles/module-info.java ! test/java/util/ResourceBundle/modules/xmlformat/src/test/module-info.java Changeset: a5506b425f1b Author: prappo Date: 2017-06-02 18:32 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a5506b425f1b 8180155: WebSocket secure connection get stuck after onOpen 8156518: WebSocket.Builder.connectTimeout(long timeout, TimeUnit unit) implicitly affect websocket connection timeout Reviewed-by: dfuchs ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/MultiExchange.java ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/SSLDelegate.java ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/internal/websocket/Receiver.java Changeset: 23721aa1d87f Author: lana Date: 2017-06-08 16:32 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/23721aa1d87f Added tag jdk-9+173 for changeset a5506b425f1b ! .hgtags Changeset: ca27e19449ff Author: alanb Date: 2017-06-08 18:49 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ca27e19449ff Merge ! .hgtags ! src/java.base/share/classes/java/lang/RuntimePermission.java ! src/java.base/share/classes/java/lang/module/package-info.java ! src/java.base/share/classes/java/lang/reflect/Constructor.java ! src/java.base/share/classes/java/lang/reflect/Field.java ! src/java.base/share/classes/java/lang/reflect/Method.java ! src/java.base/share/classes/java/security/Provider.java ! src/java.base/share/classes/java/security/SecureClassLoader.java ! src/java.base/share/classes/java/security/UnresolvedPermission.java ! src/java.base/share/classes/java/util/ResourceBundle.java ! src/java.base/share/classes/java/util/spi/ResourceBundleProvider.java ! src/java.base/share/classes/javax/security/auth/login/LoginContext.java - test/java/util/ResourceBundle/modules/appbasic/src/test/jdk/test/resources/MyResourcesProvider.java ! test/java/util/ResourceBundle/modules/appbasic2/src/asiabundles/jdk/test/resources/asia/MyResourcesAsia.java ! test/java/util/ResourceBundle/modules/appbasic2/src/eubundles/jdk/test/resources/eu/MyResourcesEU.java - test/java/util/ResourceBundle/modules/appbasic2/src/test/jdk/test/resources/MyResourcesProvider.java ! test/java/util/ResourceBundle/modules/appbasic2/src/test/jdk/test/resources/MyResourcesProviderImpl.java + test/java/util/ResourceBundle/modules/appbasic2/src/test/jdk/test/resources/spi/MyResourcesProvider.java ! test/java/util/ResourceBundle/modules/basic/src/asiabundles/jdk/test/resources/asia/MyResourcesAsia.java ! test/java/util/ResourceBundle/modules/basic/src/eubundles/jdk/test/resources/eu/MyResourcesEU.java ! test/java/util/ResourceBundle/modules/basic/src/mainbundles/jdk/test/resources/MyResourcesMain.java - test/java/util/ResourceBundle/modules/basic/src/mainbundles/jdk/test/resources/MyResourcesProvider.java + test/java/util/ResourceBundle/modules/basic/src/mainbundles/jdk/test/resources/spi/MyResourcesProvider.java ! test/java/util/ResourceBundle/modules/basic/src/mainbundles/module-info.java - test/java/util/ResourceBundle/modules/simple/src/bundles/jdk/test/resources/MyResourcesProvider.java + test/java/util/ResourceBundle/modules/simple/src/bundles/jdk/test/resources/spi/MyResourcesProvider.java - test/java/util/ResourceBundle/modules/visibility/src/exported.named.bundles/jdk/test/resources/exported/classes/MyResourcesProvider.java ! test/java/util/ResourceBundle/modules/visibility/src/exported.named.bundles/module-info.java - test/java/util/ResourceBundle/modules/visibility/src/named.bundles/jdk/test/resources/classes/MyResourcesProvider.java - test/java/util/ResourceBundle/modules/visibility/src/named.bundles/jdk/test/resources/props/MyResourcesProvider.java - test/java/util/ResourceBundle/modules/xmlformat/src/bundles/jdk/test/resources/MyResourcesProvider.java Changeset: 6d3426ece6e8 Author: alanb Date: 2017-06-08 18:45 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6d3426ece6e8 Further cleanup/improvements to illegal access handling ! src/java.base/share/classes/java/lang/Module.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/jdk/internal/misc/JavaLangAccess.java ! src/java.base/share/classes/jdk/internal/module/IllegalAccessLogger.java ! src/java.base/share/classes/sun/launcher/LauncherHelper.java Changeset: 4cf794c9276b Author: alanb Date: 2017-06-08 18:50 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4cf794c9276b Merge From alan.bateman at oracle.com Thu Jun 8 18:50:58 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 08 Jun 2017 18:50:58 +0000 Subject: hg: jigsaw/jake/corba: 5 new changesets Message-ID: <201706081850.v58IowBX024274@aojmv0008.oracle.com> Changeset: d5fd6bd57a56 Author: jjg Date: 2017-05-30 15:49 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/d5fd6bd57a56 8181290: Invalid HTML 5 in core-libs docs Reviewed-by: mchung, lancea ! src/java.corba/share/classes/org/omg/CORBA/doc-files/generatedfiles.html Changeset: bd32b2b28de5 Author: msheppar Date: 2017-06-01 17:49 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/bd32b2b28de5 8176784: Amend HREF to technote/guides in CORBA API docs to unilinks for guides Reviewed-by: chegar, rriggs ! src/java.corba/share/classes/javax/rmi/PortableRemoteObject.java ! src/java.corba/share/classes/org/omg/CORBA/ACTIVITY_COMPLETED.java ! src/java.corba/share/classes/org/omg/CORBA/ACTIVITY_REQUIRED.java ! src/java.corba/share/classes/org/omg/CORBA/BAD_CONTEXT.java ! src/java.corba/share/classes/org/omg/CORBA/BAD_INV_ORDER.java ! src/java.corba/share/classes/org/omg/CORBA/BAD_OPERATION.java ! src/java.corba/share/classes/org/omg/CORBA/BAD_PARAM.java ! src/java.corba/share/classes/org/omg/CORBA/BAD_QOS.java ! src/java.corba/share/classes/org/omg/CORBA/BAD_TYPECODE.java ! src/java.corba/share/classes/org/omg/CORBA/Bounds.java ! src/java.corba/share/classes/org/omg/CORBA/CODESET_INCOMPATIBLE.java ! src/java.corba/share/classes/org/omg/CORBA/COMM_FAILURE.java ! src/java.corba/share/classes/org/omg/CORBA/DATA_CONVERSION.java ! src/java.corba/share/classes/org/omg/CORBA/FREE_MEM.java ! src/java.corba/share/classes/org/omg/CORBA/IMP_LIMIT.java ! src/java.corba/share/classes/org/omg/CORBA/INITIALIZE.java ! src/java.corba/share/classes/org/omg/CORBA/INTERNAL.java ! src/java.corba/share/classes/org/omg/CORBA/INTF_REPOS.java ! src/java.corba/share/classes/org/omg/CORBA/INVALID_ACTIVITY.java ! src/java.corba/share/classes/org/omg/CORBA/INVALID_TRANSACTION.java ! src/java.corba/share/classes/org/omg/CORBA/INV_FLAG.java ! src/java.corba/share/classes/org/omg/CORBA/INV_IDENT.java ! src/java.corba/share/classes/org/omg/CORBA/INV_OBJREF.java ! src/java.corba/share/classes/org/omg/CORBA/INV_POLICY.java ! src/java.corba/share/classes/org/omg/CORBA/MARSHAL.java ! src/java.corba/share/classes/org/omg/CORBA/NO_IMPLEMENT.java ! src/java.corba/share/classes/org/omg/CORBA/NO_MEMORY.java ! src/java.corba/share/classes/org/omg/CORBA/NO_PERMISSION.java ! src/java.corba/share/classes/org/omg/CORBA/NO_RESOURCES.java ! src/java.corba/share/classes/org/omg/CORBA/NO_RESPONSE.java ! src/java.corba/share/classes/org/omg/CORBA/OBJECT_NOT_EXIST.java ! src/java.corba/share/classes/org/omg/CORBA/OBJ_ADAPTER.java ! src/java.corba/share/classes/org/omg/CORBA/ORB.java ! src/java.corba/share/classes/org/omg/CORBA/PERSIST_STORE.java ! src/java.corba/share/classes/org/omg/CORBA/REBIND.java ! src/java.corba/share/classes/org/omg/CORBA/SystemException.java ! src/java.corba/share/classes/org/omg/CORBA/TIMEOUT.java ! src/java.corba/share/classes/org/omg/CORBA/TRANSACTION_MODE.java ! src/java.corba/share/classes/org/omg/CORBA/TRANSACTION_REQUIRED.java ! src/java.corba/share/classes/org/omg/CORBA/TRANSACTION_ROLLEDBACK.java ! src/java.corba/share/classes/org/omg/CORBA/TRANSACTION_UNAVAILABLE.java ! src/java.corba/share/classes/org/omg/CORBA/TRANSIENT.java ! src/java.corba/share/classes/org/omg/CORBA/UNKNOWN.java ! src/java.corba/share/classes/org/omg/CORBA/UnknownUserException.java ! src/java.corba/share/classes/org/omg/CORBA/UserException.java ! src/java.corba/share/classes/org/omg/CORBA/WrongTransaction.java ! src/java.corba/share/classes/org/omg/CORBA/package.html ! src/java.corba/share/classes/org/omg/CosNaming/package.html ! src/java.corba/share/classes/org/omg/PortableServer/package.html Changeset: 534ba4f8cfcf Author: lana Date: 2017-06-01 18:48 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/534ba4f8cfcf Merge Changeset: 3615768c1290 Author: lana Date: 2017-06-08 16:32 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/3615768c1290 Added tag jdk-9+173 for changeset 534ba4f8cfcf ! .hgtags Changeset: f8d62fabd7d4 Author: alanb Date: 2017-06-08 18:38 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/f8d62fabd7d4 Merge ! .hgtags ! src/java.corba/share/classes/javax/rmi/PortableRemoteObject.java ! src/java.corba/share/classes/org/omg/CORBA/ORB.java From alan.bateman at oracle.com Fri Jun 9 07:20:38 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 09 Jun 2017 07:20:38 +0000 Subject: hg: jigsaw/jake/jdk: Update JCP technology summary page Message-ID: <201706090720.v597Kd1L008835@aojmv0008.oracle.com> Changeset: ba87fa8f1282 Author: alanb Date: 2017-06-09 08:18 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ba87fa8f1282 Update JCP technology summary page Contributed-by: alex.buckley at oracle.com ! make/src/classes/build/tools/jigsaw/technology-summary.html From alan.bateman at oracle.com Fri Jun 9 13:10:52 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 09 Jun 2017 13:10:52 +0000 Subject: hg: jigsaw/jake/jdk: Add additional tests to exercise addExports/addOpens with --illegal-access Message-ID: <201706091310.v59DAqxl009337@aojmv0008.oracle.com> Changeset: 5a5c798c2ef9 Author: alanb Date: 2017-06-09 14:08 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5a5c798c2ef9 Add additional tests to exercise addExports/addOpens with --illegal-access ! test/tools/launcher/modules/illegalaccess/IllegalAccessTest.java ! test/tools/launcher/modules/illegalaccess/TryAccess.java + test/tools/launcher/modules/illegalaccess/modules/m/module-info.java + test/tools/launcher/modules/illegalaccess/modules/m/p/Type.java + test/tools/launcher/modules/illegalaccess/patchsrc/java.base/java/lang/Helper.java - test/tools/launcher/modules/illegalaccess/src/m/module-info.java - test/tools/launcher/modules/illegalaccess/src/m/p/Type.java From alan.bateman at oracle.com Fri Jun 9 14:44:00 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 09 Jun 2017 14:44:00 +0000 Subject: hg: jigsaw/jake/jdk: More ServiceLoader tests Message-ID: <201706091444.v59Ei002012545@aojmv0008.oracle.com> Changeset: 208848417e5e Author: alanb Date: 2017-06-09 15:42 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/208848417e5e More ServiceLoader tests ! test/java/util/ServiceLoader/ModulesTest.java From todd.west at gmail.com Fri Jun 9 15:01:03 2017 From: todd.west at gmail.com (Todd West) Date: Fri, 9 Jun 2017 08:01:03 -0700 Subject: Fwd: Using java.sql.Time in an Agent? In-Reply-To: References: Message-ID: I am currently running into an issue where a usage of java.sql.Time in an Agent prevents the agent from starting correctly when running on JDK 9. Here is the example I am testing with: https://github.com/AdoptOpenJDK/jdk9-jigsaw/tree/ master/session-1-jigsaw-intro/01_Greetings I modified the run.sh to look like the following: java -javaagent:/path/to/my/agent.jar \ --module-path mods \ --module com.greetings/com.greetings.Main However, the JVM fails to start up due to simply trying to parse some JSON: java.lang.NoClassDefFoundError: java/sql/Time at com.google.gson.Gson.(Gson.java:232) at com.google.gson.GsonBuilder.create(GsonBuilder.java:545) ... The usage of "java.sql.Time" in Gson is preventing the application from starting because it does not use "requires java.sql" and the agent is unable to specify this required dependency. I can work around the issue by using "--add-modules=java.sql" but this is pretty clunky to require users to have to specify yet another command line option. I could remove the Gson dependency to work around the issue but I have a feeling that a similar issue would likely crop up in the future. Are there any documented ways of either: 1. Allowing an agent to specify dependencies that it needs while still maintaining backward compatibility with at least Java 8 2. Giving an agent access to any required modules/packages in a programmatic way, considering that an agent is part of the unnamed module and may require access to JDK modules Any help or direction here would be greatly appreciated. Thank you! From Alan.Bateman at oracle.com Fri Jun 9 15:57:42 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 9 Jun 2017 16:57:42 +0100 Subject: Fwd: Using java.sql.Time in an Agent? In-Reply-To: References: Message-ID: <538ec9e9-2d24-96ab-c985-dbf0577f6b7a@oracle.com> On 09/06/2017 16:01, Todd West wrote: > I am currently running into an issue where a usage of java.sql.Time in an > Agent prevents the agent from starting correctly when running on JDK 9. > Here is the example I am testing with: > > https://github.com/AdoptOpenJDK/jdk9-jigsaw/tree/ > master/session-1-jigsaw-intro/01_Greetings > > I modified the run.sh to look like the following: > > java -javaagent:/path/to/my/agent.jar \ > --module-path mods \ > --module com.greetings/com.greetings.Main > > However, the JVM fails to start up due to simply trying to parse some JSON: > > java.lang.NoClassDefFoundError: java/sql/Time > at com.google.gson.Gson.(Gson.java:232) > at com.google.gson.GsonBuilder.create(GsonBuilder.java:545) > ... The "Visibility" section of the java.lang.instrument spec explains this: "The types visible to the agent class are the types visible to the system class loader. They minimally include the types in packages exported by java.base and java.instrument. Whether all platform classes are visible or not will depend on the initial module or application." The initial module in the example is "com.greetings" and so the modules are that are resolved at startup are the modules that it recursively enumerates (along with any service provider modules), plus "java.instrument" because `-javaagent` is specified. There isn't any support at this time to develop or deploy java agents as modules. It has been prototyped and most of the issues are interactions are understood, it's just too much to take on for Java SE 9. Using `--add-modules java.sql` is the workaround. The alternative is to trim down the dependences so that the agent only needs java.base and java.instrument. This would allow the agent to be used in small run-time images that don't have java.sql too. -Alan From nipa at codefx.org Sun Jun 11 06:44:21 2017 From: nipa at codefx.org (Nicolai Parlog) Date: Sun, 11 Jun 2017 08:44:21 +0200 Subject: module-info hygiene In-Reply-To: <580667E8.9030607@oracle.com> References: <29fbf424-e90a-7d04-0046-7e15d3fc0c35@gmail.com> <580667E8.9030607@oracle.com> Message-ID: <5be43859-0776-b9da-4edb-d95344edf892@codefx.org> Hi! As far as I can tell, no linter option for unused requires clauses was introduced. I think it would be very helpful - is it still being considered? so long ... Nicolai On 18.10.2016 20:20, Ioi Lam wrote: > > > On 10/17/16 12:43 PM, Robert Scholte wrote: >> On Mon, 17 Oct 2016 12:59:25 +0200, Alan Bateman >> wrote: >> >>> On 17/10/2016 08:32, Peter Levart wrote: >>> >>>> : >>>> >>>> Do we need an --exclude-modules (in addition to >>>> --add-modules) option on javac, java and jlink commands? >>>> >>>> --exclude-modules would be different to --limit-modules. If >>>> some module requires module M and there is no module M on the >>>> module path or it is not observable because it was not >>>> mentioned in the --limit-modules option, then an exception is >>>> raised. OTOH if some module X requires module M and module M >>>> is mentioned in the --exclude-modules option, then such >>>> requires is silently ignored in hope that module X will not >>>> actually need types from module M. >>> The module declaration is intended to be authoritative and so >>> we have to trust module author when they declare that the >>> module `requires M`. So my view is that options such as >>> --exclude-modules that would have the effect of dropping >>> requires puts us on the road to anarchy. >>> >>> That said, I do see Robert's concern that there might be >>> orphaned `requires` clauses in some modules. My module started >>> using the preferences API but later the implementation changed >>> to use something else. I neglected to remove the `requires >>> java.prefs` from the module declaration and the result is that >>> my module cannot compile against or run on a run-time image >>> that doesn't include this module. Static analysis tools might >>> help here, as might the IDE. We are used to IDEs highlighting >>> unused `import` statements and in time then I expect they will >>> do the same for apparently unused `requires` clauses in >>> module-info.java. If the usage is purely reflective then the >>> module author might need to put a comment on the `requires` >>> clause to avoid other maintainers from removing it (a bit like >>> "// used by javadoc" in comments today when an import is for an >>> unqualified reference in the javadoc). >>> >>> Another part to Robert's mail is the case where something is >>> making use of types in modules that it doesn't depend on. >>> Assuming these are static references then they will be caught >>> at compile-time. This is big improvement compared to today's >>> class path. >>> >>> A more general comment is that module authors will need to >>> learn a few new things about compatibility and refactoring. One >>> example is changing `requires transitive M` to `requires M` is >>> an incompatible change. Another is splitting a module (several >>> sub-cases) where the module author will need to add `requires >>> transitive` to avoid breaking consumers. There are lots of >>> opportunities here for authoritative books and documentation to >>> help module authors do this right. >>> >>> -Alan >>> >>> >> >> I understand why *in concept* the --exclude-modules is an >> unwanted option. The module-info clearly states "requires A.B", >> otherwise it should have been marked as "optional" or simply >> removed. Now that the user fully relies on the discipline of the >> library-builders: users cannot control the modules, nor will the >> compilation fail in case of an incorrect module-info. It is >> really a matter of hoping that library-builders are aware of this >> and maybe it will make libraries more popular based on the >> quality of the module-info instead of the quality of the classes. >> As a user you probably don't want to be forced to choose on these >> facts. And for the smaller and medium application this will work, >> but for the larger this can really become problematic. >> >> Up until now the compiler was always about "is everything on the >> classpath to compile the classes?". If there is more, we'll, >> it'll be ignored. "More" was never a problem. And if it was a >> problem, the user could fix it. >> >> Now we have the module-info, and it is actually a safety-belt for >> the library-builder! Now he can never be blamed (almost): the >> module-info contains at least all info to compile and run this >> library, maybe even more for free. But with a lot of libraries >> with their own safety-belts there can be (and will be) conflicts >> and there's nothing you can do right now (apart from dropping all >> safety-belts). For the end-user all these small safety-belts >> doesn't feel very "safe". He would feel much better if he had >> some of the control back (and yes, he's very well aware of the >> possible consequences). >> >> The introduction of the module-info comes with great powers, but >> that comes with great responsibilities as well. I would like to >> see that the compiler could help with controlling those required >> modules (which would mean that "More" is considered to be a >> problem). Static analysis is IMHO just a hint, ignorable, but to >> me it shouldn't be that way. >> > > Maybe a "javac -Xlint:unusedmodules" can give warnings that > hopefully most library developers will notice? > > Or, for some reason if the library uses module X only via > reflection, perhaps there can be a way to turn off the warning for > just module X? > > Another option is to have a static analysis tool (similar to jdep) > that can print out all the dependencies and give various > warnings/suggestions regarding minimizing the "requires" clauses? > -- PGP Key: http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509 Web: http://codefx.org a blog about software development https://www.sitepoint.com/java high-quality Java/JVM content http://do-foss.de Free and Open Source Software for the City of Dortmund Twitter: https://twitter.com/nipafx From nipa at codefx.org Sun Jun 11 07:13:58 2017 From: nipa at codefx.org (Nicolai Parlog) Date: Sun, 11 Jun 2017 09:13:58 +0200 Subject: Why is -XD-Xmodule hidden? Message-ID: Hi! When incrementally compiling some of a module's sources it is necessary to make the compiler aware that the sources actually belong to that module. One way to do this was the non-standard option -Xmodule, which was recently demoted to the hidden -XD-Xmodule. I'm curious to know why. Example: javac --module-path mods -d classes src/foo.mod/com.example.SomeClass.java This will compile SomeClass in the unnamed module, making it fail if it uses types from bar.mod (even if foo.mod requires it). I know of three ways to fix this: * adding module declaration to compile command * multi-module declaration * option -XD-Xmodule I found the last option to be conceptually most fitting and also the least troublesome. so long ... Nicolai -- PGP Key: http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509 Web: http://codefx.org a blog about software development https://www.sitepoint.com/java high-quality Java/JVM content http://do-foss.de Free and Open Source Software for the City of Dortmund Twitter: https://twitter.com/nipafx From Alan.Bateman at oracle.com Sun Jun 11 07:35:44 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 11 Jun 2017 08:35:44 +0100 Subject: Why is -XD-Xmodule hidden? In-Reply-To: References: Message-ID: On 11/06/2017 08:13, Nicolai Parlog wrote: > Hi! > > When incrementally compiling some of a module's sources it is necessary > to make the compiler aware that the sources actually belong to that > module. One way to do this was the non-standard option -Xmodule, which > was recently demoted to the hidden -XD-Xmodule. > > I'm curious to know why. > > Example: > > javac --module-path mods -d classes > src/foo.mod/com.example.SomeClass.java > > This will compile SomeClass in the unnamed module, making it fail if it > uses types from bar.mod (even if foo.mod requires it). > > I know of three ways to fix this: > > * adding module declaration to compile command > * multi-module declaration > * option -XD-Xmodule > > I found the last option to be conceptually most fitting and also the > least troublesome. > -Xmodule was folded into --patch-module some time ago. Just add `--patch-module foo.mod=src/foo.jmod` to the above. I'll have to defer to Jon or Jan as to why -Xmodule wasn't removed. As I recall, it was made hidden to allow for transition but I thought that was temporary. -Alan From nipa at codefx.org Sun Jun 11 07:57:44 2017 From: nipa at codefx.org (Nicolai Parlog) Date: Sun, 11 Jun 2017 09:57:44 +0200 Subject: Why is -XD-Xmodule hidden? In-Reply-To: References: Message-ID: <6a5550a0-1795-ffd9-8c97-b53bce6414f4@codefx.org> Hi Alan, thanks for the quick reply. Unfortunately I could not get it to work with --patch-module (I tried before finding -XD-Xmodule). Maybe I'm doing something wrong? I'm using a JPMS demo project I developed[1]. I get the expected compilation errors when doing this: javac --module-path mods -d classes \ monitor.rest/src/main/java/monitor/rest/MonitorServer.java It works with -XD-Xmodule: javac --module-path mods -d classes \ XD-Xmodule monitor.rest monitor.rest/src/main/java/monitor/rest/MonitorServer.java With --patch-module I get the same errors as without: javac --module-path mods -d classes \ --patch-module monitor.rest=mods/monitor.rest.jar \ monitor.rest/src/main/java/monitor/rest/MonitorServer.java Also, it looks like the option is not even really processed. If using a non-existent module name or JAR or even if I add some additional equal signs, I get no particular error for that. I'm on ea-172-Jigsaw. so long ... Nicolai [1] https://github.com/CodeFX-org/demo-jpms-monitor ; it can be built with the contained compile.sh or multi-compile.sh (maybe after removing the 9's from the commands) On 11.06.2017 09:35, Alan Bateman wrote: > On 11/06/2017 08:13, Nicolai Parlog wrote: >> Hi! >> >> When incrementally compiling some of a module's sources it is >> necessary to make the compiler aware that the sources actually >> belong to that module. One way to do this was the non-standard >> option -Xmodule, which was recently demoted to the hidden >> -XD-Xmodule. >> >> I'm curious to know why. >> >> Example: >> >> javac --module-path mods -d classes >> src/foo.mod/com.example.SomeClass.java >> >> This will compile SomeClass in the unnamed module, making it fail >> if it uses types from bar.mod (even if foo.mod requires it). >> >> I know of three ways to fix this: >> >> * adding module declaration to compile command * multi-module >> declaration * option -XD-Xmodule >> >> I found the last option to be conceptually most fitting and also >> the least troublesome. >> > -Xmodule was folded into --patch-module some time ago. Just add > `--patch-module foo.mod=src/foo.jmod` to the above. > > I'll have to defer to Jon or Jan as to why -Xmodule wasn't removed. > As I recall, it was made hidden to allow for transition but I > thought that was temporary. > > -Alan > -- PGP Key: http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509 Web: http://codefx.org a blog about software development https://www.sitepoint.com/java high-quality Java/JVM content http://do-foss.de Free and Open Source Software for the City of Dortmund Twitter: https://twitter.com/nipafx From Alan.Bateman at oracle.com Sun Jun 11 09:52:38 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 11 Jun 2017 10:52:38 +0100 Subject: Why is -XD-Xmodule hidden? In-Reply-To: <6a5550a0-1795-ffd9-8c97-b53bce6414f4@codefx.org> References: <6a5550a0-1795-ffd9-8c97-b53bce6414f4@codefx.org> Message-ID: On 11/06/2017 08:57, Nicolai Parlog wrote: > : > > With --patch-module I get the same errors as without: > > javac --module-path mods -d classes \ > --patch-module monitor.rest=mods/monitor.rest.jar \ > monitor.rest/src/main/java/monitor/rest/MonitorServer.java I agree the documentation needs improvement. JEP 261 needs a big update and one of the items that needs to be properly describes is `javac --patch-module`. The main thing to understand with `javac --patch-module` is that you can specify the source location (it's more powerful than the --patch-module support as run-time). In this example then I would expect this should work: javac --modulepath mods -d classes \ --patch-module monitor.rest=monitor/src \ monitor.rest/src/main/java/monitor/rest/MonitorServer.java The already compiled monitor.rest will be found on the module path. -Alan. From jonathan.gibbons at oracle.com Sun Jun 11 15:26:57 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Sun, 11 Jun 2017 08:26:57 -0700 Subject: Why is -XD-Xmodule hidden? In-Reply-To: References: Message-ID: On 6/11/17 12:35 AM, Alan Bateman wrote: > On 11/06/2017 08:13, Nicolai Parlog wrote: >> Hi! >> >> When incrementally compiling some of a module's sources it is necessary >> to make the compiler aware that the sources actually belong to that >> module. One way to do this was the non-standard option -Xmodule, which >> was recently demoted to the hidden -XD-Xmodule. >> >> I'm curious to know why. >> >> Example: >> >> javac --module-path mods -d classes >> src/foo.mod/com.example.SomeClass.java >> >> This will compile SomeClass in the unnamed module, making it fail if it >> uses types from bar.mod (even if foo.mod requires it). >> >> I know of three ways to fix this: >> >> * adding module declaration to compile command >> * multi-module declaration >> * option -XD-Xmodule >> >> I found the last option to be conceptually most fitting and also the >> least troublesome. >> > -Xmodule was folded into --patch-module some time ago. Just add > `--patch-module foo.mod=src/foo.jmod` to the above. > > I'll have to defer to Jon or Jan as to why -Xmodule wasn't removed. As > I recall, it was made hidden to allow for transition but I thought > that was temporary. > There are some tests which still need to be changed to use --patch-module. Once all uses of -Xmodule have been removed from tests, we will remove the (hidden/undocumented) option. -- Jon > -Alan From Alan.Bateman at oracle.com Mon Jun 12 07:59:26 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 12 Jun 2017 08:59:26 +0100 Subject: Why is -XD-Xmodule hidden? In-Reply-To: References: Message-ID: On 11/06/2017 16:26, Jonathan Gibbons wrote: > > There are some tests which still need to be changed to use > --patch-module. Once all uses of -Xmodule have been removed from > tests, we will remove the (hidden/undocumented) option. I thought this was done already but I see now that there are small number of tests remaining in the hotspot repo that have not been updated. -Alan From alan.bateman at oracle.com Mon Jun 12 11:02:58 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 12 Jun 2017 11:02:58 +0000 Subject: hg: jigsaw/jake/jdk: Cleanup of CL spec, move text for default implementation to @implSpec Message-ID: <201706121102.v5CB2wXw009509@aojmv0008.oracle.com> Changeset: 741bd322be3e Author: alanb Date: 2017-06-12 12:01 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/741bd322be3e Cleanup of CL spec, move text for default implementation to @implSpec ! src/java.base/share/classes/java/lang/ClassLoader.java From markus_keller at ch.ibm.com Mon Jun 12 13:26:10 2017 From: markus_keller at ch.ibm.com (Markus Keller) Date: Mon, 12 Jun 2017 15:26:10 +0200 Subject: Annotation-based syntax for module-info.java Message-ID: [I know this is coming way too late, and my recent accident that incapacitated me for several week didn't help either. Nevertheless, I think the current module-info.java syntax was a snap decision that should not end up in the Java 9 spec.] The discussions about restricted keywords http://openjdk.java.net/projects/jigsaw/spec/issues/#RestrictedKeywords and the difficulties with defining a proper grammar for module-info.java indicate that something could be fundamentally wrong with the chosen approach that tries to come up with a new way of specifying a language. What module-info.java tries to achieve is to: - declare a module name - declare properties of the module, thereby referencing other modules, packages, and types For such simple declarative configuration descriptions, Java already has a sub-language: Annotations. The annotation syntax can be used to express all the properties of a module, and "@package" could be used as keyword to introduce a ModuleDeclaration like this: ModuleDeclaration: {Annotation} @package Identifier {. Identifier} ; This approach has huge advantages over the proposed new language: - completely solves all the problems related to restricted keywords and hardly parseable grammars - can be adopted by existing tooling very easily, and in most cases already works out of the box (syntax coloring, code completion, refactorings, search) - syntax is already understood by every Java developer: no new language to learn - doesn't require all the new class file attributes - has a proven built-in story for evolution of the module-info syntax The slightly more verbose syntax is not an issue in practice. The number of module-info.java files is negligible compared to other compilation units, and the fact that nobody has to learn a new language is more than enough to justify the few more characters. The "value=" in NormalAnnotation nodes looks a bit cumbersome, but this can easily be fixed in Java 10, e.g. by enhancing the general annotation language to make "value=" for the first annotation element optional, or by declaring the order of AnnotationTypeElementDeclaration declarations as relevant, and then allowing users to use unnamed ElementValues (positional arguments, like in method invocations). In this proposal, "@package" is to be pronounced as "module". That's not specially nice, but its precedent "@interface" that stands for "annotation" was not a problem either. Here's an example that compiles with the current annotation syntax (XXX comments indicate proposed improvements): //======================================= /** * Defines the Java API for JAX-WS. * * @since 9 */ @Deprecated(since="9", forRemoval=true) // XXX: value should be a qualified module name (without quotes): @Requires(value="java.activation", as=RequiresAttribute.TRANSITIVE) @Requires(value="java.xml", as=RequiresAttribute.STATIC) @Requires("java.xml.bind") @Uses(javax.xml.ws.spi.Provider.class) @Uses(javax.xml.soap.MessageFactory.class) // XXX: value should be a qualified package name (without quotes), or a // "package literal", that would look similar to a class literal, // but would end with ".package" instead of ".class" @Exports("javax.jws") // XXX: @Exports(javax.jws) or @Exports(javax.jws.package) @Exports("javax.jws.soap") @Opens(value="javax.xml.ws.wsaddressing", to="java.xml.bind") @Exports(value="com.oracle.webservices.internal.api.databinding", to="jdk.xml.ws") @Exports(value="com.sun.xml.internal.ws.addressing", to= {"jdk.xml.ws", "java.xml.bind"}) @Provides(value=java.nio.file.spi.FileSystemProvider.class, with=jdk.internal.jrtfs.JrtFileSystemProvider.class) //XXX: actually: @package java.xml.ws; package java.xml.ws; import java.lang.module.Exports; import java.lang.module.Opens; import java.lang.module.Provides; import java.lang.module.Requires; import java.lang.module.RequiresAttribute; import java.lang.module.Uses; //======================================= Regards, Markus From mark.reinhold at oracle.com Mon Jun 12 14:09:18 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 12 Jun 2017 07:09:18 -0700 Subject: Annotation-based syntax for module-info.java In-Reply-To: References: Message-ID: <20170612070918.182212822@eggemoggin.niobe.net> 2017/6/12 6:26:10 -0700, markus_keller at ch.ibm.com: > [I know this is coming way too late, and my recent accident that > incapacitated me for several week didn't help either. Nevertheless, I > think the current module-info.java syntax was a snap decision that should > not end up in the Java 9 spec.] Yes, this is coming way too late. No, the current module-info.java syntax was not a snap decision. - Mark From forax at univ-mlv.fr Mon Jun 12 14:46:55 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 12 Jun 2017 16:46:55 +0200 (CEST) Subject: Annotation-based syntax for module-info.java In-Reply-To: References: Message-ID: <1586071512.703398.1497278815903.JavaMail.zimbra@u-pem.fr> Hi Markus, ----- Mail original ----- > De: "Markus Keller" > ?: jigsaw-dev at openjdk.java.net > Cc: "Daniel Megert" > Envoy?: Lundi 12 Juin 2017 15:26:10 > Objet: Annotation-based syntax for module-info.java > [I know this is coming way too late, and my recent accident that > incapacitated me for several weeks didn't help either. Nevertheless, I > think the current module-info.java syntax was a snap decision that should > not end up in the Java 9 spec.] i hope you're well now, and as you said, it's too late, and it doesn't solve the issue we had (see below ...) > > The discussions about restricted keywords > http://openjdk.java.net/projects/jigsaw/spec/issues/#RestrictedKeywords > and the difficulties with defining a proper grammar for module-info.java > indicate that something could be fundamentally wrong with the chosen > approach that tries to come up with a new way of specifying a language. The problem is not to define the grammar, the module-info grammar is very straight forward. The problem is how to introduce new keywords when the language evolves without breaking the source compatibility as we have done with assert and enum in the past. Even if we can use annotations (that's ugly but it works) to solve the particular case of the module-info, we will have the same issue when we will want to introduce new keywords like 'var', 'data', 'closed', 'value'*, etc in the future. Local keyword (named restricted keyword in the spec) is a good answer for specifying how a keyword and an identifier can have the same name and disambiguate them. cheers, R?mi * those keywords are among the ones proposed by projects Amber and Valhalla for the next releases of Java. From alan.bateman at oracle.com Mon Jun 12 18:31:53 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 12 Jun 2017 18:31:53 +0000 Subject: hg: jigsaw/jake/jdk: Move locating/ordering sections from SL spec to SL.load methods Message-ID: <201706121831.v5CIVrrl025155@aojmv0008.oracle.com> Changeset: 01a5ea9fa211 Author: alanb Date: 2017-06-12 19:30 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/01a5ea9fa211 Move locating/ordering sections from SL spec to SL.load methods ! src/java.base/share/classes/java/util/ServiceLoader.java From jan.lahoda at oracle.com Mon Jun 12 20:35:06 2017 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Mon, 12 Jun 2017 20:35:06 +0000 Subject: hg: jigsaw/jake/langtools: 8181925: Confusing error when unnamed module reads multiple modules exporting the same package. Message-ID: <201706122035.v5CKZ65j019539@aojmv0008.oracle.com> Changeset: 31edb164e288 Author: jlahoda Date: 2017-06-12 22:30 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/31edb164e288 8181925: Confusing error when unnamed module reads multiple modules exporting the same package. Summary: Adding special wording for package clash in modules read by the unnamed module. ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/PackageClashFromRequiresInUnnamed/PackageClashFromRequiresInUnnamed.java + test/tools/javac/diags/examples/PackageClashFromRequiresInUnnamed/modulepath/lib1x/exported/Api1.java + test/tools/javac/diags/examples/PackageClashFromRequiresInUnnamed/modulepath/lib1x/module-info.java + test/tools/javac/diags/examples/PackageClashFromRequiresInUnnamed/modulepath/lib2x/exported/Api2.java + test/tools/javac/diags/examples/PackageClashFromRequiresInUnnamed/modulepath/lib2x/module-info.java ! test/tools/javac/modules/PackageConflictTest.java From rgoers at apache.org Mon Jun 12 21:31:39 2017 From: rgoers at apache.org (Ralph Goers) Date: Mon, 12 Jun 2017 14:31:39 -0700 Subject: Annotation-based syntax for module-info.java In-Reply-To: References: Message-ID: <7D0846A0-822D-4500-ABDB-254E71E46844@apache.org> I had this same thought a week or so ago and I wouldn?t be surprised to see someone create a framework that generates a module-info.java from annotations. But that doesn?t solve the issues I have hit, which all stem from module-info.class conflicting with pre-java 9 tools. Frankly, I don?t know why module-info.java and package-info.java are ?real? java files since they really contain meta-data. Things would work much better if these were json files or something else. package-info.java seems especially silly since the Java compiler seems to ignore these files unless you tell it not to (and the compiler doc mentions that it will let you create the class files just to make Ant happy that there is a matching class file for every source file). Ralph > On Jun 12, 2017, at 6:26 AM, Markus Keller wrote: > > [I know this is coming way too late, and my recent accident that > incapacitated me for several week didn't help either. Nevertheless, I > think the current module-info.java syntax was a snap decision that should > not end up in the Java 9 spec.] > > The discussions about restricted keywords > http://openjdk.java.net/projects/jigsaw/spec/issues/#RestrictedKeywords > and the difficulties with defining a proper grammar for module-info.java > indicate that something could be fundamentally wrong with the chosen > approach that tries to come up with a new way of specifying a language. > > What module-info.java tries to achieve is to: > - declare a module name > - declare properties of the module, thereby referencing other modules, > packages, and types > > For such simple declarative configuration descriptions, Java already has a > sub-language: Annotations. > The annotation syntax can be used to express all the properties of a > module, and "@package" could be used as keyword to introduce a > ModuleDeclaration like this: > > ModuleDeclaration: > {Annotation} @package Identifier {. Identifier} ; > > This approach has huge advantages over the proposed new language: > - completely solves all the problems related to restricted keywords and > hardly parseable grammars > - can be adopted by existing tooling very easily, and in most cases > already works out of the box (syntax coloring, code completion, > refactorings, search) > - syntax is already understood by every Java developer: no new language to > learn > - doesn't require all the new class file attributes > - has a proven built-in story for evolution of the module-info syntax > > The slightly more verbose syntax is not an issue in practice. The number > of module-info.java files is negligible compared to other compilation > units, and the fact that nobody has to learn a new language is more than > enough to justify the few more characters. > > The "value=" in NormalAnnotation nodes looks a bit cumbersome, but this > can easily be fixed in Java 10, e.g. by enhancing the general annotation > language to make "value=" for the first annotation element optional, or by > declaring the order of AnnotationTypeElementDeclaration declarations as > relevant, and then allowing users to use unnamed ElementValues (positional > arguments, like in method invocations). > > In this proposal, "@package" is to be pronounced as "module". That's not > specially nice, but its precedent "@interface" that stands for > "annotation" was not a problem either. > > > Here's an example that compiles with the current annotation syntax (XXX > comments indicate proposed improvements): > > //======================================= > /** > * Defines the Java API for JAX-WS. > * > * @since 9 > */ > @Deprecated(since="9", forRemoval=true) > > // XXX: value should be a qualified module name (without quotes): > @Requires(value="java.activation", as=RequiresAttribute.TRANSITIVE) > @Requires(value="java.xml", as=RequiresAttribute.STATIC) > @Requires("java.xml.bind") > > @Uses(javax.xml.ws.spi.Provider.class) > @Uses(javax.xml.soap.MessageFactory.class) > > // XXX: value should be a qualified package name (without quotes), or a > // "package literal", that would look similar to a class literal, > // but would end with ".package" instead of ".class" > @Exports("javax.jws") // XXX: @Exports(javax.jws) or > @Exports(javax.jws.package) > @Exports("javax.jws.soap") > > @Opens(value="javax.xml.ws.wsaddressing", to="java.xml.bind") > > @Exports(value="com.oracle.webservices.internal.api.databinding", > to="jdk.xml.ws") > @Exports(value="com.sun.xml.internal.ws.addressing", to= {"jdk.xml.ws", > "java.xml.bind"}) > > @Provides(value=java.nio.file.spi.FileSystemProvider.class, > with=jdk.internal.jrtfs.JrtFileSystemProvider.class) > > //XXX: actually: @package java.xml.ws; > package java.xml.ws; > > import java.lang.module.Exports; > import java.lang.module.Opens; > import java.lang.module.Provides; > import java.lang.module.Requires; > import java.lang.module.RequiresAttribute; > import java.lang.module.Uses; > //======================================= > > Regards, > Markus > > > From stephan.herrmann at berlin.de Tue Jun 13 01:10:44 2017 From: stephan.herrmann at berlin.de (Stephan Herrmann) Date: Tue, 13 Jun 2017 03:10:44 +0200 Subject: Annotation-based syntax for module-info.java In-Reply-To: <7D0846A0-822D-4500-ABDB-254E71E46844@apache.org> References: <7D0846A0-822D-4500-ABDB-254E71E46844@apache.org> Message-ID: We don't need more proposals how to solve the problem. We need agreement that we have a problem! Stephan On 12.06.2017 23:31, Ralph Goers wrote: > I had this same thought a week or so ago and I wouldn?t be surprised to see someone create a framework that generates a module-info.java from annotations. But that doesn?t solve the issues I have hit, which all stem from module-info.class conflicting with pre-java 9 tools. Frankly, I don?t know why module-info.java and package-info.java are ?real? java files since they really contain meta-data. Things would work much better if these were json files or something else. package-info.java seems especially silly since the Java compiler seems to ignore these files unless you tell it not to (and the compiler doc mentions that it will let you create the class files just to make Ant happy that there is a matching class file for every source file). > > Ralph > >> On Jun 12, 2017, at 6:26 AM, Markus Keller wrote: >> >> [I know this is coming way too late, and my recent accident that >> incapacitated me for several week didn't help either. Nevertheless, I >> think the current module-info.java syntax was a snap decision that should >> not end up in the Java 9 spec.] >> >> The discussions about restricted keywords >> http://openjdk.java.net/projects/jigsaw/spec/issues/#RestrictedKeywords >> and the difficulties with defining a proper grammar for module-info.java >> indicate that something could be fundamentally wrong with the chosen >> approach that tries to come up with a new way of specifying a language. >> >> What module-info.java tries to achieve is to: >> - declare a module name >> - declare properties of the module, thereby referencing other modules, >> packages, and types >> >> For such simple declarative configuration descriptions, Java already has a >> sub-language: Annotations. >> The annotation syntax can be used to express all the properties of a >> module, and "@package" could be used as keyword to introduce a >> ModuleDeclaration like this: >> >> ModuleDeclaration: >> {Annotation} @package Identifier {. Identifier} ; >> >> This approach has huge advantages over the proposed new language: >> - completely solves all the problems related to restricted keywords and >> hardly parseable grammars >> - can be adopted by existing tooling very easily, and in most cases >> already works out of the box (syntax coloring, code completion, >> refactorings, search) >> - syntax is already understood by every Java developer: no new language to >> learn >> - doesn't require all the new class file attributes >> - has a proven built-in story for evolution of the module-info syntax >> >> The slightly more verbose syntax is not an issue in practice. The number >> of module-info.java files is negligible compared to other compilation >> units, and the fact that nobody has to learn a new language is more than >> enough to justify the few more characters. >> >> The "value=" in NormalAnnotation nodes looks a bit cumbersome, but this >> can easily be fixed in Java 10, e.g. by enhancing the general annotation >> language to make "value=" for the first annotation element optional, or by >> declaring the order of AnnotationTypeElementDeclaration declarations as >> relevant, and then allowing users to use unnamed ElementValues (positional >> arguments, like in method invocations). >> >> In this proposal, "@package" is to be pronounced as "module". That's not >> specially nice, but its precedent "@interface" that stands for >> "annotation" was not a problem either. >> >> >> Here's an example that compiles with the current annotation syntax (XXX >> comments indicate proposed improvements): >> >> //======================================= >> /** >> * Defines the Java API for JAX-WS. >> * >> * @since 9 >> */ >> @Deprecated(since="9", forRemoval=true) >> >> // XXX: value should be a qualified module name (without quotes): >> @Requires(value="java.activation", as=RequiresAttribute.TRANSITIVE) >> @Requires(value="java.xml", as=RequiresAttribute.STATIC) >> @Requires("java.xml.bind") >> >> @Uses(javax.xml.ws.spi.Provider.class) >> @Uses(javax.xml.soap.MessageFactory.class) >> >> // XXX: value should be a qualified package name (without quotes), or a >> // "package literal", that would look similar to a class literal, >> // but would end with ".package" instead of ".class" >> @Exports("javax.jws") // XXX: @Exports(javax.jws) or >> @Exports(javax.jws.package) >> @Exports("javax.jws.soap") >> >> @Opens(value="javax.xml.ws.wsaddressing", to="java.xml.bind") >> >> @Exports(value="com.oracle.webservices.internal.api.databinding", >> to="jdk.xml.ws") >> @Exports(value="com.sun.xml.internal.ws.addressing", to= {"jdk.xml.ws", >> "java.xml.bind"}) >> >> @Provides(value=java.nio.file.spi.FileSystemProvider.class, >> with=jdk.internal.jrtfs.JrtFileSystemProvider.class) >> >> //XXX: actually: @package java.xml.ws; >> package java.xml.ws; >> >> import java.lang.module.Exports; >> import java.lang.module.Opens; >> import java.lang.module.Provides; >> import java.lang.module.Requires; >> import java.lang.module.RequiresAttribute; >> import java.lang.module.Uses; >> //======================================= >> >> Regards, >> Markus >> >> >> > > From mandy.chung at oracle.com Tue Jun 13 05:35:04 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 12 Jun 2017 22:35:04 -0700 Subject: Review Request JDK-8182032: Make java.compiler upgradeable Message-ID: <268EE83D-7C9C-4BF4-B062-10EB9F06C770@oracle.com> Webrev at: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8182032/webrev.00/ java.compiler is a standalone technology that allows to be running on older JDK, in particular for IDE to support new language features. This patch takes out the make logic to find the modules that directly and indirectly require any upgradeable modules and include them as upgradeable. Instead it lists all upgradeable modules. The list of upgradeable modules is small whereas the exclude list is not (which is also error-prone to find them). I have added a new test to verify what modules are hashed in java.base. Mandy From forax at univ-mlv.fr Tue Jun 13 07:42:21 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 13 Jun 2017 09:42:21 +0200 (CEST) Subject: Review Request JDK-8182032: Make java.compiler upgradeable In-Reply-To: <268EE83D-7C9C-4BF4-B062-10EB9F06C770@oracle.com> References: <268EE83D-7C9C-4BF4-B062-10EB9F06C770@oracle.com> Message-ID: <2116144525.859166.1497339741029.JavaMail.zimbra@u-pem.fr> Hi Mandy, why only java.compiler is upgradable and not all modules defined in langtools ? cheers, R?mi ----- Mail original ----- > De: "Mandy Chung" > ?: "jigsaw-dev" > Envoy?: Mardi 13 Juin 2017 07:35:04 > Objet: Review Request JDK-8182032: Make java.compiler upgradeable > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8182032/webrev.00/ > > java.compiler is a standalone technology that allows to be running on older JDK, > in particular for IDE to support new language features. > > This patch takes out the make logic to find the modules that directly and > indirectly require any upgradeable modules and include them as upgradeable. > Instead it lists all upgradeable modules. The list of upgradeable modules is > small whereas the exclude list is not (which is also error-prone to find them). > I have added a new test to verify what modules are hashed in java.base. > > Mandy From Alan.Bateman at oracle.com Tue Jun 13 08:26:18 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 13 Jun 2017 09:26:18 +0100 Subject: Review Request JDK-8182032: Make java.compiler upgradeable In-Reply-To: <2116144525.859166.1497339741029.JavaMail.zimbra@u-pem.fr> References: <268EE83D-7C9C-4BF4-B062-10EB9F06C770@oracle.com> <2116144525.859166.1497339741029.JavaMail.zimbra@u-pem.fr> Message-ID: On 13/06/2017 08:42, Remi Forax wrote: > Hi Mandy, > why only java.compiler is upgradable and not all modules defined in langtools ? > java.compiler needs to be upgradeable because JSR 199 and JSR 269 are standalone technologies. The other modules in the langtools repository are JDK-specific. They aren't meant to be upgraded via the upgrade module path. If someone is forking the code to create their own version of jdk.compiler (for example) then they can re-package or load it into a child layer. -Alan From forax at univ-mlv.fr Tue Jun 13 09:11:45 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 13 Jun 2017 09:11:45 +0000 Subject: Review Request JDK-8182032: Make java.compiler upgradeable In-Reply-To: References: <268EE83D-7C9C-4BF4-B062-10EB9F06C770@oracle.com> <2116144525.859166.1497339741029.JavaMail.zimbra@u-pem.fr> Message-ID: <0E769C8B-2C63-4438-8085-B7A3D1E40201@univ-mlv.fr> My concern is that by example javac and javap need to be aligned and by making a module upgradeable you can not make only some packages upgradeable. So it seems logical that if java.compiler is upgradeable the other modules of langtools are upgradable too. R?mi On June 13, 2017 10:26:18 AM GMT+02:00, Alan Bateman wrote: >On 13/06/2017 08:42, Remi Forax wrote: >> Hi Mandy, >> why only java.compiler is upgradable and not all modules defined in >langtools ? >> >java.compiler needs to be upgradeable because JSR 199 and JSR 269 are >standalone technologies. > >The other modules in the langtools repository are JDK-specific. They >aren't meant to be upgraded via the upgrade module path. If someone is >forking the code to create their own version of jdk.compiler (for >example) then they can re-package or load it into a child layer. > >-Alan -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From alan.bateman at oracle.com Tue Jun 13 13:00:31 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 13 Jun 2017 13:00:31 +0000 Subject: hg: jigsaw/jake/jdk: Migrate jl.instrument package.html to package-info.java, misc. cleanup Message-ID: <201706131300.v5DD0V9Y009940@aojmv0008.oracle.com> Changeset: 9269173b154d Author: alanb Date: 2017-06-13 13:56 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9269173b154d Migrate jl.instrument package.html to package-info.java, misc. cleanup + src/java.instrument/share/classes/java/lang/instrument/package-info.java - src/java.instrument/share/classes/java/lang/instrument/package.html From alan.bateman at oracle.com Tue Jun 13 20:02:44 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 13 Jun 2017 20:02:44 +0000 Subject: hg: jigsaw/jake/jdk: More clean-up of SL javadoc Message-ID: <201706132002.v5DK2iWG010589@aojmv0008.oracle.com> Changeset: 7ec1b2a769fe Author: alanb Date: 2017-06-13 21:01 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7ec1b2a769fe More clean-up of SL javadoc ! src/java.base/share/classes/java/util/ServiceLoader.java From mandy.chung at oracle.com Tue Jun 13 20:33:01 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 13 Jun 2017 13:33:01 -0700 Subject: Review Request JDK-8182032: Make java.compiler upgradeable In-Reply-To: <0E769C8B-2C63-4438-8085-B7A3D1E40201@univ-mlv.fr> References: <268EE83D-7C9C-4BF4-B062-10EB9F06C770@oracle.com> <2116144525.859166.1497339741029.JavaMail.zimbra@u-pem.fr> <0E769C8B-2C63-4438-8085-B7A3D1E40201@univ-mlv.fr> Message-ID: <8627A53E-5F24-4C6F-8AF0-57A8C91AB133@oracle.com> The langtools modules are not intended nor required to be upgradeable. JDK 9 javap will only work with JDK 9 java.compiler. When IDE upgrades java.compiler to JDK 10 and runs on JDK 9, it would have to deliver a Java compiler implementing JDK 10 JavaCompiler API and could also implement the new version of javap. One thing to mention is that javap is java.util.spi.ToolProvider and it could provide a ToolProvider of this new version of javap. Mandy FYI. The list of modules that directly and indirectly require java.compiler: $ jdeps -I --require java.compiler Inverse transitive dependences on [java.compiler] java.compiler <- jdk.jshell java.compiler <- jdk.scripting.nashorn.shell java.compiler <- jdk.xml.ws java.compiler <- java.se <- java.se.ee java.compiler <- java.xml.bind <- java.se.ee java.compiler <- java.xml.bind <- jdk.xml.bind java.compiler <- java.xml.bind <- jdk.xml.ws java.compiler <- jdk.compiler <- jdk.javadoc java.compiler <- jdk.compiler <- jdk.jdeps java.compiler <- jdk.compiler <- jdk.jshell java.compiler <- jdk.compiler <- jdk.rmic java.compiler <- jdk.compiler <- jdk.xml.bind java.compiler <- jdk.javadoc <- jdk.rmic java.compiler <- jdk.jdeps <- jdk.packager java.compiler <- jdk.xml.bind <- jdk.xml.ws java.compiler <- java.xml.bind <- java.xml.ws <- java.se.ee java.compiler <- java.xml.bind <- java.xml.ws <- jdk.xml.ws java.compiler <- jdk.jdeps <- jdk.jlink <- jdk.packager > On Jun 13, 2017, at 2:11 AM, Remi Forax wrote: > > My concern is that by example javac and javap need to be aligned and by making a module upgradeable you can not make only some packages upgradeable. > So it seems logical that if java.compiler is upgradeable the other modules of langtools are upgradable too. > > R?mi > > > On June 13, 2017 10:26:18 AM GMT+02:00, Alan Bateman wrote: >> On 13/06/2017 08:42, Remi Forax wrote: >>> Hi Mandy, >>> why only java.compiler is upgradable and not all modules defined in >> langtools ? >>> >> java.compiler needs to be upgradeable because JSR 199 and JSR 269 are >> standalone technologies. >> >> The other modules in the langtools repository are JDK-specific. They >> aren't meant to be upgraded via the upgrade module path. If someone is >> forking the code to create their own version of jdk.compiler (for >> example) then they can re-package or load it into a child layer. >> >> -Alan > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. From erik.joelsson at oracle.com Wed Jun 14 06:52:54 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 14 Jun 2017 08:52:54 +0200 Subject: Review Request JDK-8182032: Make java.compiler upgradeable In-Reply-To: <268EE83D-7C9C-4BF4-B062-10EB9F06C770@oracle.com> References: <268EE83D-7C9C-4BF4-B062-10EB9F06C770@oracle.com> Message-ID: <5093902b-7f33-d543-cf39-629da85bff57@oracle.com> Hello Mandy, Looks good to me. /Erik On 2017-06-13 07:35, Mandy Chung wrote: > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8182032/webrev.00/ > > java.compiler is a standalone technology that allows to be running on older JDK, in particular for IDE to support new language features. > > This patch takes out the make logic to find the modules that directly and indirectly require any upgradeable modules and include them as upgradeable. Instead it lists all upgradeable modules. The list of upgradeable modules is small whereas the exclude list is not (which is also error-prone to find them). I have added a new test to verify what modules are hashed in java.base. > > Mandy From Alan.Bateman at oracle.com Wed Jun 14 07:45:02 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 14 Jun 2017 08:45:02 +0100 Subject: Accessing module internals from bytecode rewriting agent In-Reply-To: References: <2099da91-fe6e-a5ed-3396-1e57284a75f1@oracle.com> <64a587a9-ec06-f0cd-f136-149b85e083d7@oracle.com> <3aef86fc-3fc2-9ff9-7be4-06d92800f0a7@oracle.com> <0e51419c-b100-8dc8-fb81-dd0b50b5177b@oracle.com> Message-ID: <8d225548-dadb-5b07-fcc5-4d1e37d43162@oracle.com> On 14/06/2017 00:57, Jeremy Manson wrote: > Hey folks, > > As a followup to this, given everything else that has happened in the mean > time: I wonder if the same logic Mark put in his proposal to allow illegal > access to internal APIs ( > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-June/012841.html) in > JDK 9 also applies to Xbootclasspath/p. > > Mark's stated goal in his revised proposal is to address concerns that code > that works on JDK 8 today will not work on JDK 9 tomorrow, yet no advance > warning of this change was given at run time in JDK 8. No advance warning > was given for the removal of -Xbootclasspath/p, and, without it, there will > need to be a lot of fiddly logic in a lot of scripting languages to allow > for testing to switch between Java 8 and Java 9. > > Dalibor's previous response of "-X options are subject to change" is > probably not relevant, given the fact that everything that is being done > via access to internal APIs is subject to change, and Mark's proposal is > probably the way Java 9 will be rolled out. > > There are plenty of XX flags that aren't removed without warning, too: > -XX:+UseConcMarkSweepGC is going to spend an entire release cycle > deprecated. > > Would it make sense to make -Xbootclasspath/p available again, possibly > only if the kill switch is enabled? > There is no proposal to bring back the unsupported -Xbootclasspath/p. That option was for overriding classes defined to the boot loader, something that doesn't make sense with JDK 9 where the boot class path is mostly gone and where many of the APIs that could potentially be patched via -Xbootclasspath/p are not defined to the boot loader anymore. As Remi note, the option to look at is -patch-module option, the details are in JEP 261 [1]. As regards --illegal-access then there is no connection. That proposal just opens the packages that existed in JDK 8 to allow code that hacks JDK internals (with core reflection mostly) to continue to work for a bit longer. It doesn't change anything else. -Alan. [1] http://openjdk.java.net/jeps/261 From alan.bateman at oracle.com Wed Jun 14 14:00:59 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 14 Jun 2017 14:00:59 +0000 Subject: hg: jigsaw/jake/jdk: 4 new changesets Message-ID: <201706141400.v5EE0xmD005031@aojmv0008.oracle.com> Changeset: 4d68e26297db Author: alanb Date: 2017-06-14 09:31 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4d68e26297db More clean-up/clarification to jl.instrument spec ! src/java.instrument/share/classes/java/lang/instrument/package-info.java Changeset: 4c1a6e0ad708 Author: alanb Date: 2017-06-14 10:05 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4c1a6e0ad708 Tests should exercise getDeclaredAnnotations ! test/java/lang/ModuleTests/AnnotationsTest.java ! test/java/lang/ModuleTests/annotation/Basic.java Changeset: 8c57b928e22f Author: alanb Date: 2017-06-14 14:08 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8c57b928e22f defineModulesWithXXX do not specify how they locate resources ! src/java.base/share/classes/java/lang/ModuleLayer.java ! src/java.base/share/classes/jdk/internal/loader/Loader.java ! test/java/lang/ModuleLayer/LayerAndLoadersTest.java Changeset: 43fb98a8f239 Author: alanb Date: 2017-06-14 14:14 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/43fb98a8f239 ModuleReferenceImpl can keep reference to module location to help startup ! src/java.base/share/classes/jdk/internal/module/ModuleReferenceImpl.java From mandy.chung at oracle.com Wed Jun 14 15:55:51 2017 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 14 Jun 2017 15:55:51 +0000 Subject: hg: jigsaw/jake/langtools: Clean up jdk.jdeps module-info.java Message-ID: <201706141555.v5EFtpnf011855@aojmv0008.oracle.com> Changeset: 046969a94992 Author: mchung Date: 2017-06-14 08:53 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/046969a94992 Clean up jdk.jdeps module-info.java ! src/jdk.jdeps/share/classes/module-info.java From alan.bateman at oracle.com Wed Jun 14 16:14:26 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 14 Jun 2017 16:14:26 +0000 Subject: hg: jigsaw/jake/jdk: Restore paragraph on SM, removed in error Message-ID: <201706141614.v5EGEQxB020808@aojmv0008.oracle.com> Changeset: c488bbb509d9 Author: alanb Date: 2017-06-14 16:58 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c488bbb509d9 Restore paragraph on SM, removed in error ! src/java.base/share/classes/java/lang/ModuleLayer.java From Alan.Bateman at oracle.com Wed Jun 14 16:52:59 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 14 Jun 2017 17:52:59 +0100 Subject: 8181087: Module system implementation refresh (6/2017 update) Message-ID: It's time to bring the changes accumulated in the jake forest into jdk9/dev. I'm hoping we are near the end of these updates and that we can close the jake forest soon. A summary of the changes that have accumulated for this update are listed in this issue: https://bugs.openjdk.java.net/browse/JDK-8181087 Aside from the important spec/javadoc updates, this update will bring the -illegal-access option into JDK 9 to replace the --permit-illegal-access option. The webrevs with the changes are here: http://cr.openjdk.java.net/~alanb/8181087/1/ -Alan From peter.levart at gmail.com Wed Jun 14 21:44:14 2017 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 14 Jun 2017 23:44:14 +0200 Subject: 8181087: Module system implementation refresh (6/2017 update) In-Reply-To: References: Message-ID: Hi Alan, Looking just at changes in jdk part... On 06/14/2017 06:52 PM, Alan Bateman wrote: > It's time to bring the changes accumulated in the jake forest into > jdk9/dev. I'm hoping we are near the end of these updates and that we > can close the jake forest soon. > > A summary of the changes that have accumulated for this update are > listed in this issue: > https://bugs.openjdk.java.net/browse/JDK-8181087 > > Aside from the important spec/javadoc updates, this update will bring > the -illegal-access option into JDK 9 to replace the > --permit-illegal-access option. > > The webrevs with the changes are here: > http://cr.openjdk.java.net/~alanb/8181087/1/ > > -Alan In j.l.Class, you have this new method: 2447 List getDeclaredPublicMethods(String name, Class... parameterTypes) { 2448 Method[] methods = privateGetDeclaredMethods(/* publicOnly */ true); 2449 List result = new ArrayList<>(); 2450 for (Method method : methods) { 2451 if (method.getName().equals(name) 2452 && Arrays.equals( 2453 reflectionFactory.getExecutableSharedParameterTypes(method), 2454 parameterTypes)) { 2455 result.add(getReflectionFactory().copyMethod(method)); 2456 } 2457 } 2458 return result; 2459 } ...where you use the 'reflectionFactory' field one time and 'getReflectionFactory()' method another time. The field might not already be initialized... 3479 // Fetches the factory for reflective objects 3480 private static ReflectionFactory getReflectionFactory() { 3481 if (reflectionFactory == null) { 3482 reflectionFactory = 3483 java.security.AccessController.doPrivileged 3484 (new ReflectionFactory.GetReflectionFactoryAction()); 3485 } 3486 return reflectionFactory; 3487 } 3488 private static ReflectionFactory reflectionFactory; Since 'reflectionFactory' field is not volatile, I would also introduce a local variable into getReflectionFactory() so that the field is read only once which would prevent theoretical possibility of reordering the re-reading of the non-volatile filed before the (1st) reading of the field which could cause getReflectionFactory() to return null. In j.l.Module: There are two places in the same method that contain exactly the same fragment of code: 566 if (targets.contains(EVERYONE_MODULE) || targets.contains(other)) 567 return true; 568 if (other != EVERYONE_MODULE 569 && !other.isNamed() && targets.contains(ALL_UNNAMED_MODULE)) 570 return true; Perhaps this could be factored out into separate private method which could also be made a little more optimal (when other == EVERYONE_MODULE and targets does not contain it, it is looked-up twice currently). For example: private static boolean isIncludedIn(Module module, Set targets) { return targets != null && ( targets.contains(EVERYONE_MODULE) || !module.isNamed() && targets.contains(ALL_UNNAMED_MODULE) || // ALL_UNNAMED_MODULE.isNamed() == false module != EVERYONE_MODULE && module != ALL_UNNAMED_MODULE && targets.contains(module) ); } In j.u.ServiceLoader: The following method: 601 /** 602 * Returns true if the given class is assignable to a class or interface 603 * with the given name. 604 */ 605 private boolean isAssignable(Class clazz, String className) { 606 Class c = clazz; 607 while (c != null) { 608 if (c.getName().equals(className)) { 609 return true; 610 } 611 for (Class interf : c.getInterfaces()) { 612 if (interf.getName().equals(className)) { 613 return true; 614 } 615 } 616 c = c.getSuperclass(); 617 } 618 return false; 619 } ...does not return true for situations like: public interface A {} public interface B extends A {} public class C implements B {} isAssignable(C.class, "A") ??? If A is a service interface and C is its implementation class, should C be considered a valid service provider? If yes, the method might need some stack or queue or recursion. In IllegalAccessLogger: Is the following method: 280 private void log(Class caller, String what, Supplier msgSupplier) ... Invoked frequently from different threads? Might synchronization in this method be a performance bottleneck? There are some optimizations possible... That's all for now. Regards, Peter From serguei.spitsyn at oracle.com Wed Jun 14 22:57:20 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 14 Jun 2017 15:57:20 -0700 Subject: 8181087: Module system implementation refresh (6/2017 update) In-Reply-To: References: Message-ID: <0a84c463-fca4-c5be-11a6-3b5b1b39e99e@oracle.com> Hi Alan, I looked at the hotspot and top changes. They look good. Thanks, Serguei On 6/14/17 09:52, Alan Bateman wrote: > It's time to bring the changes accumulated in the jake forest into > jdk9/dev. I'm hoping we are near the end of these updates and that we > can close the jake forest soon. > > A summary of the changes that have accumulated for this update are > listed in this issue: > https://bugs.openjdk.java.net/browse/JDK-8181087 > > Aside from the important spec/javadoc updates, this update will bring > the -illegal-access option into JDK 9 to replace the > --permit-illegal-access option. > > The webrevs with the changes are here: > http://cr.openjdk.java.net/~alanb/8181087/1/ > > -Alan From jeremymanson at google.com Thu Jun 15 00:00:54 2017 From: jeremymanson at google.com (Jeremy Manson) Date: Wed, 14 Jun 2017 17:00:54 -0700 Subject: Accessing module internals from bytecode rewriting agent In-Reply-To: <8d225548-dadb-5b07-fcc5-4d1e37d43162@oracle.com> References: <2099da91-fe6e-a5ed-3396-1e57284a75f1@oracle.com> <64a587a9-ec06-f0cd-f136-149b85e083d7@oracle.com> <3aef86fc-3fc2-9ff9-7be4-06d92800f0a7@oracle.com> <0e51419c-b100-8dc8-fb81-dd0b50b5177b@oracle.com> <8d225548-dadb-5b07-fcc5-4d1e37d43162@oracle.com> Message-ID: Hey folks, I understand that -patch-module accomplishes similar goals. The point I was making is that it can be a pain to change deployment / testing scripts that contain command line flags to have two different versions of those flags, which get chosen depending on what JDK you are running. In fact, given our codebase, it will be likely to be a bigger job for us to deal with the -Xbootclasspath/p flag transition than to deal with a lot of the other transition problems that are fixed by Mark's proposal. Introspection into the JDK happens in a small number of places. You may have to be a bit clever about how you fix it, but they are generally fixable. By contrast, there are hundreds of little snippets of shell we have to change to get rid of Xbootclasspath/p. And given that you want both JDK 8 and JDK 9 working at the same time, you have to make two passes over all that shell: one to make sure both versions are supported, and then a second one later to remove the JDK 8 support. It would be much easier for us to leave -Xbootclasspath/p in place, and then fix it all once we've finalized the transition, but before Java 10 comes out. The upshot is that, in the same way as we would have turned on the big kill switch by default to ease the transition, we are also likely to implement -Xbootclasspath/p to ease the transition. I note that you came around on the big kill switch being on by default for the transition, so I thought you might also come around on continuing to provide -Xbootclasspath/p for the transition. Jeremy On Wed, Jun 14, 2017 at 12:45 AM, Alan Bateman wrote: > On 14/06/2017 00:57, Jeremy Manson wrote: > >> Hey folks, >> >> As a followup to this, given everything else that has happened in the mean >> time: I wonder if the same logic Mark put in his proposal to allow illegal >> access to internal APIs ( >> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-June/012841.html) >> in >> JDK 9 also applies to Xbootclasspath/p. >> >> Mark's stated goal in his revised proposal is to address concerns that >> code >> that works on JDK 8 today will not work on JDK 9 tomorrow, yet no advance >> warning of this change was given at run time in JDK 8. No advance warning >> was given for the removal of -Xbootclasspath/p, and, without it, there >> will >> need to be a lot of fiddly logic in a lot of scripting languages to allow >> for testing to switch between Java 8 and Java 9. >> >> Dalibor's previous response of "-X options are subject to change" is >> probably not relevant, given the fact that everything that is being done >> via access to internal APIs is subject to change, and Mark's proposal is >> probably the way Java 9 will be rolled out. >> >> There are plenty of XX flags that aren't removed without warning, too: >> -XX:+UseConcMarkSweepGC is going to spend an entire release cycle >> deprecated. >> >> Would it make sense to make -Xbootclasspath/p available again, possibly >> only if the kill switch is enabled? >> >> There is no proposal to bring back the unsupported -Xbootclasspath/p. > That option was for overriding classes defined to the boot loader, > something that doesn't make sense with JDK 9 where the boot class path is > mostly gone and where many of the APIs that could potentially be patched > via -Xbootclasspath/p are not defined to the boot loader anymore. As Remi > note, the option to look at is -patch-module option, the details are in JEP > 261 [1]. > > As regards --illegal-access then there is no connection. That proposal > just opens the packages that existed in JDK 8 to allow code that hacks JDK > internals (with core reflection mostly) to continue to work for a bit > longer. It doesn't change anything else. > > -Alan. > > [1] http://openjdk.java.net/jeps/261 > > > > From mandy.chung at oracle.com Thu Jun 15 05:37:33 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 14 Jun 2017 22:37:33 -0700 Subject: 8181087: Module system implementation refresh (6/2017 update) In-Reply-To: References: Message-ID: > On Jun 14, 2017, at 9:52 AM, Alan Bateman wrote: > > It's time to bring the changes accumulated in the jake forest into jdk9/dev. I'm hoping we are near the end of these updates and that we can close the jake forest soon. > > A summary of the changes that have accumulated for this update are listed in this issue: > https://bugs.openjdk.java.net/browse/JDK-8181087 > > Aside from the important spec/javadoc updates, this update will bring the -illegal-access option into JDK 9 to replace the --permit-illegal-access option. > > The webrevs with the changes are here: > http://cr.openjdk.java.net/~alanb/8181087/1/ > java/lang/Class.java 2453 reflectionFactory.getExecutableSharedParameterTypes(method), reflectionFactory should be accessed via getReflectionFactory(). I see Peter already comments on this. java/lang/Module.java 901 void implAddOpensToAllUnnamed(Iterator iterator) { 902 if (jdk.internal.misc.VM.isModuleSystemInited()) { 903 iterator.forEachRemaining(pn -> 904 implAddExportsOrOpens(pn, ALL_UNNAMED_MODULE, true, true)); 905 return; 906 } AFAICT this should only be called during module system initialization. When will this method be called after initPhase 2? jdk/internal/loader/Loader.java 406 public Enumeration getResources(String name) throws IOException { 407 // this loader 408 List urls = findResourcesAsList(name); 409 410 // parent loader 411 parent.getResources(name).asIterator().forEachRemaining(urls::add); 412 413 return Collections.enumeration(urls); 414 } We could consider returning an Enumeration that defers finding resources from parent class loader after iterating the local resources. ModuleBootstrap.java line 406, 418 the formatting seems off. ModulePath.java 408 private static final Attributes.Name AUTOMATIC_MODULE_NAME 409 = new Attributes.Name("Automatic-Module-Name"); Should this be defined in java.util.jar.Attributes.Name? ServiceLoader.java 1174 } else if (!isAssignable(clazz, serviceName)) { 1175 fail(service, clazz.getName() + " not a subtype?); Peter raises the question on isAssignable that I think it should look at the interfaces recursively. On the other hand, I wonder if this should simply fail if service.isAssignableFrom(clazz) returns false (which I think it?s the existing JDK 8 behavior). Mandy From peter.levart at gmail.com Thu Jun 15 07:21:27 2017 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 15 Jun 2017 09:21:27 +0200 Subject: 8181087: Module system implementation refresh (6/2017 update) In-Reply-To: References: Message-ID: Re-reading my post in the morning... On 06/14/2017 11:44 PM, Peter Levart wrote: > In j.l.Module: > > There are two places in the same method that contain exactly the same > fragment of code: > > 566 if (targets.contains(EVERYONE_MODULE) || > targets.contains(other)) > 567 return true; > 568 if (other != EVERYONE_MODULE > 569 && !other.isNamed() && > targets.contains(ALL_UNNAMED_MODULE)) > 570 return true; > > Perhaps this could be factored out into separate private method which > could also be made a little more optimal (when other == > EVERYONE_MODULE and targets does not contain it, it is looked-up twice > currently). For example: > > private static boolean isIncludedIn(Module module, Set targets) { > return > targets != null && ( > targets.contains(EVERYONE_MODULE) || > !module.isNamed() && targets.contains(ALL_UNNAMED_MODULE) > || // ALL_UNNAMED_MODULE.isNamed() == false > module != EVERYONE_MODULE && module != ALL_UNNAMED_MODULE > && targets.contains(module) > ); > } ...this last method is not entirely correct. if called as isIncluded(EVERYONE_MODULE, targets) and targets does not contain EVERYONE_MODULE but it contains ALL_UNNAMED_MODULE, the method returns true, because EVERYONE_MODULE.isNamed() returns false, which is not correct I think. The correct logic would be this: private static boolean isIncludedIn(Module module, Set targets) { return targets != null && ( targets.contains(EVERYONE_MODULE) || module != EVERYONE_MODULE && !module.isNamed() && targets.contains(ALL_UNNAMED_MODULE) || // ALL_UNNAMED_MODULE.isNamed() == false module != EVERYONE_MODULE && module != ALL_UNNAMED_MODULE && targets.contains(module) ); } Regards, Peter From Alan.Bateman at oracle.com Thu Jun 15 07:22:10 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 15 Jun 2017 08:22:10 +0100 Subject: 8181087: Module system implementation refresh (6/2017 update) In-Reply-To: References: Message-ID: <08a9c60f-36a9-ba73-0f42-4ca96c0eccda@oracle.com> Thanks for looking through this. On 14/06/2017 22:44, Peter Levart wrote: > : > > ...where you use the 'reflectionFactory' field one time and > 'getReflectionFactory()' method another time. The field might not > already be initialized... Well spotted, it should be using getReflectionFactory(), not reflectionFactory. I'm not sure how that crept in. > : > > > In j.u.ServiceLoader: > > : > > ...does not return true for situations like: > > public interface A {} > public interface B extends A {} > public class C implements B {} > > isAssignable(C.class, "A") ??? > > If A is a service interface and C is its implementation class, should > C be considered a valid service provider? If yes, the method might > need some stack or queue or recursion. I think I'd prefer to just remove this completely. As you probably gathered, this is just to disambiguate error cases when Class.isAssignableFrom indicates the provider listed in META-INF/services/ is not an implementation of the service type. It's a long standing SL issue (pre-dates JDK 9) and probably not worth trying to improve this now. > > > In IllegalAccessLogger: > > Is the following method: > > 280 private void log(Class caller, String what, > Supplier msgSupplier) ... > > Invoked frequently from different threads? Might synchronization in > this method be a performance bottleneck? There are some optimizations > possible... Are you concerned about the permit case or the warn/debug case? For the permit (default) case then the logger is discarded at the first illegal access. At worse, then several threads compete (and synchronized) to be the first offender but there is no synchronization or logging after that. With the warn/debug case then someone has opt'ed in to get warnings or stack traces. If there is really bad code with continuous calls to log because of illegal reflective access then it could indeed be a bottleneck. I don't think we should be too concerned with that. Yes, it could be improved if it really is an issue so I think we should wait to see what the default setting will be in JDK 10. If it becomes "warn" then we might have to look at it again. -Alan From Alan.Bateman at oracle.com Thu Jun 15 07:34:58 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 15 Jun 2017 08:34:58 +0100 Subject: 8181087: Module system implementation refresh (6/2017 update) In-Reply-To: References: Message-ID: <206a429f-0aa7-d2dc-6bc5-831eccf4f620@oracle.com> On 15/06/2017 06:37, Mandy Chung wrote: > : > java/lang/Class.java > 2453 reflectionFactory.getExecutableSharedParameterTypes(method), > > reflectionFactory should be accessed via getReflectionFactory(). I see Peter > already comments on this. Thanks, it should be getReflectionFactory(). > > java/lang/Module.java > 901 void implAddOpensToAllUnnamed(Iterator iterator) { > 902 if (jdk.internal.misc.VM.isModuleSystemInited()) { > 903 iterator.forEachRemaining(pn -> > 904 implAddExportsOrOpens(pn, ALL_UNNAMED_MODULE, true, true)); > 905 return; > 906 } > > AFAICT this should only be called during module system initialization. > When will this method be called after initPhase 2? It's for use during startup (initPhase2) only. If called later then it works as if the module somehow reflectively opened the packages to all unnamed modules. I wouldn't object to changing it to throwing an exception (assuming that is what you are thinking) as the JDK doesn't have any use for this after initPhase2. > > jdk/internal/loader/Loader.java > 406 public Enumeration getResources(String name) throws IOException { > 407 // this loader > 408 List urls = findResourcesAsList(name); > 409 > 410 // parent loader > 411 parent.getResources(name).asIterator().forEachRemaining(urls::add); > 412 > 413 return Collections.enumeration(urls); > 414 } > > We could consider returning an Enumeration that defers finding resources > from parent class loader after iterating the local resources. Yes, this is possible but has a lot of potential issues. The new stream returning resources() methods is better for doing lazy consumption and it could override this (although still lots of potential issues, esp. when running with a security manager, concerns about context change like TCCL, etc.). > : > > ModulePath.java > 408 private static final Attributes.Name AUTOMATIC_MODULE_NAME > 409 = new Attributes.Name("Automatic-Module-Name"); > > Should this be defined in java.util.jar.Attributes.Name? As I recall, this was deliberately not included in the automatic name proposal. > > ServiceLoader.java > > 1174 } else if (!isAssignable(clazz, serviceName)) { > 1175 fail(service, clazz.getName() + " not a subtype?); > > Peter raises the question on isAssignable that I think it should look at the interfaces recursively. On the other hand, I wonder if this should simply fail if service.isAssignableFrom(clazz) returns false (which I think it?s the existing JDK 8 behavior). > Yes, I think I will remove this. -Alan. From peter.levart at gmail.com Thu Jun 15 07:40:18 2017 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 15 Jun 2017 09:40:18 +0200 Subject: 8181087: Module system implementation refresh (6/2017 update) In-Reply-To: <206a429f-0aa7-d2dc-6bc5-831eccf4f620@oracle.com> References: <206a429f-0aa7-d2dc-6bc5-831eccf4f620@oracle.com> Message-ID: <5f518013-9a97-9842-531a-d58a6a0066d4@gmail.com> Hi Alan, On 06/15/2017 09:34 AM, Alan Bateman wrote: >> 2453 reflectionFactory.getExecutableSharedParameterTypes(method), >> >> reflectionFactory should be accessed via getReflectionFactory(). I >> see Peter >> already comments on this. > Thanks, it should be getReflectionFactory(). ...and I would also introduce a local variable in getReflectionFactory() as was done recently in String.hashCode(). It might not be a problem now, but could become one in the future... Regards, Peter From Alan.Bateman at oracle.com Thu Jun 15 08:21:26 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 15 Jun 2017 09:21:26 +0100 Subject: Accessing module internals from bytecode rewriting agent In-Reply-To: References: <2099da91-fe6e-a5ed-3396-1e57284a75f1@oracle.com> <64a587a9-ec06-f0cd-f136-149b85e083d7@oracle.com> <3aef86fc-3fc2-9ff9-7be4-06d92800f0a7@oracle.com> <0e51419c-b100-8dc8-fb81-dd0b50b5177b@oracle.com> <8d225548-dadb-5b07-fcc5-4d1e37d43162@oracle.com> Message-ID: On 15/06/2017 01:00, Jeremy Manson wrote: > : > > The upshot is that, in the same way as we would have turned on the big > kill switch by default to ease the transition, we are also likely to > implement -Xbootclasspath/p to ease the transition. You might find it easier to add --patch-module to your JDK 8 build instead. It's easy to translate a sequence of `--patch-module =()*` options to one `-Xbootclasspath/p:()*`. Going the other way is not easy, esp. if -Xbootclasspath/p is called with a directory or JAR file containing classes or resources in "new" packages or where there are classes that are no longer defined to the boot class loader. -Alan From alan.bateman at oracle.com Thu Jun 15 12:24:45 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 15 Jun 2017 12:24:45 +0000 Subject: hg: jigsaw/jake/hotspot: Remove --permit-illegal-access Message-ID: <201706151224.v5FCOjsI007858@aojmv0008.oracle.com> Changeset: 6b59d482c269 Author: alanb Date: 2017-06-15 13:23 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6b59d482c269 Remove --permit-illegal-access ! src/share/vm/runtime/arguments.cpp From alan.bateman at oracle.com Thu Jun 15 12:25:02 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 15 Jun 2017 12:25:02 +0000 Subject: hg: jigsaw/jake/jdk: 3 new changesets Message-ID: <201706151225.v5FCP2eN008048@aojmv0008.oracle.com> Changeset: b9f3633bf293 Author: alanb Date: 2017-06-15 13:15 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b9f3633bf293 Review comments ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/classes/java/util/ServiceLoader.java ! src/java.base/share/classes/jdk/internal/loader/Loader.java ! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java ! test/java/lang/ModuleLayer/LayerAndLoadersTest.java Changeset: 071e7be76138 Author: alanb Date: 2017-06-15 13:16 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/071e7be76138 Fix broken link ! src/java.base/share/classes/java/lang/module/ModuleFinder.java Changeset: 9863b67ce0b1 Author: alanb Date: 2017-06-15 13:18 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9863b67ce0b1 SCL.findResources does not need to eagerly check URLs ! src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java From mandy.chung at oracle.com Thu Jun 15 14:28:33 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 15 Jun 2017 07:28:33 -0700 Subject: 8181087: Module system implementation refresh (6/2017 update) In-Reply-To: <206a429f-0aa7-d2dc-6bc5-831eccf4f620@oracle.com> References: <206a429f-0aa7-d2dc-6bc5-831eccf4f620@oracle.com> Message-ID: <20564742-43D1-4470-A413-5D84F7028FA6@oracle.com> > On Jun 15, 2017, at 12:34 AM, Alan Bateman wrote: > >> >> java/lang/Module.java >> 901 void implAddOpensToAllUnnamed(Iterator iterator) { >> 902 if (jdk.internal.misc.VM.isModuleSystemInited()) { >> 903 iterator.forEachRemaining(pn -> >> 904 implAddExportsOrOpens(pn, ALL_UNNAMED_MODULE, true, true)); >> 905 return; >> 906 } >> >> AFAICT this should only be called during module system initialization. >> When will this method be called after initPhase 2? > It's for use during startup (initPhase2) only. If called later then it works as if the module somehow reflectively opened the packages to all unnamed modules. I wouldn't object to changing it to throwing an exception (assuming that is what you are thinking) as the JDK doesn't have any use for this after initPhase2. Yes this is what I am thinking. This method should catch when it?s called which is not expected. Mandy From jeremymanson at google.com Thu Jun 15 18:31:14 2017 From: jeremymanson at google.com (Jeremy Manson) Date: Thu, 15 Jun 2017 11:31:14 -0700 Subject: Accessing module internals from bytecode rewriting agent In-Reply-To: References: <2099da91-fe6e-a5ed-3396-1e57284a75f1@oracle.com> <64a587a9-ec06-f0cd-f136-149b85e083d7@oracle.com> <3aef86fc-3fc2-9ff9-7be4-06d92800f0a7@oracle.com> <0e51419c-b100-8dc8-fb81-dd0b50b5177b@oracle.com> <8d225548-dadb-5b07-fcc5-4d1e37d43162@oracle.com> Message-ID: Hey Alan, Thanks. We'd been tossing that around in the list of possibilities, but hadn't gotten far enough to think about whether it would be easier or not. My initial thought in this general direction was to write a JVMTI agent that takes a list of JAR files as arguments. It then does two things: - Intercepts all loads of classes using the ClassFileLoadHook, checks to see if there is a class with that name in the JAR file, and, if so, uses that one instead. That way, if you try to load java.util.HashMap, it will replace the bytes the system is trying to load from rt.jar (or whatever) with the bytes from the provided JAR. - Puts those JARs into the bootclasspath using AddToBootstrapClassLoaderSearch, so that the boot class loader (or whatever) can find those packages. It has to be JVMTI instead of java.lang.instrument, of course, because many JDK classes will already be loaded if you are far enough along to use java.lang.instrument. The advantage of this approach is that it works with unmodified JDKs 6, 7, 8 and 9, and will probably work for 95%+ of the cases. In fact, I wrote a prototype in a couple of hundred LOC that seems to work just fine. Because we write our own launcher and use JEP 178 pretty pervasively, I can even just make "-Xbootclasspath/p" mean "load this JVMTI library", if I want, and still not modify the JDK. The disadvantages are that a) that ClassFileLoadHook will have to go before any other transforming agents, so that subsequent transformations aren't lost, and that b) if the user tries to get the actual bytes of the class as a resource from the classloader, those bytes will not correspond to the bytes that were loaded. Your way might be better, even if it does require local changes. Technically, there are a few folks still using Java 7 around here, which might make it somewhat more painful. Also, making -patch-module work in Javas 7 and 8 might be confusing to users who have to deal with stock JDKs (or directions that are supposed to apply to stock JDKs), but maybe that's their problem. Jeremy On Thu, Jun 15, 2017 at 1:21 AM, Alan Bateman wrote: > On 15/06/2017 01:00, Jeremy Manson wrote: > >> : >> >> The upshot is that, in the same way as we would have turned on the big >> kill switch by default to ease the transition, we are also likely to >> implement -Xbootclasspath/p to ease the transition. >> > You might find it easier to add --patch-module to your JDK 8 build > instead. It's easy to translate a sequence of `--patch-module > =()*` options to one > `-Xbootclasspath/p:()*`. Going the other way is not > easy, esp. if -Xbootclasspath/p is called with a directory or JAR file > containing classes or resources in "new" packages or where there are > classes that are no longer defined to the boot class loader. > > -Alan > From alan.bateman at oracle.com Thu Jun 15 19:16:20 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 15 Jun 2017 19:16:20 +0000 Subject: hg: jigsaw/jake/jaxws: 5 new changesets Message-ID: <201706151916.v5FJGKd6013865@aojmv0008.oracle.com> Changeset: 0d797e800441 Author: lancea Date: 2017-06-07 18:47 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/0d797e800441 8181702: Mark jdk.xml.bind and jdk.xml.ws modules deprecated and for removal Reviewed-by: alanb, mchung ! src/jdk.xml.bind/share/classes/module-info.java ! src/jdk.xml.ws/share/classes/module-info.java Changeset: e5fae34690ab Author: mchung Date: 2017-06-07 21:14 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/e5fae34690ab 8181639: Add tool and services information to module summary Reviewed-by: alanb, psandoz, lancea ! src/java.xml.bind/share/classes/module-info.java ! src/java.xml.ws/share/classes/module-info.java ! src/jdk.xml.bind/share/classes/module-info.java ! src/jdk.xml.ws/share/classes/module-info.java Changeset: c2296642010f Author: lana Date: 2017-06-08 23:11 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/c2296642010f Merge Changeset: 872236b506ff Author: lana Date: 2017-06-15 17:24 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/872236b506ff Added tag jdk-9+174 for changeset c2296642010f ! .hgtags Changeset: c799e33d157c Author: alanb Date: 2017-06-15 18:55 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/c799e33d157c Merge ! .hgtags ! src/java.xml.bind/share/classes/module-info.java ! src/java.xml.ws/share/classes/module-info.java ! src/jdk.xml.bind/share/classes/module-info.java ! src/jdk.xml.ws/share/classes/module-info.java From alan.bateman at oracle.com Thu Jun 15 19:16:20 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 15 Jun 2017 19:16:20 +0000 Subject: hg: jigsaw/jake: 5 new changesets Message-ID: <201706151916.v5FJGKAj013847@aojmv0008.oracle.com> Changeset: 577896ffb41a Author: mchung Date: 2017-06-07 21:15 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/577896ffb41a 8181639: Add tool and services information to module summary Reviewed-by: alanb, psandoz, lancea ! make/common/Modules.gmk Changeset: abe884590f03 Author: erikj Date: 2017-06-08 14:53 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/abe884590f03 8178064: OpenJDK RI binary should include the license file for freetype Reviewed-by: tbell, ihse ! common/autoconf/generated-configure.sh ! common/autoconf/lib-freetype.m4 ! common/autoconf/spec.gmk.in ! common/conf/jib-profiles.js ! make/CreateJmods.gmk Changeset: 5466f409346e Author: lana Date: 2017-06-08 23:10 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/5466f409346e Merge Changeset: 023f93e511ba Author: lana Date: 2017-06-15 17:24 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/023f93e511ba Added tag jdk-9+174 for changeset 5466f409346e ! .hgtags Changeset: 3e53d8c3178a Author: alanb Date: 2017-06-15 18:42 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/3e53d8c3178a Merge ! .hgtags ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/conf/jib-profiles.js ! make/CreateJmods.gmk ! make/common/Modules.gmk From alan.bateman at oracle.com Thu Jun 15 19:16:20 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 15 Jun 2017 19:16:20 +0000 Subject: hg: jigsaw/jake/jaxp: 4 new changesets Message-ID: <201706151916.v5FJGKTU013933@aojmv0008.oracle.com> Changeset: 0ca686e3e26b Author: mchung Date: 2017-06-07 21:08 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/0ca686e3e26b 8181639: Add tool and services information to module summary Reviewed-by: alanb, psandoz, lancea ! src/java.xml/share/classes/module-info.java Changeset: b9c0b1050022 Author: lana Date: 2017-06-08 23:11 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/b9c0b1050022 Merge Changeset: c0b8bea54e91 Author: lana Date: 2017-06-15 17:24 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/c0b8bea54e91 Added tag jdk-9+174 for changeset b9c0b1050022 ! .hgtags Changeset: 82a1571849db Author: alanb Date: 2017-06-15 18:44 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/82a1571849db Merge ! .hgtags ! src/java.xml/share/classes/module-info.java From alan.bateman at oracle.com Thu Jun 15 19:16:23 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 15 Jun 2017 19:16:23 +0000 Subject: hg: jigsaw/jake/nashorn: 4 new changesets Message-ID: <201706151916.v5FJGN21013972@aojmv0008.oracle.com> Changeset: 7b100002e7ae Author: mchung Date: 2017-06-07 18:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/7b100002e7ae 8181639: Add tool and services information to module summary Reviewed-by: alanb, psandoz, lancea ! src/jdk.dynalink/share/classes/module-info.java ! src/jdk.scripting.nashorn.shell/share/classes/module-info.java ! src/jdk.scripting.nashorn/share/classes/module-info.java Changeset: 7d4006eaa088 Author: lana Date: 2017-06-08 23:11 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/7d4006eaa088 Merge Changeset: da6134f74952 Author: lana Date: 2017-06-15 17:24 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/da6134f74952 Added tag jdk-9+174 for changeset 7d4006eaa088 ! .hgtags Changeset: a5994d2b9cff Author: alanb Date: 2017-06-15 18:55 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/a5994d2b9cff Merge ! .hgtags ! src/jdk.scripting.nashorn.shell/share/classes/module-info.java ! src/jdk.scripting.nashorn/share/classes/module-info.java From alan.bateman at oracle.com Thu Jun 15 19:16:23 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 15 Jun 2017 19:16:23 +0000 Subject: hg: jigsaw/jake/langtools: 5 new changesets Message-ID: <201706151916.v5FJGN9W013965@aojmv0008.oracle.com> Changeset: 733fb11b37d4 Author: jjg Date: 2017-06-08 15:50 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/733fb11b37d4 8180296: Move Javadoc: doclet, taglet specs to specs directory Reviewed-by: ksrini ! src/jdk.compiler/share/classes/com/sun/source/doctree/package-info.java ! src/jdk.javadoc/share/classes/jdk/javadoc/doclet/StandardDoclet.java ! src/jdk.javadoc/share/classes/module-info.java Changeset: 50c077995aa2 Author: lana Date: 2017-06-08 23:11 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/50c077995aa2 Merge Changeset: da99b31da7b5 Author: lana Date: 2017-06-15 17:24 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/da99b31da7b5 Added tag jdk-9+174 for changeset 50c077995aa2 ! .hgtags Changeset: e035894df61f Author: alanb Date: 2017-06-15 18:43 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/e035894df61f Merge ! .hgtags ! src/jdk.javadoc/share/classes/module-info.java Changeset: 8de9fe1adef1 Author: alanb Date: 2017-06-15 19:00 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/8de9fe1adef1 Merge From alan.bateman at oracle.com Thu Jun 15 19:16:25 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 15 Jun 2017 19:16:25 +0000 Subject: hg: jigsaw/jake/hotspot: 7 new changesets Message-ID: <201706151916.v5FJGPuN013982@aojmv0008.oracle.com> Changeset: bb5c32e2d31a Author: eosterlund Date: 2017-06-06 13:31 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/bb5c32e2d31a 8161145: The min/max macros make hotspot tests fail to build with GCC 6 Summary: Change min/max macros to expand (once) to self. Reviewed-by: sgehwolf, pliden, andrew ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 5242609b8088 Author: psandoz Date: 2017-06-05 15:52 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5242609b8088 8181292: Backport Rename internal Unsafe.compare methods from 10 to 9 Reviewed-by: psandoz, dholmes, thartmann, kvn Contributed-by: ron.pressler at oracle.com, claes.redestad at oracle.com ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/StandardGraphBuilderPlugins.java ! src/share/vm/c1/c1_Compiler.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/classfile/vmSymbols.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/shark/sharkIntrinsics.cpp ! src/share/vm/shark/sharkIntrinsics.hpp ! test/compiler/c2/cr8004867/TestIntUnsafeCAS.java ! test/compiler/intrinsics/unsafe/TestCAEAntiDep.java ! test/compiler/intrinsics/unsafe/UnsafeTwoCASLong.java ! test/compiler/profiling/UnsafeAccess.java ! test/compiler/unsafe/JdkInternalMiscUnsafeAccessTestBoolean.java ! test/compiler/unsafe/JdkInternalMiscUnsafeAccessTestByte.java ! test/compiler/unsafe/JdkInternalMiscUnsafeAccessTestChar.java ! test/compiler/unsafe/JdkInternalMiscUnsafeAccessTestDouble.java ! test/compiler/unsafe/JdkInternalMiscUnsafeAccessTestFloat.java ! test/compiler/unsafe/JdkInternalMiscUnsafeAccessTestInt.java ! test/compiler/unsafe/JdkInternalMiscUnsafeAccessTestLong.java ! test/compiler/unsafe/JdkInternalMiscUnsafeAccessTestObject.java ! test/compiler/unsafe/JdkInternalMiscUnsafeAccessTestShort.java ! test/compiler/unsafe/SunMiscUnsafeAccessTestBoolean.java ! test/compiler/unsafe/SunMiscUnsafeAccessTestByte.java ! test/compiler/unsafe/SunMiscUnsafeAccessTestChar.java ! test/compiler/unsafe/SunMiscUnsafeAccessTestDouble.java ! test/compiler/unsafe/SunMiscUnsafeAccessTestFloat.java ! test/compiler/unsafe/SunMiscUnsafeAccessTestInt.java ! test/compiler/unsafe/SunMiscUnsafeAccessTestLong.java ! test/compiler/unsafe/SunMiscUnsafeAccessTestObject.java ! test/compiler/unsafe/SunMiscUnsafeAccessTestShort.java ! test/compiler/unsafe/X-UnsafeAccessTest.java.template Changeset: 921359dbc96b Author: mchung Date: 2017-06-07 18:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/921359dbc96b 8181639: Add tool and services information to module summary Reviewed-by: alanb, psandoz, lancea ! src/jdk.hotspot.agent/share/classes/module-info.java Changeset: 944791f81601 Author: lana Date: 2017-06-08 23:11 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/944791f81601 Merge Changeset: ca47dcfdd351 Author: lana Date: 2017-06-15 17:24 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ca47dcfdd351 Added tag jdk-9+174 for changeset 944791f81601 ! .hgtags Changeset: 2ee01a2abc55 Author: alanb Date: 2017-06-15 18:55 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2ee01a2abc55 Merge ! .hgtags ! src/jdk.hotspot.agent/share/classes/module-info.java ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/library_call.cpp ! test/compiler/c2/cr8004867/TestIntUnsafeCAS.java ! test/compiler/intrinsics/unsafe/UnsafeTwoCASLong.java ! test/compiler/unsafe/JdkInternalMiscUnsafeAccessTestBoolean.java ! test/compiler/unsafe/JdkInternalMiscUnsafeAccessTestByte.java ! test/compiler/unsafe/JdkInternalMiscUnsafeAccessTestChar.java ! test/compiler/unsafe/JdkInternalMiscUnsafeAccessTestDouble.java ! test/compiler/unsafe/JdkInternalMiscUnsafeAccessTestFloat.java ! test/compiler/unsafe/JdkInternalMiscUnsafeAccessTestInt.java ! test/compiler/unsafe/JdkInternalMiscUnsafeAccessTestLong.java ! test/compiler/unsafe/JdkInternalMiscUnsafeAccessTestObject.java ! test/compiler/unsafe/JdkInternalMiscUnsafeAccessTestShort.java Changeset: bc3d2b52debd Author: alanb Date: 2017-06-15 19:00 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/bc3d2b52debd Merge From alan.bateman at oracle.com Thu Jun 15 19:16:27 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 15 Jun 2017 19:16:27 +0000 Subject: hg: jigsaw/jake/jdk: 22 new changesets Message-ID: <201706151916.v5FJGS4S013987@aojmv0008.oracle.com> Changeset: ffa11326afd5 Author: psandoz Date: 2017-06-05 16:05 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ffa11326afd5 8181292: Backport Rename internal Unsafe.compare methods from 10 to 9 Reviewed-by: psandoz, dholmes, mchung Contributed-by: ron.pressler at oracle.com ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/java/lang/invoke/X-VarHandle.java.template ! src/java.base/share/classes/java/lang/invoke/X-VarHandleByteArrayView.java.template ! src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java ! src/java.base/share/classes/java/util/concurrent/atomic/AtomicInteger.java ! src/java.base/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java ! src/java.base/share/classes/java/util/concurrent/atomic/AtomicLong.java ! src/java.base/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java ! src/java.base/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java ! src/java.base/share/classes/jdk/internal/misc/Unsafe.java ! src/jdk.unsupported/share/classes/sun/misc/Unsafe.java Changeset: 915b8df0afbb Author: weijun Date: 2017-06-07 10:03 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/915b8df0afbb 8181461: sun/security/krb5/auto/KdcPolicy.java fails with java.lang.Exception: Does not match Reviewed-by: xuelei ! test/sun/security/krb5/auto/KdcPolicy.java Changeset: e4a4f89bbca3 Author: alitvinov Date: 2017-06-02 18:40 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e4a4f89bbca3 8181192: [macos] javafx.print.PrinterJob.showPrintDialog() hangs on macOS Reviewed-by: prr, serb ! src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m ! src/java.desktop/share/classes/sun/print/RasterPrinterJob.java ! test/java/awt/print/PageFormat/WrongPaperPrintingTest.java Changeset: 80aecb2f0ac7 Author: prr Date: 2017-06-05 11:00 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/80aecb2f0ac7 Merge - src/java.base/share/classes/overview-core.html - test/java/util/ResourceBundle/modules/appbasic/src/test/jdk/test/resources/MyResourcesProvider.java - test/java/util/ResourceBundle/modules/appbasic2/src/test/jdk/test/resources/MyResourcesProvider.java - test/java/util/ResourceBundle/modules/basic/src/mainbundles/jdk/test/resources/MyResourcesProvider.java - test/java/util/ResourceBundle/modules/simple/src/bundles/jdk/test/resources/MyResourcesProvider.java - test/java/util/ResourceBundle/modules/visibility/src/exported.named.bundles/jdk/test/resources/exported/classes/MyResourcesProvider.java - test/java/util/ResourceBundle/modules/visibility/src/named.bundles/jdk/test/resources/classes/MyResourcesProvider.java - test/java/util/ResourceBundle/modules/visibility/src/named.bundles/jdk/test/resources/props/MyResourcesProvider.java - test/java/util/ResourceBundle/modules/xmlformat/src/bundles/jdk/test/resources/MyResourcesProvider.java Changeset: 510301a824d4 Author: psadhukhan Date: 2017-06-06 11:11 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/510301a824d4 8181401: Error in Javadoc for JTabbedPane getAccessibleName() Reviewed-by: serb, ssadetsky ! src/java.desktop/share/classes/javax/swing/JTabbedPane.java Changeset: e7ede182f86f Author: psadhukhan Date: 2017-06-06 11:56 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e7ede182f86f 8181640: Spelling mistake in javadoc javax.swing.JEditorPane.scrollToReference(String) Reviewed-by: serb ! src/java.desktop/share/classes/javax/swing/JEditorPane.java Changeset: 92d4889c9b57 Author: mhalder Date: 2017-06-06 14:38 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/92d4889c9b57 8172510: This test fails for me on OS X consistently with result: Expected : 01230123 Actual : 001122303011223 Reviewed-by: serb, prr Contributed-by: manajit.halder at oracle.com ! test/java/awt/List/ItemEventTest/ItemEventTest.java Changeset: ed1e99c1bba2 Author: prr Date: 2017-06-07 06:45 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ed1e99c1bba2 Merge Changeset: 67ad6b89dd96 Author: lancea Date: 2017-06-07 15:05 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/67ad6b89dd96 8181195: Mark java.se.ee aggregator module deprecated and for removal Reviewed-by: joehw, alanb, mchung ! src/java.se.ee/share/classes/module-info.java Changeset: 4ecceb2dcc01 Author: mchung Date: 2017-06-07 18:54 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4ecceb2dcc01 8181696: Package versioning link does not exist in JAR file specification Reviewed-by: alanb ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/java/lang/Package.java Changeset: 0f734ac5ddb1 Author: mchung Date: 2017-06-07 21:15 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0f734ac5ddb1 8181639: Add tool and services information to module summary Reviewed-by: alanb, psandoz, lancea ! make/src/classes/build/tools/docs/docs-module-groups.properties ! src/java.base/share/classes/module-info.java ! src/java.desktop/share/classes/module-info.java ! src/java.management.rmi/share/classes/module-info.java ! src/java.management/share/classes/module-info.java ! src/java.prefs/share/classes/module-info.java ! src/java.rmi/share/classes/module-info.java ! src/java.scripting/share/classes/module-info.java ! src/java.se/share/classes/module-info.java ! src/java.sql.rowset/share/classes/module-info.java ! src/java.sql/share/classes/module-info.java ! src/jdk.attach/share/classes/module-info.java ! src/jdk.charsets/share/classes/module-info.java ! src/jdk.crypto.cryptoki/share/classes/module-info.java ! src/jdk.crypto.ec/share/classes/module-info.java ! src/jdk.crypto.mscapi/windows/classes/module-info.java ! src/jdk.crypto.ucrypto/solaris/classes/module-info.java ! src/jdk.editpad/share/classes/module-info.java ! src/jdk.httpserver/share/classes/module-info.java ! src/jdk.jartool/share/classes/module-info.java ! src/jdk.jcmd/share/classes/module-info.java ! src/jdk.jconsole/share/classes/module-info.java ! src/jdk.jdi/share/classes/module-info.java ! src/jdk.jdwp.agent/share/classes/module-info.java ! src/jdk.jlink/share/classes/module-info.java ! src/jdk.jstatd/share/classes/module-info.java ! src/jdk.localedata/share/classes/module-info.java ! src/jdk.management.agent/share/classes/module-info.java ! src/jdk.naming.dns/share/classes/module-info.java ! src/jdk.naming.rmi/share/classes/module-info.java ! src/jdk.pack/share/classes/module-info.java ! src/jdk.policytool/share/classes/module-info.java ! src/jdk.rmic/share/classes/module-info.java ! src/jdk.security.auth/share/classes/module-info.java ! src/jdk.zipfs/share/classes/module-info.java Changeset: 2637d816e17a Author: ihse Date: 2017-06-08 11:24 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2637d816e17a 8181776: Move back specs to closed Reviewed-by: erikj - src/java.base/share/specs/serialization/class.md - src/java.base/share/specs/serialization/examples.md - src/java.base/share/specs/serialization/exceptions.md - src/java.base/share/specs/serialization/images/version.gif - src/java.base/share/specs/serialization/index.md - src/java.base/share/specs/serialization/input.md - src/java.base/share/specs/serialization/output.md - src/java.base/share/specs/serialization/protocol.md - src/java.base/share/specs/serialization/security.md - src/java.base/share/specs/serialization/serial-arch.md - src/java.base/share/specs/serialization/version.md - src/java.desktop/share/specs/AWT_Native_Interface.html - src/java.management/share/specs/JVM-MANAGEMENT-MIB.mib Changeset: 4287c7853433 Author: dfuchs Date: 2017-06-08 12:24 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4287c7853433 8181430: HTTP/2 client might deadlock when receiving data during the initial handshake Summary: CountDownLatch removed. Data produced during the handshake is instead buffered until the preface is sent. Reviewed-by: michaelm, msheppar, prappo ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/Http2Connection.java Changeset: ea0146845b79 Author: dfuchs Date: 2017-06-08 12:41 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ea0146845b79 8180044: java/net/httpclient/ManyRequests.java failed due to timeout Summary: Fixes several race conditions observed while testing. Reviewed-by: michaelm, msheppar, prappo ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/HttpClientImpl.java ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/PlainHttpConnection.java ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/Stream.java ! test/com/sun/net/httpserver/FileServerHandler.java ! test/java/net/httpclient/ManyRequests.java + test/java/net/httpclient/ManyRequests2.java Changeset: 3abaf7610609 Author: ihse Date: 2017-06-08 13:49 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3abaf7610609 8180300: Move JDWP specs to specs directory Reviewed-by: sspitsyn ! src/jdk.jdi/share/classes/com/sun/jdi/connect/spi/Connection.java ! src/jdk.jdi/share/classes/com/sun/jdi/connect/spi/TransportService.java Changeset: 890af73c1fe4 Author: erikj Date: 2017-06-08 14:53 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/890af73c1fe4 8178064: OpenJDK RI binary should include the license file for freetype Reviewed-by: tbell, ihse ! make/copy/Copy-java.desktop.gmk Changeset: 9a344811dba9 Author: lana Date: 2017-06-08 23:11 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9a344811dba9 Merge - src/java.base/share/specs/serialization/class.md - src/java.base/share/specs/serialization/examples.md - src/java.base/share/specs/serialization/exceptions.md - src/java.base/share/specs/serialization/images/version.gif - src/java.base/share/specs/serialization/index.md - src/java.base/share/specs/serialization/input.md - src/java.base/share/specs/serialization/output.md - src/java.base/share/specs/serialization/protocol.md - src/java.base/share/specs/serialization/security.md - src/java.base/share/specs/serialization/serial-arch.md - src/java.base/share/specs/serialization/version.md - src/java.desktop/share/specs/AWT_Native_Interface.html - src/java.management/share/specs/JVM-MANAGEMENT-MIB.mib Changeset: 78c003bd010f Author: dfuchs Date: 2017-06-09 16:52 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/78c003bd010f 8181867: [tests] Reorganize EchoHandlers Summary: This fix reorganize some test files and rename some test classes. Several classes named EchoHandler in the unnamed package are renamed to make it clear what classes (and sources) tests that use these EchoHandler implementations effectively depend on. Reviewed-by: chegar + test/com/sun/net/httpserver/EchoHandler.java ! test/com/sun/net/httpserver/FileServerHandler.java + test/com/sun/net/httpserver/SimpleFileServer.java + test/java/net/httpclient/HttpEchoHandler.java ! test/java/net/httpclient/LightWeightHttpServer.java ! test/java/net/httpclient/ManyRequests.java ! test/java/net/httpclient/ManyRequests2.java ! test/java/net/httpclient/RequestBodyTest.java ! test/java/net/httpclient/SmokeTest.java ! test/java/net/httpclient/http2/BasicTest.java ! test/java/net/httpclient/http2/ErrorTest.java ! test/java/net/httpclient/http2/FixedThreadPoolTest.java ! test/java/net/httpclient/http2/RedirectTest.java + test/java/net/httpclient/http2/server/Http2EchoHandler.java Changeset: 42f18c931bd4 Author: psandoz Date: 2017-06-09 11:26 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/42f18c931bd4 8181824: Broken javadoc link in java.util.BitSet Reviewed-by: martin ! src/java.base/share/classes/java/util/BitSet.java Changeset: c31ac0b8a60e Author: lana Date: 2017-06-15 17:24 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c31ac0b8a60e Added tag jdk-9+174 for changeset 42f18c931bd4 ! .hgtags Changeset: c995af6b0907 Author: alanb Date: 2017-06-15 18:43 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c995af6b0907 Merge ! .hgtags ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/java/lang/Package.java ! src/java.base/share/classes/module-info.java - src/java.base/share/specs/serialization/class.md - src/java.base/share/specs/serialization/examples.md - src/java.base/share/specs/serialization/exceptions.md - src/java.base/share/specs/serialization/images/version.gif - src/java.base/share/specs/serialization/index.md - src/java.base/share/specs/serialization/input.md - src/java.base/share/specs/serialization/output.md - src/java.base/share/specs/serialization/protocol.md - src/java.base/share/specs/serialization/security.md - src/java.base/share/specs/serialization/serial-arch.md - src/java.base/share/specs/serialization/version.md ! src/java.desktop/share/classes/javax/swing/JEditorPane.java ! src/java.desktop/share/classes/module-info.java - src/java.desktop/share/specs/AWT_Native_Interface.html ! src/java.management/share/classes/module-info.java - src/java.management/share/specs/JVM-MANAGEMENT-MIB.mib ! src/java.prefs/share/classes/module-info.java ! src/java.rmi/share/classes/module-info.java ! src/java.scripting/share/classes/module-info.java ! src/java.se.ee/share/classes/module-info.java ! src/java.se/share/classes/module-info.java ! src/java.sql.rowset/share/classes/module-info.java ! src/java.sql/share/classes/module-info.java ! src/jdk.attach/share/classes/module-info.java ! src/jdk.charsets/share/classes/module-info.java ! src/jdk.crypto.cryptoki/share/classes/module-info.java ! src/jdk.crypto.ec/share/classes/module-info.java ! src/jdk.crypto.mscapi/windows/classes/module-info.java ! src/jdk.crypto.ucrypto/solaris/classes/module-info.java ! src/jdk.httpserver/share/classes/module-info.java ! src/jdk.jartool/share/classes/module-info.java ! src/jdk.jcmd/share/classes/module-info.java ! src/jdk.jconsole/share/classes/module-info.java ! src/jdk.jdi/share/classes/module-info.java ! src/jdk.jdwp.agent/share/classes/module-info.java ! src/jdk.jlink/share/classes/module-info.java ! src/jdk.localedata/share/classes/module-info.java ! src/jdk.naming.dns/share/classes/module-info.java ! src/jdk.naming.rmi/share/classes/module-info.java ! src/jdk.pack/share/classes/module-info.java ! src/jdk.policytool/share/classes/module-info.java ! src/jdk.rmic/share/classes/module-info.java ! src/jdk.security.auth/share/classes/module-info.java ! src/jdk.zipfs/share/classes/module-info.java Changeset: 9a5c4208130d Author: alanb Date: 2017-06-15 19:00 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9a5c4208130d Merge ! src/java.base/share/classes/java/lang/Class.java - src/java.instrument/share/classes/java/lang/instrument/package.html From alan.bateman at oracle.com Thu Jun 15 19:19:28 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 15 Jun 2017 19:19:28 +0000 Subject: hg: jigsaw/jake/corba: 2 new changesets Message-ID: <201706151919.v5FJJSVW016020@aojmv0008.oracle.com> Changeset: 6a33ed672191 Author: lana Date: 2017-06-15 17:24 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/6a33ed672191 Added tag jdk-9+174 for changeset 3615768c1290 ! .hgtags Changeset: 2b5fa3512f1f Author: alanb Date: 2017-06-15 20:18 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/2b5fa3512f1f Merge ! .hgtags From pepper at gradle.com Fri Jun 16 04:07:54 2017 From: pepper at gradle.com (Pepper Lebeck-Jobe) Date: Fri, 16 Jun 2017 04:07:54 +0000 Subject: Explicitly empty sourcepath regression Message-ID: I'll start with a question, and then give an opinion. *Question* Why must the source files which make up a module be on the source path for the module to be compiled? *Opinion* Build tools, especially Gradle, attempt to make reproducible builds a reality. One thing these tools offer is fine-grained control over the set of java files which will be passed to javac for compilation. Historically, we have even explicitly set the `-sourcepath` to be empty to tell the compiler not to look for source files on the classpath or in the current working directory. Combining this with an exact specification of which java files should be compiled supports a few important use cases: 1. You can exclude experimental sources (not yet ready to compile) easily to unblock local development without fear that they will break the build. 2. You can set up build logic to dynamically include or exclude specific files without having to copy those files around to various directories which are or are not on the source path, so that you can produce different variations of a library from the original sources. We feel that having to isolate the files which make up a module into directories on the `-sourcepath` would limit the flexibility of the build system, and, possibly hurt reproducibility of the builds. *Reproduction* In case anyone on the list doesn't understand what I mean when I say that module source files are required to be on the source path, I've created a tiny GitHub repo , with instructions on reproducing what I'm seeing. Thanks for your consideration, Pepper [image: Email-Signature at 2x.png] Pepper Lebeck-Jobe Principal Engineer Gradle Inc. P. +1 (919) 439-7557 <(919)%20439-7557> W. gradle.com Gradle Summit is now open Click HERE to register From sven.reimers at gmail.com Fri Jun 16 05:54:15 2017 From: sven.reimers at gmail.com (Sven Reimers) Date: Fri, 16 Jun 2017 07:54:15 +0200 Subject: Incompatible change to java.lang.instrument.Instrumentation Message-ID: Hi all, as part of the process of the code donation from Oracle to Apache for NetBeans I tried a compilation of the source code using idk 9-ea+173. The compilation fails due to an added method boolean isModifiableModule(Module) in java.lang.instrument.Instrumentation. Should the newly added method on the interface Instrumentation have a default implementation to make this change source code compatible from 8 to 9, e.g. default boolean isModifiableModule(Module module) { return false; } Is it already to late for changing this before JDK 9 release? Thanks for considering Sven -- Sven Reimers * Senior Expert Software Architect * Java Champion * NetBeans Dream Team Member: http://dreamteam.netbeans.org * JUG Leader JUG Bodensee: http://www.jug-bodensee.de * Duke's Choice Award Winner 2009 * XING: https://www.xing.com/profile/Sven_Reimers8 * LinkedIn: http://www.linkedin.com/in/svenreimers From Alan.Bateman at oracle.com Fri Jun 16 06:11:49 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 16 Jun 2017 07:11:49 +0100 Subject: Incompatible change to java.lang.instrument.Instrumentation In-Reply-To: References: Message-ID: <34d81995-cafa-ef80-7dca-d2aef328ba23@oracle.com> On 16/06/2017 06:54, Sven Reimers wrote: > Hi all, > > as part of the process of the code donation from Oracle to Apache for > NetBeans I tried a compilation of the source code using idk 9-ea+173. The > compilation fails due to an added method boolean isModifiableModule(Module) > in java.lang.instrument.Instrumentation. > > Should the newly added method on the interface Instrumentation have a > default implementation to make this change source code compatible from 8 to > 9, e.g. > > default boolean isModifiableModule(Module module) { > > return false; > > } > > > Is it already to late for changing this before JDK 9 release? > You are correct that adding abstract methods to Instrumentation is an incompatible change but the long term assumption in this area has always been it wouldn't be implemented outside of the java.instrument module. There were 4 abstract methods added to it in Java SE 6 and I don't recall anyone screaming (pre-dates default methods of course). So can you say what NetBeans is doing? Is this mocking, maybe forwarding/intercepting? If there is a compelling reasons then we could try to see about changing redefineModule and the other new methods to be default methods but it is late and there is more to this that changing them to be default methods. -Alan From sven.reimers at gmail.com Fri Jun 16 06:17:51 2017 From: sven.reimers at gmail.com (Sven Reimers) Date: Fri, 16 Jun 2017 08:17:51 +0200 Subject: Incompatible change to java.lang.instrument.Instrumentation In-Reply-To: <34d81995-cafa-ef80-7dca-d2aef328ba23@oracle.com> References: <34d81995-cafa-ef80-7dca-d2aef328ba23@oracle.com> Message-ID: Hi Alan, the code in question I am looking at is in o.n.bootstrap/src/org/netbeans/NbInstrumentation.java So this looks more like some basic stuff baked deep into NetBeans core... cc'Ing Jaroslav Tulach who wrote this - he should have some more details.. else I will try to figure this out. Thanks for looking into this Sven On Fri, Jun 16, 2017 at 8:11 AM, Alan Bateman wrote: > On 16/06/2017 06:54, Sven Reimers wrote: > >> Hi all, >> >> as part of the process of the code donation from Oracle to Apache for >> NetBeans I tried a compilation of the source code using idk 9-ea+173. The >> compilation fails due to an added method boolean >> isModifiableModule(Module) >> in java.lang.instrument.Instrumentation. >> >> Should the newly added method on the interface Instrumentation have a >> default implementation to make this change source code compatible from 8 >> to >> 9, e.g. >> >> default boolean isModifiableModule(Module module) { >> >> return false; >> >> } >> >> >> Is it already to late for changing this before JDK 9 release? >> >> You are correct that adding abstract methods to Instrumentation is an > incompatible change but the long term assumption in this area has always > been it wouldn't be implemented outside of the java.instrument module. > There were 4 abstract methods added to it in Java SE 6 and I don't recall > anyone screaming (pre-dates default methods of course). > > So can you say what NetBeans is doing? Is this mocking, maybe > forwarding/intercepting? If there is a compelling reasons then we could try > to see about changing redefineModule and the other new methods to be > default methods but it is late and there is more to this that changing them > to be default methods. > > -Alan > > -- Sven Reimers * Senior Expert Software Architect * Java Champion * NetBeans Dream Team Member: http://dreamteam.netbeans.org * Community Leader NetBeans: http://community.java.net/netbeans Desktop Java: http://community.java.net/javadesktop * JUG Leader JUG Bodensee: http://www.jug-bodensee.de * Duke's Choice Award Winner 2009 * XING: https://www.xing.com/profile/Sven_Reimers8 * LinkedIn: http://www.linkedin.com/in/svenreimers From Alan.Bateman at oracle.com Fri Jun 16 06:50:07 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 16 Jun 2017 07:50:07 +0100 Subject: Explicitly empty sourcepath regression In-Reply-To: References: Message-ID: <3143a037-09e8-7fb1-b8a4-7c25063b01da@oracle.com> On 16/06/2017 05:07, Pepper Lebeck-Jobe wrote: > I'll start with a question, and then give an opinion. > > *Question* > Why must the source files which make up a module be on the source path for > the module to be compiled? > > *Opinion* > Build tools, especially Gradle, attempt to make reproducible builds a > reality. One thing these tools offer is fine-grained control over the set > of java files which will be passed to javac for compilation. Historically, > we have even explicitly set the `-sourcepath` to be empty to tell the > compiler not to look for source files on the classpath or in the current > working directory. Combining this with an exact specification of which java > files should be compiled supports a few important use cases: > > 1. You can exclude experimental sources (not yet ready to compile) > easily to unblock local development without fear that they will break the > build. > 2. You can set up build logic to dynamically include or exclude specific > files without having to copy those files around to various directories > which are or are not on the source path, so that you can produce different > variations of a library from the original sources. > > We feel that having to isolate the files which make up a module into > directories on the `-sourcepath` would limit the flexibility of the build > system, and, possibly hurt reproducibility of the builds. > > *Reproduction* > In case anyone on the list doesn't understand what I mean when I say that > module source files are required to be on the source path, I've created a > tiny GitHub repo , > with instructions on reproducing what I'm seeing. > Jon or Jan might want to comment on this but there does appear to be a corner case in javac when none of the paths specified to -sourcepath exist and the source to compile includes a module-info.java. That said, the javac command looks fishy and not clear why -cp and -sourcepath are specified when compiling the module. Are these just inherited from existing build code that hasn't been updated for modules? Have you looked at using -implicit:none rather than setting using empty paths? -Alan From pepper at gradle.com Fri Jun 16 07:34:14 2017 From: pepper at gradle.com (Pepper Lebeck-Jobe) Date: Fri, 16 Jun 2017 07:34:14 +0000 Subject: Explicitly empty sourcepath regression In-Reply-To: <3143a037-09e8-7fb1-b8a4-7c25063b01da@oracle.com> References: <3143a037-09e8-7fb1-b8a4-7c25063b01da@oracle.com> Message-ID: On Fri, Jun 16, 2017 at 2:49 PM Alan Bateman wrote: > On 16/06/2017 05:07, Pepper Lebeck-Jobe wrote: > > I'll start with a question, and then give an opinion. > > > > *Question* > > Why must the source files which make up a module be on the source path > for > > the module to be compiled? > > > > *Opinion* > > Build tools, especially Gradle, attempt to make reproducible builds a > > reality. One thing these tools offer is fine-grained control over the set > > of java files which will be passed to javac for compilation. > Historically, > > we have even explicitly set the `-sourcepath` to be empty to tell the > > compiler not to look for source files on the classpath or in the current > > working directory. Combining this with an exact specification of which > java > > files should be compiled supports a few important use cases: > > > > 1. You can exclude experimental sources (not yet ready to compile) > > easily to unblock local development without fear that they will > break the > > build. > > 2. You can set up build logic to dynamically include or exclude > specific > > files without having to copy those files around to various > directories > > which are or are not on the source path, so that you can produce > different > > variations of a library from the original sources. > > > > We feel that having to isolate the files which make up a module into > > directories on the `-sourcepath` would limit the flexibility of the build > > system, and, possibly hurt reproducibility of the builds. > > > > *Reproduction* > > In case anyone on the list doesn't understand what I mean when I say that > > module source files are required to be on the source path, I've created a > > tiny GitHub repo < > https://github.com/eljobe/modules/blob/master/README.md>, > > with instructions on reproducing what I'm seeing. > > > Jon or Jan might want to comment on this but there does appear to be a > corner case in javac when none of the paths specified to -sourcepath > exist and the source to compile includes a module-info.java. > > That said, the javac command looks fishy and not clear why -cp and > -sourcepath are specified when compiling the module. Are these just > inherited from existing build code that hasn't been updated for modules? > Not exactly. Let me take them each in turn. The reason I explicitly "unset CLASSPATH" and "-cp ''" in the "bin/worksJ9.sh" script is because the documentation says that when "-sourcepath" isn't specified the class path will be searched for source files and that when "-cp" is not specified, the default value for the classpath is the current working directory. We consider it too "fast and loose" to coincidentally include source files which are in the current working directory and want to ensure that the only files seen by the compiler are the ones we explicitly pass it by fully qualified filesystem paths. That way, those complete set of reachable source files have to be included among the specified inputs to the task we are running, and we can use that specified set to calculate whether or not there have been changes in those files since the previous run of the build and avoid calling javac at all if we know none of the inputs have changed. I'll put it another way. Suppose, we didn't explicitly empty the sourcepath, and there was a source file in the current working directory (say, "Parent.java") which was needed for compiling one of the sources we explicitly passed to javac (say, "Child.java"). The first time we run the build, it would succeed. But, then, suppose someone changes "Parent.java" and runs the build again. Since only "Child.java" is explicitly known to us, and we know that the source file has not changed since we last ran the task, we will incorrectly skip running the task again. I say, "incorrectly" because the result would be a successful build, but the user would be confused as to why the changes to "Parent.java" weren't being picked up by the build. I only left "-cp ''" in "bin/failsJ9.sh" to show that I didn't change anything between the two invocations except for explicitly setting the "-sourcepath" to be empty. In fact, given the documentation that when "-sourcepath" is not set the classpath will be searched for sources, I actually don't understand why the same failure isn't happening without explicitly setting "-sourcepath". Whatever rule is being violated by not having the source files on the source path when compiling the module, should logically be violated as well when the source path == the classpath as both are set to the same empty path string. > Have you looked at using -implicit:none rather than setting using empty > paths? > If I understand the documentation of that option correctly, then it doesn't alter the scenario described above. Essentially, it would change whether or not "Parent.class" was generated during the original execution of the "javac" command, but we still wouldn't know to watch "Parent.java" for changes so we could know to recompile. > -Alan > Thanks for the timely response. From jaroslav.tulach at oracle.com Fri Jun 16 07:40:20 2017 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Fri, 16 Jun 2017 09:40:20 +0200 Subject: Incompatible change to java.lang.instrument.Instrumentation In-Reply-To: References: <34d81995-cafa-ef80-7dca-d2aef328ba23@oracle.com> Message-ID: <5676138.LCMvjuLTuO@pracovni> On p?tek 16. ?ervna 2017 8:17:51 CEST Sven Reimers wrote: > Hi Alan, > > the code in question I am looking at is in > > o.n.bootstrap/src/org/netbeans/NbInstrumentation.java > > So this looks more like some basic stuff baked deep into NetBeans core... > > cc'Ing Jaroslav Tulach who wrote this - he should have some more details.. > else I will try to figure this out. > > Thanks for looking into this > > Sven > > > On Fri, Jun 16, 2017 at 8:11 AM, Alan Bateman > > wrote: > > On 16/06/2017 06:54, Sven Reimers wrote: > >> Hi all, > >> > >> as part of the process of the code donation from Oracle to Apache for > >> NetBeans I tried a compilation of the source code using idk 9-ea+173. The > >> compilation fails due to an added method boolean > >> isModifiableModule(Module) > >> in java.lang.instrument.Instrumentation. > >> > >> Should the newly added method on the interface Instrumentation have a > >> default implementation to make this change source code compatible from 8 > >> to > >> 9, e.g. > >> > >> default boolean isModifiableModule(Module module) { > >> > >> return false; > >> > >> } > >> > >> > >> Is it already to late for changing this before JDK 9 release? > >> > >> You are correct that adding abstract methods to Instrumentation is an > > > > incompatible change but the long term assumption in this area has always > > been it wouldn't be implemented outside of the java.instrument module. > > There were 4 abstract methods added to it in Java SE 6 and I don't recall > > anyone screaming (pre-dates default methods of course). Looks like I have implemented the code when compiling against JDK7. > > So can you say what NetBeans is doing? Is this mocking, maybe > > forwarding/intercepting? See https://netbeans.org/bugzilla/show_bug.cgi?id=237919 > > If there is a compelling reasons then we could > > try > > to see about changing redefineModule and the other new methods to be > > default methods but it is late and there is more to this that changing > > them > > to be default methods. -jt From Alan.Bateman at oracle.com Fri Jun 16 08:13:27 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 16 Jun 2017 09:13:27 +0100 Subject: Incompatible change to java.lang.instrument.Instrumentation In-Reply-To: <5676138.LCMvjuLTuO@pracovni> References: <34d81995-cafa-ef80-7dca-d2aef328ba23@oracle.com> <5676138.LCMvjuLTuO@pracovni> Message-ID: <85495f8d-1f0d-1349-00dd-249a89881876@oracle.com> On 16/06/2017 08:40, Jaroslav Tulach wrote: > : >>> So can you say what NetBeans is doing? Is this mocking, maybe >>> forwarding/intercepting? > See https://netbeans.org/bugzilla/show_bug.cgi?id=237919 > If I read this correctly then NBInstrumentation is only interested in the addTransformer methods. If non-test code expecting an Instrumentation object gets a reference to the NBInstrumentation implementation then it will deeply disappointed when it finds that methods such as getObjectSize, appendToBootstrapClassLoaderSearch, etc. don't implement the spec. If it wrapped or forwarded to a "real" Instrumentation object then it might be more compelling. However point taken and we'll have to see whether it makes sense to make these default implementations (which has spec implications so I can't guarantee that this can be done at this late stage in JDK 9). -Alan From peter.levart at gmail.com Fri Jun 16 08:21:08 2017 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 16 Jun 2017 10:21:08 +0200 Subject: Incompatible change to java.lang.instrument.Instrumentation In-Reply-To: <5676138.LCMvjuLTuO@pracovni> References: <34d81995-cafa-ef80-7dca-d2aef328ba23@oracle.com> <5676138.LCMvjuLTuO@pracovni> Message-ID: <02ebaf55-330c-d066-caff-46b699cbe855@gmail.com> Hi Sven, Just an idea... What NetBeans could probably do is to create a special sub-interface of java.lang.instrument.Instrumentation in its bootstrap jar file (the jar passed to class-path) and make that jar file MR jar with two versions of say org.netbeans.core.Instrumentation interfaces extending java.lang.instrument.Instrumentation. The one for pre-9 JDK would have an empty body while the one for JDK 9 would override the newly introduced abstract methods with default implementations. NetBeans implementation classes would then implement org.netbeans.core.Instrumentation instead of java.lang.instrument.Instrumentation. Regards, Peter On 06/16/2017 09:40 AM, Jaroslav Tulach wrote: > On p?tek 16. ?ervna 2017 8:17:51 CEST Sven Reimers wrote: >> Hi Alan, >> >> the code in question I am looking at is in >> >> o.n.bootstrap/src/org/netbeans/NbInstrumentation.java >> >> So this looks more like some basic stuff baked deep into NetBeans core... >> >> cc'Ing Jaroslav Tulach who wrote this - he should have some more details.. >> else I will try to figure this out. >> >> Thanks for looking into this >> >> Sven >> >> >> On Fri, Jun 16, 2017 at 8:11 AM, Alan Bateman >> >> wrote: >>> On 16/06/2017 06:54, Sven Reimers wrote: >>>> Hi all, >>>> >>>> as part of the process of the code donation from Oracle to Apache for >>>> NetBeans I tried a compilation of the source code using idk 9-ea+173. The >>>> compilation fails due to an added method boolean >>>> isModifiableModule(Module) >>>> in java.lang.instrument.Instrumentation. >>>> >>>> Should the newly added method on the interface Instrumentation have a >>>> default implementation to make this change source code compatible from 8 >>>> to >>>> 9, e.g. >>>> >>>> default boolean isModifiableModule(Module module) { >>>> >>>> return false; >>>> >>>> } >>>> >>>> >>>> Is it already to late for changing this before JDK 9 release? >>>> >>>> You are correct that adding abstract methods to Instrumentation is an >>> incompatible change but the long term assumption in this area has always >>> been it wouldn't be implemented outside of the java.instrument module. >>> There were 4 abstract methods added to it in Java SE 6 and I don't recall >>> anyone screaming (pre-dates default methods of course). > Looks like I have implemented the code when compiling against JDK7. > >>> So can you say what NetBeans is doing? Is this mocking, maybe >>> forwarding/intercepting? > See https://netbeans.org/bugzilla/show_bug.cgi?id=237919 > >>> If there is a compelling reasons then we could >>> try >>> to see about changing redefineModule and the other new methods to be >>> default methods but it is late and there is more to this that changing >>> them >>> to be default methods. > -jt > From sven.reimers at gmail.com Fri Jun 16 09:08:31 2017 From: sven.reimers at gmail.com (Sven Reimers) Date: Fri, 16 Jun 2017 11:08:31 +0200 Subject: Incompatible change to java.lang.instrument.Instrumentation In-Reply-To: <02ebaf55-330c-d066-caff-46b699cbe855@gmail.com> References: <34d81995-cafa-ef80-7dca-d2aef328ba23@oracle.com> <5676138.LCMvjuLTuO@pracovni> <02ebaf55-330c-d066-caff-46b699cbe855@gmail.com> Message-ID: Hi Peter, nice idea. The only drawback is this requires JDK 9 for a build. What I wanted to check is if I can compile the same unchanged source tree with JDK 8 and 9... Since there is not yet a hard requirement for JDK 9 compilation, i.e. this is just an experiment to figure out things that may be broken and need work, I would not see any actions on NetBeans side at the moment. I was just astonished about the breaking change naively assuming that default methods should be an easy fix. Thanks for the hint, waiting what Alan comes up with in the meantime (probably more projects could be hit by the problem) @Alan: Shall I file a bug? Thanks for the fast responses Sven On Fri, Jun 16, 2017 at 10:21 AM, Peter Levart wrote: > Hi Sven, > > Just an idea... > > What NetBeans could probably do is to create a special sub-interface of > java.lang.instrument.Instrumentation in its bootstrap jar file (the jar > passed to class-path) and make that jar file MR jar with two versions of > say org.netbeans.core.Instrumentation interfaces extending > java.lang.instrument.Instrumentation. The one for pre-9 JDK would have an > empty body while the one for JDK 9 would override the newly introduced > abstract methods with default implementations. NetBeans implementation > classes would then implement org.netbeans.core.Instrumentation instead of > java.lang.instrument.Instrumentation. > > Regards, Peter > > > On 06/16/2017 09:40 AM, Jaroslav Tulach wrote: > >> On p?tek 16. ?ervna 2017 8:17:51 CEST Sven Reimers wrote: >> >>> Hi Alan, >>> >>> the code in question I am looking at is in >>> >>> o.n.bootstrap/src/org/netbeans/NbInstrumentation.java >>> >>> So this looks more like some basic stuff baked deep into NetBeans core... >>> >>> cc'Ing Jaroslav Tulach who wrote this - he should have some more >>> details.. >>> else I will try to figure this out. >>> >>> Thanks for looking into this >>> >>> Sven >>> >>> >>> On Fri, Jun 16, 2017 at 8:11 AM, Alan Bateman >>> >>> wrote: >>> >>>> On 16/06/2017 06:54, Sven Reimers wrote: >>>> >>>>> Hi all, >>>>> >>>>> as part of the process of the code donation from Oracle to Apache for >>>>> NetBeans I tried a compilation of the source code using idk 9-ea+173. >>>>> The >>>>> compilation fails due to an added method boolean >>>>> isModifiableModule(Module) >>>>> in java.lang.instrument.Instrumentation. >>>>> >>>>> Should the newly added method on the interface Instrumentation have a >>>>> default implementation to make this change source code compatible from >>>>> 8 >>>>> to >>>>> 9, e.g. >>>>> >>>>> default boolean isModifiableModule(Module module) { >>>>> >>>>> return false; >>>>> >>>>> } >>>>> >>>>> >>>>> Is it already to late for changing this before JDK 9 release? >>>>> >>>>> You are correct that adding abstract methods to Instrumentation is an >>>>> >>>> incompatible change but the long term assumption in this area has always >>>> been it wouldn't be implemented outside of the java.instrument module. >>>> There were 4 abstract methods added to it in Java SE 6 and I don't >>>> recall >>>> anyone screaming (pre-dates default methods of course). >>>> >>> Looks like I have implemented the code when compiling against JDK7. >> >> So can you say what NetBeans is doing? Is this mocking, maybe >>>> forwarding/intercepting? >>>> >>> See https://netbeans.org/bugzilla/show_bug.cgi?id=237919 >> >> If there is a compelling reasons then we could >>>> try >>>> to see about changing redefineModule and the other new methods to be >>>> default methods but it is late and there is more to this that changing >>>> them >>>> to be default methods. >>>> >>> -jt >> >> > -- Sven Reimers * Senior Expert Software Architect * Java Champion * NetBeans Dream Team Member: http://dreamteam.netbeans.org * Community Leader NetBeans: http://community.java.net/netbeans Desktop Java: http://community.java.net/javadesktop * JUG Leader JUG Bodensee: http://www.jug-bodensee.de * Duke's Choice Award Winner 2009 * XING: https://www.xing.com/profile/Sven_Reimers8 * LinkedIn: http://www.linkedin.com/in/svenreimers From michael.rasmussen at zeroturnaround.com Fri Jun 16 09:26:26 2017 From: michael.rasmussen at zeroturnaround.com (Michael Rasmussen) Date: Fri, 16 Jun 2017 12:26:26 +0300 Subject: Accessing module internals from bytecode rewriting agent In-Reply-To: References: <2099da91-fe6e-a5ed-3396-1e57284a75f1@oracle.com> <64a587a9-ec06-f0cd-f136-149b85e083d7@oracle.com> <3aef86fc-3fc2-9ff9-7be4-06d92800f0a7@oracle.com> <0e51419c-b100-8dc8-fb81-dd0b50b5177b@oracle.com> <8d225548-dadb-5b07-fcc5-4d1e37d43162@oracle.com> Message-ID: On 15 June 2017 at 21:31, Jeremy Manson wrote: > My initial thought in this general direction was to write a JVMTI agent > that takes a list of JAR files as arguments. It then does two things: > > - Intercepts all loads of classes using the ClassFileLoadHook, checks to > see if there is a class with that name in the JAR file, and, if so, uses > that one instead. That way, if you try to load java.util.HashMap, it will > replace the bytes the system is trying to load from rt.jar (or whatever) > with the bytes from the provided JAR. If going that route, then there are 3 capabilities added with JVMTI 9 that you should look into, in order to be able to intercept the loading of the very early classes as well (Object, String, Class etc): can_generate_early_vmstart can_generate_all_class_hook_events can_generate_early_class_hook_events Also note, that if your modified classes cause other classes to be loaded during loading/verification, then you might get into trouble. For instance if they don't exist in java.base, they won't be found. Also, we had some issues with a similar approach, where the Reference class was loaded too soon, causing it to not be correctly registered as a reference class in the VM, which caused crashes during GC (happening a lot later, after main() had started). /Michael From peter.levart at gmail.com Fri Jun 16 12:33:50 2017 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 16 Jun 2017 14:33:50 +0200 Subject: Incompatible change to java.lang.instrument.Instrumentation In-Reply-To: References: <34d81995-cafa-ef80-7dca-d2aef328ba23@oracle.com> <5676138.LCMvjuLTuO@pracovni> <02ebaf55-330c-d066-caff-46b699cbe855@gmail.com> Message-ID: <501de8e6-cdad-b5d0-434a-d492878b45aa@gmail.com> Hi Sven, On 06/16/2017 11:08 AM, Sven Reimers wrote: > Hi Peter, > > nice idea. The only drawback is this requires JDK 9 for a build. What > I wanted to check is if I can compile the same unchanged source tree > with JDK 8 and 9... Another trick that comes to my mind is to dynamically generate a java.lang.instrument.Instrumentation implementation using java.lang.reflect.Proxy and create an InvocationHandler as a substitute for NbInstrumentation rather than directly implementing the interface... Regards, Peter > > Since there is not yet a hard requirement for JDK 9 compilation, i.e. > this is just an experiment to figure out things that may be broken and > need work, I would not see any actions on NetBeans side at the moment. > I was just astonished about the breaking change naively assuming that > default methods should be an easy fix. > > Thanks for the hint, waiting what Alan comes up with in the meantime > (probably more projects could be hit by the problem) > > @Alan: Shall I file a bug? > > Thanks for the fast responses > > Sven > > On Fri, Jun 16, 2017 at 10:21 AM, Peter Levart > wrote: > > Hi Sven, > > Just an idea... > > What NetBeans could probably do is to create a special > sub-interface of java.lang.instrument.Instrumentation in its > bootstrap jar file (the jar passed to class-path) and make that > jar file MR jar with two versions of say > org.netbeans.core.Instrumentation interfaces extending > java.lang.instrument.Instrumentation. The one for pre-9 JDK would > have an empty body while the one for JDK 9 would override the > newly introduced abstract methods with default implementations. > NetBeans implementation classes would then implement > org.netbeans.core.Instrumentation instead of > java.lang.instrument.Instrumentation. > > Regards, Peter > > > On 06/16/2017 09:40 AM, Jaroslav Tulach wrote: > > On p?tek 16. ?ervna 2017 8:17:51 CEST Sven Reimers wrote: > > Hi Alan, > > the code in question I am looking at is in > > o.n.bootstrap/src/org/netbeans/NbInstrumentation.java > > So this looks more like some basic stuff baked deep into > NetBeans core... > > cc'Ing Jaroslav Tulach who wrote this - he should have > some more details.. > else I will try to figure this out. > > Thanks for looking into this > > Sven > > > On Fri, Jun 16, 2017 at 8:11 AM, Alan Bateman > > > > wrote: > > On 16/06/2017 06:54, Sven Reimers wrote: > > Hi all, > > as part of the process of the code donation from > Oracle to Apache for > NetBeans I tried a compilation of the source code > using idk 9-ea+173. The > compilation fails due to an added method boolean > isModifiableModule(Module) > in java.lang.instrument.Instrumentation. > > Should the newly added method on the interface > Instrumentation have a > default implementation to make this change source > code compatible from 8 > to > 9, e.g. > > default boolean isModifiableModule(Module module) { > > return false; > > } > > > Is it already to late for changing this before JDK > 9 release? > > You are correct that adding abstract methods to > Instrumentation is an > > incompatible change but the long term assumption in > this area has always > been it wouldn't be implemented outside of the > java.instrument module. > There were 4 abstract methods added to it in Java SE 6 > and I don't recall > anyone screaming (pre-dates default methods of course). > > Looks like I have implemented the code when compiling against > JDK7. > > So can you say what NetBeans is doing? Is this > mocking, maybe > forwarding/intercepting? > > See https://netbeans.org/bugzilla/show_bug.cgi?id=237919 > > > If there is a compelling reasons then we could > try > to see about changing redefineModule and the other new > methods to be > default methods but it is late and there is more to > this that changing > them > to be default methods. > > -jt > > > > > > -- > Sven Reimers > > * Senior Expert Software Architect > * Java Champion > * NetBeans Dream Team Member: http://dreamteam.netbeans.org > * Community Leader NetBeans: http://community.java.net/netbeans > Desktop Java: > http://community.java.net/javadesktop > * JUG Leader JUG Bodensee: http://www.jug-bodensee.de > * Duke's Choice Award Winner 2009 > > * XING: https://www.xing.com/profile/Sven_Reimers8 > * LinkedIn: http://www.linkedin.com/in/svenreimers From Alan.Bateman at oracle.com Fri Jun 16 12:41:43 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 16 Jun 2017 13:41:43 +0100 Subject: Accessing module internals from bytecode rewriting agent In-Reply-To: References: <64a587a9-ec06-f0cd-f136-149b85e083d7@oracle.com> <3aef86fc-3fc2-9ff9-7be4-06d92800f0a7@oracle.com> <0e51419c-b100-8dc8-fb81-dd0b50b5177b@oracle.com> <8d225548-dadb-5b07-fcc5-4d1e37d43162@oracle.com> Message-ID: <1348b2aa-a264-8088-a67e-fcc685a2ff3f@oracle.com> On 16/06/2017 10:26, Michael Rasmussen wrote: > : > If going that route, then there are 3 capabilities added with JVMTI 9 > that you should look into, in order to be able to intercept the > loading of the very early classes as well (Object, String, Class etc): > can_generate_early_vmstart > can_generate_all_class_hook_events > can_generate_early_class_hook_events The two can_generate_early_XXXX capabilities are new. can_generate_all_class_hook_events has been there since JVM TI 1.0. > : > > Also note, that if your modified classes cause other classes to be > loaded during loading/verification, then you might get into trouble. > For instance if they don't exist in java.base, they won't be found. > I assume you mean calling JNI FindClass in the start phase. A long standing bug in the JVM TI spec is that it set expectations that any JNI function could be used in the start phase even though the VM is not fully initialized. That spec issue was corrected and expectations dialed down with the spec changes in 9. Another point is that the start phase defaults to being deferred until VM initialization is at the point that it can classes in modules other than java.base. That keeps existing JVM TI agents working as the cost of them missing out on events from early startup (long before main is executed). -Alan. From Alan.Bateman at oracle.com Fri Jun 16 12:46:43 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 16 Jun 2017 13:46:43 +0100 Subject: 8181087: Module system implementation refresh (6/2017 update) In-Reply-To: <20564742-43D1-4470-A413-5D84F7028FA6@oracle.com> References: <206a429f-0aa7-d2dc-6bc5-831eccf4f620@oracle.com> <20564742-43D1-4470-A413-5D84F7028FA6@oracle.com> Message-ID: <993d580e-2bd8-de5f-f57e-47ed1d59554a@oracle.com> On 15/06/2017 15:28, Mandy Chung wrote: >> On Jun 15, 2017, at 12:34 AM, Alan Bateman wrote: >> >>> java/lang/Module.java >>> 901 void implAddOpensToAllUnnamed(Iterator iterator) { >>> 902 if (jdk.internal.misc.VM.isModuleSystemInited()) { >>> 903 iterator.forEachRemaining(pn -> >>> 904 implAddExportsOrOpens(pn, ALL_UNNAMED_MODULE, true, true)); >>> 905 return; >>> 906 } >>> >>> AFAICT this should only be called during module system initialization. >>> When will this method be called after initPhase 2? >> It's for use during startup (initPhase2) only. If called later then it works as if the module somehow reflectively opened the packages to all unnamed modules. I wouldn't object to changing it to throwing an exception (assuming that is what you are thinking) as the JDK doesn't have any use for this after initPhase2. > Yes this is what I am thinking. This method should catch when it?s called which is not expected. > Okay, I can do that. -Alan From Alan.Bateman at oracle.com Fri Jun 16 12:47:47 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 16 Jun 2017 13:47:47 +0100 Subject: 8181087: Module system implementation refresh (6/2017 update) In-Reply-To: References: Message-ID: <6ccbb439-49f0-3458-a502-a63529b33627@oracle.com> On 14/06/2017 22:44, Peter Levart wrote: > : > > > In j.l.Module: > > There are two places in the same method that contain exactly the same > fragment of code: > > 566 if (targets.contains(EVERYONE_MODULE) || > targets.contains(other)) > 567 return true; > 568 if (other != EVERYONE_MODULE > 569 && !other.isNamed() && > targets.contains(ALL_UNNAMED_MODULE)) > 570 return true; > > Perhaps this could be factored out into separate private method which > could also be made a little more optimal (when other == > EVERYONE_MODULE and targets does not contain it, it is looked-up twice > currently). Okay, make sense, I'll do that. -Alan From alan.bateman at oracle.com Fri Jun 16 12:49:43 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 16 Jun 2017 12:49:43 +0000 Subject: hg: jigsaw/jake/jdk: 2 new changesets Message-ID: <201706161249.v5GCnhdn005367@aojmv0008.oracle.com> Changeset: cb616bb8b8d0 Author: alanb Date: 2017-06-16 07:55 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/cb616bb8b8d0 com/sun/tools/attach/StartManagementAgent.java failing ! test/ProblemList.txt Changeset: c7c2a3e12341 Author: alanb Date: 2017-06-16 13:34 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c7c2a3e12341 Review comments ! src/java.base/share/classes/java/lang/Module.java From Alan.Bateman at oracle.com Fri Jun 16 12:56:18 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 16 Jun 2017 13:56:18 +0100 Subject: Incompatible change to java.lang.instrument.Instrumentation In-Reply-To: References: <34d81995-cafa-ef80-7dca-d2aef328ba23@oracle.com> <5676138.LCMvjuLTuO@pracovni> <02ebaf55-330c-d066-caff-46b699cbe855@gmail.com> Message-ID: <22778864-cbd8-4b04-c5cb-89e41ad2e138@oracle.com> On 16/06/2017 10:08, Sven Reimers wrote: > Hi Peter, > > nice idea. The only drawback is this requires JDK 9 for a build. What I > wanted to check is if I can compile the same unchanged source tree with JDK > 8 and 9... > > Since there is not yet a hard requirement for JDK 9 compilation, i.e. this > is just an experiment to figure out things that may be broken and need > work, I would not see any actions on NetBeans side at the moment. I was > just astonished about the breaking change naively assuming that default > methods should be an easy fix. > > Thanks for the hint, waiting what Alan comes up with in the meantime > (probably more projects could be hit by the problem) Hard to say. We've had new abstract methods on Instrumentation in the EA builds for a long time (and in main line JDK 9 EA builds since 3/2016) and it hasn't come up before now (at least not to my knowledge). > > @Alan: Shall I file a bug? > Okay. From mandy.chung at oracle.com Sat Jun 17 06:27:15 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 16 Jun 2017 23:27:15 -0700 Subject: Review Request JDK-8182416: Clean up module-info.java like move requires transitive adjacent to exports Message-ID: <78E7C761-8462-414D-B1B6-E42731DBF197@oracle.com> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8182416/webrev.00/ This patch cleans up module-info.java mainly moving requires transitive before exports, group exports/opens (packages) together and uses/provides (services) next. Document if a module is upgradeable. jdeps ?-generate-module-info is also updated to list requires transitive before exports. Mandy From lance.andersen at oracle.com Sat Jun 17 12:16:59 2017 From: lance.andersen at oracle.com (Lance Andersen) Date: Sat, 17 Jun 2017 08:16:59 -0400 Subject: Review Request JDK-8182416: Clean up module-info.java like move requires transitive adjacent to exports In-Reply-To: <78E7C761-8462-414D-B1B6-E42731DBF197@oracle.com> References: <78E7C761-8462-414D-B1B6-E42731DBF197@oracle.com> Message-ID: The changes looked fine Mandy. Nice that everything is consistent best lance > On Jun 17, 2017, at 2:27 AM, Mandy Chung wrote: > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8182416/webrev.00/ > > This patch cleans up module-info.java mainly moving requires transitive > before exports, group exports/opens (packages) together and uses/provides > (services) next. > > Document if a module is upgradeable. > > jdeps ?-generate-module-info is also updated to list requires transitive > before exports. > > Mandy Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From Alan.Bateman at oracle.com Sat Jun 17 14:26:44 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 17 Jun 2017 15:26:44 +0100 Subject: Review Request JDK-8182416: Clean up module-info.java like move requires transitive adjacent to exports In-Reply-To: <78E7C761-8462-414D-B1B6-E42731DBF197@oracle.com> References: <78E7C761-8462-414D-B1B6-E42731DBF197@oracle.com> Message-ID: On 17/06/2017 07:27, Mandy Chung wrote: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8182416/webrev.00/ > > This patch cleans up module-info.java mainly moving requires transitive > before exports, group exports/opens (packages) together and uses/provides > (services) next. > > Document if a module is upgradeable. > > jdeps ?-generate-module-info is also updated to list requires transitive > before exports. > This looks okay to me, I just wonder if jdk.xml.ws and jdk.xml.bind modules need the upgradeable note given that they aren't standard modules. A minor nit in java.corba where it has "

This ...". All the others have a space. For jdeps then should it emit a blank line between the groupings to be consistent with the proposed layout? -Alan From alan.bateman at oracle.com Sat Jun 17 15:11:54 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 17 Jun 2017 15:11:54 +0000 Subject: hg: jigsaw/jake/corba: 2 new changesets Message-ID: <201706171511.v5HFBsVT011232@aojmv0008.oracle.com> Changeset: e68b042f7130 Author: msheppar Date: 2017-06-16 20:37 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/e68b042f7130 8181836: BadKindHelper.html and BoundsHelper.html contains broken link in the javadoc Reviewed-by: chegar ! src/java.corba/share/classes/org/omg/CORBA/BoundsHelper.java ! src/java.corba/share/classes/org/omg/CORBA/ORBPackage/InvalidNameHelper.java ! src/java.corba/share/classes/org/omg/CORBA/TypeCodePackage/BadKindHelper.java ! src/java.corba/share/classes/org/omg/CORBA/TypeCodePackage/BoundsHelper.java Changeset: 285a1a834027 Author: alanb Date: 2017-06-17 15:37 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/285a1a834027 Merge From alan.bateman at oracle.com Sat Jun 17 15:11:56 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 17 Jun 2017 15:11:56 +0000 Subject: hg: jigsaw/jake/jaxp: 2 new changesets Message-ID: <201706171511.v5HFBuM4011325@aojmv0008.oracle.com> Changeset: f0eb5431121e Author: joehw Date: 2017-06-15 12:40 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/f0eb5431121e 8182111: Package summary is missing in jdk.xml.dom module Reviewed-by: mchung + src/jdk.xml.dom/share/classes/org/w3c/dom/css/package-info.java + src/jdk.xml.dom/share/classes/org/w3c/dom/html/package-info.java + src/jdk.xml.dom/share/classes/org/w3c/dom/stylesheets/package-info.java + src/jdk.xml.dom/share/classes/org/w3c/dom/xpath/package-info.java Changeset: e3909ee97599 Author: alanb Date: 2017-06-17 15:37 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/e3909ee97599 Merge From alan.bateman at oracle.com Sat Jun 17 15:11:55 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 17 Jun 2017 15:11:55 +0000 Subject: hg: jigsaw/jake/jaxws: 2 new changesets Message-ID: <201706171511.v5HFBth3011272@aojmv0008.oracle.com> Changeset: c9b85ef1567e Author: lancea Date: 2017-06-16 19:12 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/c9b85ef1567e 8182405: add legal file for freebxml Reviewed-by: mchung + src/jdk.xml.bind/share/legal/freebxml.md Changeset: e8582f469c79 Author: alanb Date: 2017-06-17 15:38 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/e8582f469c79 Merge From alan.bateman at oracle.com Sat Jun 17 15:11:58 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 17 Jun 2017 15:11:58 +0000 Subject: hg: jigsaw/jake: 7 new changesets Message-ID: <201706171511.v5HFBwFQ011343@aojmv0008.oracle.com> Changeset: 35f50e9952e4 Author: mchung Date: 2017-06-13 10:44 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/35f50e9952e4 8182029: Make the top-level docs index.html to a HTML-level redirect to the API overview page Reviewed-by: alanb, erikj, ihse ! make/Docs.gmk Changeset: e73b6959f72d Author: lana Date: 2017-06-15 17:43 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/e73b6959f72d Merge Changeset: e5c8a9c39558 Author: mchung Date: 2017-06-15 11:54 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/e5c8a9c39558 8182032: Make java.compiler upgradeable Reviewed-by: alanb, erikj ! make/CreateJmods.gmk ! make/common/Modules.gmk Changeset: ce42e2c57dc7 Author: ihse Date: 2017-06-16 11:41 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/ce42e2c57dc7 8179556: Add specs copyright file Reviewed-by: erikj ! make/Docs.gmk Changeset: 34742222cd74 Author: alanb Date: 2017-06-16 09:20 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/34742222cd74 8181087: Module system implementation refresh (6/2017) Reviewed-by: sspitsyn, hseigel ! test/lib/sun/hotspot/WhiteBox.java Changeset: 83d12a7fae3d Author: alanb Date: 2017-06-17 08:02 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/83d12a7fae3d Merge Changeset: 30106266e9e8 Author: alanb Date: 2017-06-17 15:32 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/30106266e9e8 Merge ! make/CreateJmods.gmk ! make/Docs.gmk ! make/common/Modules.gmk ! test/lib/sun/hotspot/WhiteBox.java From alan.bateman at oracle.com Sat Jun 17 15:11:59 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 17 Jun 2017 15:11:59 +0000 Subject: hg: jigsaw/jake/hotspot: 11 new changesets Message-ID: <201706171512.v5HFC0hd011350@aojmv0008.oracle.com> Changeset: 79b6a9bd5c3b Author: fyang Date: 2017-06-10 16:01 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/79b6a9bd5c3b 8181906: AArch64: port bugfix for 7009641 to AArch64 Summary: Allocation in the code cache returns NULL instead of failing the entire VM Reviewed-by: aph Contributed-by: teng.lu at linaro.org ! src/cpu/aarch64/vm/vtableStubs_aarch64.cpp Changeset: 29467418d0ca Author: rbackman Date: 2017-06-02 11:26 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/29467418d0ca 8180197: Failing assert: id must be initialized Reviewed-by: kvn, kbarrett ! src/share/vm/compiler/compileBroker.cpp Changeset: 7107dccce2b2 Author: dlong Date: 2017-06-13 10:27 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7107dccce2b2 8181757: NonNMethod heap in segmented CodeCache is not scanned in some cases 8171365: nsk/jvmti/scenarios/events/EM04/em04t001: many errors for missed events Reviewed-by: thartmann, kvn ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp Changeset: d7709f2d4bd3 Author: sspitsyn Date: 2017-06-13 16:19 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d7709f2d4bd3 8178054: [TESTBUG] Need test for JVM TI IsModifiableModule Summary: Add new test hotspot/test/serviceability/jvmti/GetNamedModule Reviewed-by: alanb, iignatyev ! make/test/JtregNative.gmk ! test/serviceability/jvmti/GetNamedModule/MyPackage/GetNamedModuleTest.java + test/serviceability/jvmti/IsModifiableModule/MyPackage/IsModifiableModuleTest.java + test/serviceability/jvmti/IsModifiableModule/libIsModifiableModuleTest.c Changeset: 5e54f0bcf4ef Author: sspitsyn Date: 2017-06-13 23:22 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5e54f0bcf4ef Merge Changeset: 232d93f11c49 Author: lana Date: 2017-06-15 17:43 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/232d93f11c49 Merge Changeset: 5347a840127d Author: dnsimon Date: 2017-06-16 12:18 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5347a840127d 8182310: [AOT][JVMCI] Get host class of VM anonymous class Summary: Add missing JVMCI functionality Reviewed-by: dlong, kvn ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/CompilerToVM.java ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedObjectTypeImpl.java ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedPrimitiveType.java ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/ResolvedJavaType.java ! src/share/vm/jvmci/jvmciCompilerToVM.cpp ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java Changeset: 409ae96e9140 Author: poonam Date: 2017-06-16 22:10 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/409ae96e9140 8178536: OOM ERRORS + SERVICE-THREAD TAKES A PROCESSOR TO 100% Summary: Clear the pending OOM exception in SensorInfo::trigger() Reviewed-by: mchung, dcubed ! src/share/vm/services/lowMemoryDetector.cpp Changeset: 0d4a6056e3cc Author: alanb Date: 2017-06-16 09:20 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0d4a6056e3cc 8181087: Module system implementation refresh (6/2017) Reviewed-by: sspitsyn, hseigel ! make/symbols/symbols-unix ! src/share/vm/classfile/modules.cpp ! src/share/vm/classfile/modules.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/arguments.cpp - test/runtime/modules/JVMAddModulePackage.java ! test/runtime/modules/ModuleHelper.java ! test/runtime/modules/java.base/java/lang/ModuleHelper.java Changeset: 032a5041e20a Author: alanb Date: 2017-06-17 08:03 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/032a5041e20a Merge - test/runtime/modules/JVMAddModulePackage.java Changeset: e2fda2cd1cac Author: alanb Date: 2017-06-17 15:35 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e2fda2cd1cac Merge ! make/symbols/symbols-unix ! make/test/JtregNative.gmk ! src/share/vm/classfile/modules.cpp ! src/share/vm/classfile/modules.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/arguments.cpp ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java ! test/runtime/modules/ModuleHelper.java ! test/runtime/modules/java.base/java/lang/ModuleHelper.java From alan.bateman at oracle.com Sat Jun 17 15:12:01 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 17 Jun 2017 15:12:01 +0000 Subject: hg: jigsaw/jake/langtools: 5 new changesets Message-ID: <201706171512.v5HFC176011355@aojmv0008.oracle.com> Changeset: bbb3a10fce39 Author: jjg Date: 2017-06-15 14:45 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/bbb3a10fce39 8181825: Add tool and services information to module summary Reviewed-by: mchung, rfield ! src/jdk.compiler/share/classes/com/sun/tools/javac/Main.java + src/jdk.compiler/share/classes/com/sun/tools/javac/package-info.java ! src/jdk.compiler/share/classes/module-info.java ! src/jdk.javadoc/share/classes/module-info.java ! src/jdk.jdeps/share/classes/module-info.java ! src/jdk.jshell/share/classes/module-info.java Changeset: 15ebbc892255 Author: jjg Date: 2017-06-16 15:29 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/15ebbc892255 8182406: Add missing legal file for jquery Reviewed-by: mchung + src/jdk.javadoc/share/legal/jquery.md Changeset: abaedfca9e3e Author: alanb Date: 2017-06-16 09:21 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/abaedfca9e3e 8181087: Module system implementation refresh (6/2017) Reviewed-by: jjg Contributed-by: alan.bateman at oracle.com, jan.lahoda at oracle.com ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.jdeps/share/classes/module-info.java + test/tools/javac/diags/examples/PackageClashFromRequiresInUnnamed/PackageClashFromRequiresInUnnamed.java + test/tools/javac/diags/examples/PackageClashFromRequiresInUnnamed/modulepath/lib1x/exported/Api1.java + test/tools/javac/diags/examples/PackageClashFromRequiresInUnnamed/modulepath/lib1x/module-info.java + test/tools/javac/diags/examples/PackageClashFromRequiresInUnnamed/modulepath/lib2x/exported/Api2.java + test/tools/javac/diags/examples/PackageClashFromRequiresInUnnamed/modulepath/lib2x/module-info.java ! test/tools/javac/modules/AutomaticModules.java ! test/tools/javac/modules/PackageConflictTest.java Changeset: cbabd54a029b Author: alanb Date: 2017-06-17 08:02 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/cbabd54a029b Merge ! src/jdk.jdeps/share/classes/module-info.java Changeset: 3938af370ffd Author: alanb Date: 2017-06-17 15:33 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/3938af370ffd Merge ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/module-info.java ! src/jdk.javadoc/share/classes/module-info.java ! src/jdk.jdeps/share/classes/module-info.java ! src/jdk.jshell/share/classes/module-info.java ! test/tools/javac/modules/AutomaticModules.java ! test/tools/javac/modules/PackageConflictTest.java From alan.bateman at oracle.com Sat Jun 17 15:12:10 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 17 Jun 2017 15:12:10 +0000 Subject: hg: jigsaw/jake/jdk: 20 new changesets Message-ID: <201706171512.v5HFCBDL011377@aojmv0008.oracle.com> Changeset: e8f3a872e69a Author: psandoz Date: 2017-06-12 14:30 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e8f3a872e69a 8181442: Deprecate sun.misc.Unsafe.defineClass Reviewed-by: shade, mchung ! src/jdk.unsupported/share/classes/sun/misc/Unsafe.java Changeset: 573efb47b310 Author: vinnie Date: 2017-06-13 13:31 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/573efb47b310 8181978: Keystore probing mechanism fails for large PKCS12 keystores Reviewed-by: mullan ! src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java + test/sun/security/pkcs12/ProbeLargeKeystore.java Changeset: 9b69584ea554 Author: dl Date: 2017-06-13 09:13 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9b69584ea554 8181104: Fix specs for updateAndGet and related methods Reviewed-by: martin, psandoz, dholmes, chegar ! src/java.base/share/classes/java/lang/invoke/VarHandle.java ! src/java.base/share/classes/java/util/concurrent/atomic/AtomicInteger.java ! src/java.base/share/classes/java/util/concurrent/atomic/AtomicIntegerArray.java ! src/java.base/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java ! src/java.base/share/classes/java/util/concurrent/atomic/AtomicLong.java ! src/java.base/share/classes/java/util/concurrent/atomic/AtomicLongArray.java ! src/java.base/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java ! src/java.base/share/classes/java/util/concurrent/atomic/AtomicReference.java ! src/java.base/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java ! src/java.base/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java Changeset: 0ffdaa7668ad Author: mchung Date: 2017-06-13 10:44 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0ffdaa7668ad 8182029: Make the top-level docs index.html to a HTML-level redirect to the API overview page Reviewed-by: alanb, erikj, ihse ! make/ModuleTools.gmk - make/src/classes/build/tools/docs/GenDocsBundlePage.java - make/src/classes/build/tools/docs/docs-bundle-page.html - make/src/classes/build/tools/docs/docs-module-groups.properties Changeset: 59902f12fb70 Author: bpb Date: 2017-06-13 13:43 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/59902f12fb70 6791812: (file spec) Incompatible File.lastModified() and setLastModified() for negative time Summary: Amend verbiage describing return value to explain negative values. Reviewed-by: rriggs, smarks ! src/java.base/share/classes/java/io/File.java Changeset: 6391a43c89ee Author: mchung Date: 2017-06-14 09:21 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6391a43c89ee 8182137: Missing permissions in deprivileged java.xml.bind and java.xml.ws modules Reviewed-by: alanb, mullan ! src/java.base/share/lib/security/default.policy Changeset: e43d0498a4ac Author: lancea Date: 2017-06-14 12:46 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e43d0498a4ac 8181832: Broken link in javax/sql/rowset/spi/package-summary.html Reviewed-by: alanb, mchung ! src/java.sql.rowset/share/classes/javax/sql/rowset/spi/package.html Changeset: 6b8f8ab175ff Author: lana Date: 2017-06-15 17:43 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6b8f8ab175ff Merge - make/src/classes/build/tools/docs/GenDocsBundlePage.java - make/src/classes/build/tools/docs/docs-bundle-page.html - make/src/classes/build/tools/docs/docs-module-groups.properties Changeset: 28d099962ee2 Author: mchung Date: 2017-06-15 11:54 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/28d099962ee2 8182032: Make java.compiler upgradeable Reviewed-by: alanb, erikj + test/jdk/modules/etc/UpgradeableModules.java ! test/jdk/modules/etc/VerifyModuleDelegation.java Changeset: dfeb383db3bb Author: herrick Date: 2017-06-15 15:03 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/dfeb383db3bb 8181821: Broken link in javadoc for JSObject.getWindow Reviewed-by: mchung ! src/jdk.jsobject/share/classes/netscape/javascript/JSObject.java Changeset: 82ed25c3cea9 Author: ksrini Date: 2017-06-15 14:27 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/82ed25c3cea9 8182185: Add Copyright notices to pack 200 spec Reviewed-by: mchung ! src/java.base/share/classes/java/util/jar/Pack200.java Changeset: e23c712e1d94 Author: poonam Date: 2017-06-16 22:10 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e23c712e1d94 8178536: OOM ERRORS + SERVICE-THREAD TAKES A PROCESSOR TO 100% Summary: Clear the pending OOM exception in SensorInfo::trigger() Reviewed-by: mchung, dcubed ! src/java.management/share/classes/sun/management/MemoryPoolImpl.java Changeset: bec8ca52804c Author: smarks Date: 2017-05-19 14:46 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/bec8ca52804c 8177788: migrate collections technotes/guides into java/util/doc-files Reviewed-by: mchung, bchristi, martin + src/java.base/share/classes/java/util/doc-files/coll-designfaq.html + src/java.base/share/classes/java/util/doc-files/coll-index.html + src/java.base/share/classes/java/util/doc-files/coll-overview.html + src/java.base/share/classes/java/util/doc-files/coll-reference.html ! src/java.base/share/classes/java/util/package-info.java Changeset: 6e591955c8a8 Author: serb Date: 2017-06-08 22:07 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6e591955c8a8 8180326: Update the tables in java.desktop to be HTML-5 friendly Reviewed-by: prr, azvegint ! src/java.desktop/share/classes/java/applet/AppletContext.java ! src/java.desktop/share/classes/java/awt/AWTKeyStroke.java ! src/java.desktop/share/classes/java/awt/AWTPermission.java ! src/java.desktop/share/classes/java/awt/AlphaComposite.java ! src/java.desktop/share/classes/java/awt/Component.java ! src/java.desktop/share/classes/java/awt/Container.java ! src/java.desktop/share/classes/java/awt/EventQueue.java ! src/java.desktop/share/classes/java/awt/GridBagLayout.java ! src/java.desktop/share/classes/java/awt/GridLayout.java ! src/java.desktop/share/classes/java/awt/KeyboardFocusManager.java ! src/java.desktop/share/classes/java/awt/Scrollbar.java ! src/java.desktop/share/classes/java/awt/SystemTray.java ! src/java.desktop/share/classes/java/awt/font/NumericShaper.java ! src/java.desktop/share/classes/java/awt/font/TextAttribute.java ! src/java.desktop/share/classes/java/awt/geom/Path2D.java ! src/java.desktop/share/classes/javax/print/DocFlavor.java ! src/java.desktop/share/classes/javax/print/attribute/standard/Chromaticity.java ! src/java.desktop/share/classes/javax/print/attribute/standard/Finishings.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobKOctets.java ! src/java.desktop/share/classes/javax/sound/midi/MidiSystem.java ! src/java.desktop/share/classes/javax/sound/sampled/AudioFormat.java ! src/java.desktop/share/classes/javax/sound/sampled/AudioPermission.java ! src/java.desktop/share/classes/javax/sound/sampled/AudioSystem.java ! src/java.desktop/share/classes/javax/sound/sampled/ReverbType.java ! src/java.desktop/share/classes/javax/swing/Action.java ! src/java.desktop/share/classes/javax/swing/BoxLayout.java ! src/java.desktop/share/classes/javax/swing/JFormattedTextField.java ! src/java.desktop/share/classes/javax/swing/JLayeredPane.java ! src/java.desktop/share/classes/javax/swing/JList.java ! src/java.desktop/share/classes/javax/swing/JOptionPane.java ! src/java.desktop/share/classes/javax/swing/JRootPane.java ! src/java.desktop/share/classes/javax/swing/JScrollPane.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicListUI.java ! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java ! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalTreeUI.java ! src/java.desktop/share/classes/javax/swing/text/JTextComponent.java ! src/java.desktop/share/classes/javax/swing/text/MaskFormatter.java ! src/java.desktop/share/classes/javax/swing/text/html/FormView.java ! src/java.desktop/share/classes/javax/swing/text/html/HTMLDocument.java ! src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java ! src/java.desktop/share/classes/javax/swing/tree/DefaultTreeCellRenderer.java ! src/java.desktop/share/classes/javax/swing/undo/UndoManager.java Changeset: 415b0831244f Author: serb Date: 2017-06-13 02:27 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/415b0831244f 8181877: Cleanup of javadoc in javax.accessibility package Reviewed-by: prr ! src/java.desktop/share/classes/javax/accessibility/AccessibilityProvider.java ! src/java.desktop/share/classes/javax/accessibility/Accessible.java ! src/java.desktop/share/classes/javax/accessibility/AccessibleAction.java ! src/java.desktop/share/classes/javax/accessibility/AccessibleAttributeSequence.java ! src/java.desktop/share/classes/javax/accessibility/AccessibleBundle.java ! src/java.desktop/share/classes/javax/accessibility/AccessibleComponent.java ! src/java.desktop/share/classes/javax/accessibility/AccessibleContext.java ! src/java.desktop/share/classes/javax/accessibility/AccessibleEditableText.java ! src/java.desktop/share/classes/javax/accessibility/AccessibleExtendedComponent.java ! src/java.desktop/share/classes/javax/accessibility/AccessibleExtendedTable.java ! src/java.desktop/share/classes/javax/accessibility/AccessibleExtendedText.java ! src/java.desktop/share/classes/javax/accessibility/AccessibleHyperlink.java ! src/java.desktop/share/classes/javax/accessibility/AccessibleHypertext.java ! src/java.desktop/share/classes/javax/accessibility/AccessibleIcon.java ! src/java.desktop/share/classes/javax/accessibility/AccessibleKeyBinding.java ! src/java.desktop/share/classes/javax/accessibility/AccessibleRelation.java ! src/java.desktop/share/classes/javax/accessibility/AccessibleRelationSet.java ! src/java.desktop/share/classes/javax/accessibility/AccessibleResourceBundle.java ! src/java.desktop/share/classes/javax/accessibility/AccessibleRole.java ! src/java.desktop/share/classes/javax/accessibility/AccessibleSelection.java ! src/java.desktop/share/classes/javax/accessibility/AccessibleState.java ! src/java.desktop/share/classes/javax/accessibility/AccessibleStateSet.java ! src/java.desktop/share/classes/javax/accessibility/AccessibleStreamable.java ! src/java.desktop/share/classes/javax/accessibility/AccessibleTable.java ! src/java.desktop/share/classes/javax/accessibility/AccessibleTableModelChange.java ! src/java.desktop/share/classes/javax/accessibility/AccessibleText.java ! src/java.desktop/share/classes/javax/accessibility/AccessibleTextSequence.java ! src/java.desktop/share/classes/javax/accessibility/AccessibleValue.java ! src/java.desktop/share/classes/javax/accessibility/package-info.java Changeset: 757b830688e3 Author: ddehaven Date: 2017-06-16 17:41 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/757b830688e3 Merge Changeset: bd582963beb7 Author: dl Date: 2017-06-16 19:50 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/bd582963beb7 8181334: add spec for Deque.addAll Reviewed-by: martin, psandoz, smarks, darcy ! src/java.base/share/classes/java/util/Deque.java Changeset: f8b19df2115a Author: alanb Date: 2017-06-16 09:20 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f8b19df2115a 8181087: Module system implementation refresh (6/2017) Reviewed-by: plevart, mchung Contributed-by: alan.bateman at oracle.com, alex.buckley at oracle.com ! make/mapfiles/libjava/mapfile-vers ! make/src/classes/build/tools/jigsaw/technology-summary.html ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/java/lang/LayerInstantiationException.java ! src/java.base/share/classes/java/lang/Module.java ! src/java.base/share/classes/java/lang/ModuleLayer.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/lang/module/Configuration.java ! src/java.base/share/classes/java/lang/module/ModuleFinder.java ! src/java.base/share/classes/java/lang/module/package-info.java ! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java ! src/java.base/share/classes/java/util/ServiceConfigurationError.java ! src/java.base/share/classes/java/util/ServiceLoader.java ! src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java ! src/java.base/share/classes/jdk/internal/loader/Loader.java ! src/java.base/share/classes/jdk/internal/misc/JavaLangAccess.java ! src/java.base/share/classes/jdk/internal/module/IllegalAccessLogger.java + src/java.base/share/classes/jdk/internal/module/IllegalAccessMaps.java ! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java ! src/java.base/share/classes/jdk/internal/module/ModulePath.java ! src/java.base/share/classes/jdk/internal/module/ModuleReferenceImpl.java ! src/java.base/share/classes/jdk/internal/module/Modules.java ! src/java.base/share/classes/jdk/internal/module/SystemModules.java + src/java.base/share/classes/jdk/internal/module/jdk8_packages.dat ! src/java.base/share/classes/sun/launcher/LauncherHelper.java ! src/java.base/share/classes/sun/launcher/resources/launcher.properties ! src/java.base/share/native/include/jvm.h ! src/java.base/share/native/libjava/Module.c + src/java.instrument/share/classes/java/lang/instrument/package-info.java - src/java.instrument/share/classes/java/lang/instrument/package.html ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java ! test/ProblemList.txt ! test/java/lang/ModuleLayer/BasicLayerTest.java ! test/java/lang/ModuleLayer/LayerAndLoadersTest.java ! test/java/lang/ModuleLayer/LayerControllerTest.java ! test/java/lang/ModuleTests/AnnotationsTest.java ! test/java/lang/ModuleTests/BasicModuleTest.java ! test/java/lang/ModuleTests/annotation/Basic.java ! test/java/lang/instrument/RedefineModuleTest.java ! test/java/lang/module/AutomaticModulesTest.java ! test/java/lang/reflect/AccessibleObject/CanAccessTest.java ! test/java/lang/reflect/AccessibleObject/ModuleSetAccessibleTest.java ! test/java/lang/reflect/AccessibleObject/TrySetAccessibleTest.java ! test/java/util/ResourceBundle/modules/cache/CacheTest.java + test/java/util/ServiceLoader/BadProvidersTest.java + test/java/util/ServiceLoader/ModulesTest.java + test/java/util/ServiceLoader/NoInterferenceTest.java + test/java/util/ServiceLoader/ReloadTest.java + test/java/util/ServiceLoader/badfactories/badreturntype/ProviderFactory.java + test/java/util/ServiceLoader/badfactories/classnotpublic/ProviderFactory.java + test/java/util/ServiceLoader/badfactories/classnotpublic/Service.java + test/java/util/ServiceLoader/badfactories/methodnotpublic/ProviderFactory.java + test/java/util/ServiceLoader/badfactories/methodnotpublic/Service.java + test/java/util/ServiceLoader/badfactories/returnsnull/ProviderFactory.java + test/java/util/ServiceLoader/badfactories/returnsnull/Service.java + test/java/util/ServiceLoader/badfactories/throwsexception/ProviderFactory.java + test/java/util/ServiceLoader/badfactories/throwsexception/Service.java + test/java/util/ServiceLoader/badproviders/ctornotpublic/Provider.java + test/java/util/ServiceLoader/badproviders/ctornotpublic/Service.java + test/java/util/ServiceLoader/badproviders/notasubtype/Provider.java + test/java/util/ServiceLoader/badproviders/notpublic/Provider.java + test/java/util/ServiceLoader/badproviders/notpublic/Service.java + test/java/util/ServiceLoader/badproviders/throwsexception/Provider.java + test/java/util/ServiceLoader/badproviders/throwsexception/Service.java + test/java/util/ServiceLoader/classpath/pearscript/META-INF/services/javax.script.ScriptEngineFactory + test/java/util/ServiceLoader/classpath/pearscript/org/pear/PearScript.java + test/java/util/ServiceLoader/classpath/pearscript/org/pear/PearScriptEngineFactory.java + test/java/util/ServiceLoader/inheritance/NoInheritanceTest.java + test/java/util/ServiceLoader/inheritance/test/module-info.java + test/java/util/ServiceLoader/inheritance/test/p/Main.java - test/java/util/ServiceLoader/modules/BadProvidersTest.java - test/java/util/ServiceLoader/modules/Basic.java - test/java/util/ServiceLoader/modules/badfactories/badreturntype/ProviderFactory.java - test/java/util/ServiceLoader/modules/badfactories/classnotpublic/ProviderFactory.java - test/java/util/ServiceLoader/modules/badfactories/classnotpublic/Service.java - test/java/util/ServiceLoader/modules/badfactories/methodnotpublic/ProviderFactory.java - test/java/util/ServiceLoader/modules/badfactories/methodnotpublic/Service.java - test/java/util/ServiceLoader/modules/badfactories/returnsnull/ProviderFactory.java - test/java/util/ServiceLoader/modules/badfactories/returnsnull/Service.java - test/java/util/ServiceLoader/modules/badfactories/throwsexception/ProviderFactory.java - test/java/util/ServiceLoader/modules/badfactories/throwsexception/Service.java - test/java/util/ServiceLoader/modules/badproviders/ctornotpublic/Provider.java - test/java/util/ServiceLoader/modules/badproviders/ctornotpublic/Service.java - test/java/util/ServiceLoader/modules/badproviders/notasubtype/Provider.java - test/java/util/ServiceLoader/modules/badproviders/notpublic/Provider.java - test/java/util/ServiceLoader/modules/badproviders/notpublic/Service.java - test/java/util/ServiceLoader/modules/badproviders/throwsexception/Provider.java - test/java/util/ServiceLoader/modules/badproviders/throwsexception/Service.java + test/java/util/ServiceLoader/modules/bananascript/module-info.java + test/java/util/ServiceLoader/modules/bananascript/org/banana/BananaScript.java + test/java/util/ServiceLoader/modules/bananascript/org/banana/BananaScriptEngineFactory.java - test/java/util/ServiceLoader/modules/modules/bananascript/module-info.java - test/java/util/ServiceLoader/modules/modules/bananascript/org/banana/BananaScript.java - test/java/util/ServiceLoader/modules/modules/bananascript/org/banana/BananaScriptEngineFactory.java - test/java/util/ServiceLoader/modules/modules/test1/module-info.java - test/java/util/ServiceLoader/modules/modules/test1/p/ProviderFactory.java - test/java/util/ServiceLoader/modules/modules/test1/p/Service.java - test/java/util/ServiceLoader/modules/modules/test2/module-info.java - test/java/util/ServiceLoader/modules/modules/test2/p/Provider.java - test/java/util/ServiceLoader/modules/modules/test2/p/Service.java + test/java/util/ServiceLoader/modules/p1/module-info.java + test/java/util/ServiceLoader/modules/p1/q/P.java + test/java/util/ServiceLoader/modules/p2/module-info.java + test/java/util/ServiceLoader/modules/p2/q/P.java + test/java/util/ServiceLoader/modules/s1/module-info.java + test/java/util/ServiceLoader/modules/s1/p/S.java + test/java/util/ServiceLoader/modules/s2/module-info.java + test/java/util/ServiceLoader/modules/s2/p/S.java - test/java/util/ServiceLoader/modules/src/pearscript/META-INF/services/javax.script.ScriptEngineFactory - test/java/util/ServiceLoader/modules/src/pearscript/org/pear/PearScript.java - test/java/util/ServiceLoader/modules/src/pearscript/org/pear/PearScriptEngineFactory.java + test/java/util/ServiceLoader/modules/test1/module-info.java + test/java/util/ServiceLoader/modules/test1/p/ProviderFactory.java + test/java/util/ServiceLoader/modules/test1/p/Service.java + test/java/util/ServiceLoader/modules/test2/module-info.java + test/java/util/ServiceLoader/modules/test2/p/Provider.java + test/java/util/ServiceLoader/modules/test2/p/Service.java + test/java/util/ServiceLoader/nouses/NoUsesTest.java + test/java/util/ServiceLoader/nouses/test/module-info.java + test/java/util/ServiceLoader/nouses/test/p/Main.java + test/java/util/ServiceLoader/security/SecurityTest.java + test/java/util/ServiceLoader/security/test/module-info.java + test/java/util/ServiceLoader/security/test/p/Tests.java ! test/jdk/modules/open/Basic.java ! test/tools/launcher/modules/addexports/manifest/AddExportsAndOpensInManifest.java + test/tools/launcher/modules/illegalaccess/IllegalAccessTest.java + test/tools/launcher/modules/illegalaccess/TryAccess.java + test/tools/launcher/modules/illegalaccess/modules/m/module-info.java + test/tools/launcher/modules/illegalaccess/modules/m/p/Type.java + test/tools/launcher/modules/illegalaccess/patchsrc/java.base/java/lang/Helper.java + test/tools/launcher/modules/illegalaccess/upgradesrc/java.activation/javax/activation/MimeTypeParameterList.java + test/tools/launcher/modules/illegalaccess/upgradesrc/java.activation/module-info.java ! test/tools/launcher/modules/patch/systemmodules/src1/java.base/jdk/internal/modules/SystemModules.java - test/tools/launcher/modules/permit/AttemptAccess.java - test/tools/launcher/modules/permit/PermitIllegalAccess.java Changeset: 14c177bb4ea4 Author: alanb Date: 2017-06-17 08:03 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/14c177bb4ea4 Merge - src/java.instrument/share/classes/java/lang/instrument/package.html - test/java/util/ServiceLoader/modules/BadProvidersTest.java - test/java/util/ServiceLoader/modules/Basic.java - test/java/util/ServiceLoader/modules/badfactories/badreturntype/ProviderFactory.java - test/java/util/ServiceLoader/modules/badfactories/classnotpublic/ProviderFactory.java - test/java/util/ServiceLoader/modules/badfactories/classnotpublic/Service.java - test/java/util/ServiceLoader/modules/badfactories/methodnotpublic/ProviderFactory.java - test/java/util/ServiceLoader/modules/badfactories/methodnotpublic/Service.java - test/java/util/ServiceLoader/modules/badfactories/returnsnull/ProviderFactory.java - test/java/util/ServiceLoader/modules/badfactories/returnsnull/Service.java - test/java/util/ServiceLoader/modules/badfactories/throwsexception/ProviderFactory.java - test/java/util/ServiceLoader/modules/badfactories/throwsexception/Service.java - test/java/util/ServiceLoader/modules/badproviders/ctornotpublic/Provider.java - test/java/util/ServiceLoader/modules/badproviders/ctornotpublic/Service.java - test/java/util/ServiceLoader/modules/badproviders/notasubtype/Provider.java - test/java/util/ServiceLoader/modules/badproviders/notpublic/Provider.java - test/java/util/ServiceLoader/modules/badproviders/notpublic/Service.java - test/java/util/ServiceLoader/modules/badproviders/throwsexception/Provider.java - test/java/util/ServiceLoader/modules/badproviders/throwsexception/Service.java - test/java/util/ServiceLoader/modules/modules/bananascript/module-info.java - test/java/util/ServiceLoader/modules/modules/bananascript/org/banana/BananaScript.java - test/java/util/ServiceLoader/modules/modules/bananascript/org/banana/BananaScriptEngineFactory.java - test/java/util/ServiceLoader/modules/modules/test1/module-info.java - test/java/util/ServiceLoader/modules/modules/test1/p/ProviderFactory.java - test/java/util/ServiceLoader/modules/modules/test1/p/Service.java - test/java/util/ServiceLoader/modules/modules/test2/module-info.java - test/java/util/ServiceLoader/modules/modules/test2/p/Provider.java - test/java/util/ServiceLoader/modules/modules/test2/p/Service.java - test/java/util/ServiceLoader/modules/src/pearscript/META-INF/services/javax.script.ScriptEngineFactory - test/java/util/ServiceLoader/modules/src/pearscript/org/pear/PearScript.java - test/java/util/ServiceLoader/modules/src/pearscript/org/pear/PearScriptEngineFactory.java - test/tools/launcher/modules/permit/AttemptAccess.java - test/tools/launcher/modules/permit/PermitIllegalAccess.java Changeset: 901193738847 Author: alanb Date: 2017-06-17 15:52 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/901193738847 Merge ! make/ModuleTools.gmk ! make/mapfiles/libjava/mapfile-vers - make/src/classes/build/tools/docs/GenDocsBundlePage.java - make/src/classes/build/tools/docs/docs-bundle-page.html - make/src/classes/build/tools/docs/docs-module-groups.properties ! make/src/classes/build/tools/jigsaw/technology-summary.html ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/java/lang/LayerInstantiationException.java ! src/java.base/share/classes/java/lang/Module.java ! src/java.base/share/classes/java/lang/ModuleLayer.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/lang/module/Configuration.java ! src/java.base/share/classes/java/lang/module/ModuleFinder.java ! src/java.base/share/classes/java/lang/module/package-info.java ! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java ! src/java.base/share/classes/java/util/ServiceLoader.java ! src/java.base/share/classes/java/util/jar/Pack200.java ! src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java ! src/java.base/share/classes/jdk/internal/loader/Loader.java ! src/java.base/share/classes/jdk/internal/misc/JavaLangAccess.java ! src/java.base/share/classes/jdk/internal/module/IllegalAccessLogger.java ! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java ! src/java.base/share/classes/jdk/internal/module/ModulePath.java ! src/java.base/share/classes/jdk/internal/module/ModuleReferenceImpl.java ! src/java.base/share/classes/jdk/internal/module/Modules.java ! src/java.base/share/classes/jdk/internal/module/SystemModules.java ! src/java.base/share/classes/sun/launcher/LauncherHelper.java ! src/java.base/share/classes/sun/launcher/resources/launcher.properties ! src/java.base/share/native/include/jvm.h ! src/java.base/share/native/libjava/Module.c ! src/java.desktop/share/classes/java/awt/Component.java ! src/java.instrument/share/classes/java/lang/instrument/package-info.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java ! test/ProblemList.txt ! test/java/lang/ModuleLayer/BasicLayerTest.java ! test/java/lang/ModuleLayer/LayerAndLoadersTest.java ! test/java/lang/ModuleLayer/LayerControllerTest.java ! test/java/lang/ModuleTests/AnnotationsTest.java ! test/java/lang/ModuleTests/BasicModuleTest.java ! test/java/lang/ModuleTests/annotation/Basic.java ! test/java/lang/instrument/RedefineModuleTest.java ! test/java/lang/module/AutomaticModulesTest.java ! test/java/lang/reflect/AccessibleObject/ModuleSetAccessibleTest.java ! test/java/util/ServiceLoader/BadProvidersTest.java ! test/java/util/ServiceLoader/ModulesTest.java ! test/java/util/ServiceLoader/badfactories/badreturntype/ProviderFactory.java ! test/java/util/ServiceLoader/badfactories/classnotpublic/ProviderFactory.java ! test/java/util/ServiceLoader/badfactories/classnotpublic/Service.java ! test/java/util/ServiceLoader/badfactories/methodnotpublic/ProviderFactory.java ! test/java/util/ServiceLoader/badfactories/methodnotpublic/Service.java ! test/java/util/ServiceLoader/badfactories/returnsnull/ProviderFactory.java ! test/java/util/ServiceLoader/badfactories/returnsnull/Service.java ! test/java/util/ServiceLoader/badfactories/throwsexception/ProviderFactory.java ! test/java/util/ServiceLoader/badfactories/throwsexception/Service.java ! test/java/util/ServiceLoader/badproviders/ctornotpublic/Provider.java ! test/java/util/ServiceLoader/badproviders/ctornotpublic/Service.java ! test/java/util/ServiceLoader/badproviders/notasubtype/Provider.java ! test/java/util/ServiceLoader/badproviders/notpublic/Provider.java ! test/java/util/ServiceLoader/badproviders/notpublic/Service.java ! test/java/util/ServiceLoader/badproviders/throwsexception/Provider.java ! test/java/util/ServiceLoader/badproviders/throwsexception/Service.java ! test/java/util/ServiceLoader/classpath/pearscript/META-INF/services/javax.script.ScriptEngineFactory ! test/java/util/ServiceLoader/classpath/pearscript/org/pear/PearScript.java ! test/java/util/ServiceLoader/classpath/pearscript/org/pear/PearScriptEngineFactory.java ! test/java/util/ServiceLoader/inheritance/NoInheritanceTest.java ! test/java/util/ServiceLoader/inheritance/test/module-info.java ! test/java/util/ServiceLoader/inheritance/test/p/Main.java ! test/java/util/ServiceLoader/modules/bananascript/module-info.java ! test/java/util/ServiceLoader/modules/bananascript/org/banana/BananaScript.java ! test/java/util/ServiceLoader/modules/bananascript/org/banana/BananaScriptEngineFactory.java ! test/java/util/ServiceLoader/modules/test1/module-info.java ! test/java/util/ServiceLoader/modules/test1/p/ProviderFactory.java ! test/java/util/ServiceLoader/modules/test1/p/Service.java ! test/java/util/ServiceLoader/modules/test2/module-info.java ! test/java/util/ServiceLoader/modules/test2/p/Provider.java ! test/java/util/ServiceLoader/modules/test2/p/Service.java ! test/java/util/ServiceLoader/nouses/NoUsesTest.java ! test/java/util/ServiceLoader/nouses/test/module-info.java ! test/java/util/ServiceLoader/nouses/test/p/Main.java ! test/jdk/modules/etc/VerifyModuleDelegation.java ! test/jdk/modules/open/Basic.java ! test/tools/launcher/modules/addexports/manifest/AddExportsAndOpensInManifest.java ! test/tools/launcher/modules/illegalaccess/IllegalAccessTest.java ! test/tools/launcher/modules/illegalaccess/TryAccess.java ! test/tools/launcher/modules/illegalaccess/modules/m/module-info.java ! test/tools/launcher/modules/illegalaccess/modules/m/p/Type.java From mandy.chung at oracle.com Sat Jun 17 15:19:58 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Sat, 17 Jun 2017 08:19:58 -0700 Subject: Review Request JDK-8182416: Clean up module-info.java like move requires transitive adjacent to exports In-Reply-To: References: <78E7C761-8462-414D-B1B6-E42731DBF197@oracle.com> Message-ID: <26847663-F43F-4F3A-AF84-719351ECFCE0@oracle.com> > On Jun 17, 2017, at 7:26 AM, Alan Bateman wrote: > > On 17/06/2017 07:27, Mandy Chung wrote: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8182416/webrev.00/ >> >> This patch cleans up module-info.java mainly moving requires transitive >> before exports, group exports/opens (packages) together and uses/provides >> (services) next. >> >> Document if a module is upgradeable. >> >> jdeps ?-generate-module-info is also updated to list requires transitive >> before exports. >> > This looks okay to me, I just wonder if jdk.xml.ws and jdk.xml.bind modules need the upgradeable note given that they aren't standard modules. > Good point and will drop that sentence. > A minor nit in java.corba where it has "

This ...". All the others have a space. > Fixed. > For jdeps then should it emit a blank line between the groupings to be consistent with the proposed layout? Updated webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8182416/webrev.01/ Mandy From Alan.Bateman at oracle.com Sat Jun 17 15:48:03 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 17 Jun 2017 16:48:03 +0100 Subject: Review Request JDK-8182416: Clean up module-info.java like move requires transitive adjacent to exports In-Reply-To: <26847663-F43F-4F3A-AF84-719351ECFCE0@oracle.com> References: <78E7C761-8462-414D-B1B6-E42731DBF197@oracle.com> <26847663-F43F-4F3A-AF84-719351ECFCE0@oracle.com> Message-ID: On 17/06/2017 16:19, Mandy Chung wrote: >> On Jun 17, 2017, at 7:26 AM, Alan Bateman wrote: >> >> On 17/06/2017 07:27, Mandy Chung wrote: >>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8182416/webrev.00/ >>> >>> This patch cleans up module-info.java mainly moving requires transitive >>> before exports, group exports/opens (packages) together and uses/provides >>> (services) next. >>> >>> Document if a module is upgradeable. >>> >>> jdeps ?-generate-module-info is also updated to list requires transitive >>> before exports. >>> >> This looks okay to me, I just wonder if jdk.xml.ws and jdk.xml.bind modules need the upgradeable note given that they aren't standard modules. >> > Good point and will drop that sentence. > >> A minor nit in java.corba where it has "

This ...". All the others have a space. >> > Fixed. > >> For jdeps then should it emit a blank line between the groupings to be consistent with the proposed layout? > Updated webrev: > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8182416/webrev.01/ > Looks good. -Alan From jonathan.gibbons at oracle.com Sun Jun 18 16:19:42 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Sun, 18 Jun 2017 09:19:42 -0700 Subject: Explicitly empty sourcepath regression In-Reply-To: References: Message-ID: <9053b531-eb9d-8731-e622-ee90b3437eea@oracle.com> On 06/15/2017 09:07 PM, Pepper Lebeck-Jobe wrote: > *Question* > Why must the source files which make up a module be on the source path for > the module to be compiled? There are a number of aspects to the answer for this. First, some background. It has been a decision of long standing that the module membership of a compilation unit is determined by the "host system", which in the case of command-line javac, means by the position of the file in the file system. The alternative, which was rejected early on, was to have to edit every single compilation unit in code that was being modularized to have a module declaration at the top, preceding the package declaration. While it may seem to follow that for any compilation unit, you could just look in some appropriate enclosing directory to find the module declaration, there are some important use cases where that is not enough. Generally, these use cases are when the source for a module is spread across different directory hierarchies with different directories for the package root. The two most common cases of this are when some of the source for a module is generated, or when the source is a combination of some platform-independent code and some platform specific code. The ability to merge directory hierarchies like this is managed by using paths, as in source paths or class paths. Now, to some more specific reasons for the design decision. First ... consistency. It has always been the case for Jigsaw javac that when compiling code from multiple modules together, all the source files given on the command line had to be present on the module source path .. meaning, on the source path for a module on the module source path. That was always required for the reasons described earlier, to be able to determine the module membership of each source file specified on the comment line. That was initially different from the case of compiling a single module, which initially was more like compiling "traditional" non-modular code. In time, it became clear that was a bad choice and it was better to have the compilation requirements for all modular code be more consistent, whether compiling one module or many. Second ... to avoid obscure errors. In the initial design, when compiling a single module, javac tried to infer the module being compiled from the presence of a module declaration in a compilation unit specified on the command line, or on the source path or a module declaration on the class path. That led to the possibility of errors in which the module membership of a compilation unit specified on the command line (as determined by its position in the file system) could be different from the inferred module being compiled. For example, consider the case where the source path is empty, and the command line contains the source files for the module declaration for one module, and the class declarations for different module. There is no way, in that case, for javac to detect the misconfiguration and give a meaningful message. The solution was to require that when compiling modular code for a single module, all source files must appear on the source path so that javac can ensure that all sources files are part of the same module. That all being said, I understand the concerns that this sets up the possibility of files being implicitly compiled when that is not desired, by virtue of being found on the source path. I also agree that -implicit:none is not an ideal solution to the issue. In time, we could consider a new option to better address the problem. In the meantime, the short term options are to either synthesize a suitable source directory with links, or to use the Compiler API to provide a custom file manager that uses an equivalent synthetic source path. -- Jon From pepper at gradle.com Mon Jun 19 03:07:00 2017 From: pepper at gradle.com (Pepper Lebeck-Jobe) Date: Mon, 19 Jun 2017 03:07:00 +0000 Subject: Explicitly empty sourcepath regression In-Reply-To: <9053b531-eb9d-8731-e622-ee90b3437eea@oracle.com> References: <9053b531-eb9d-8731-e622-ee90b3437eea@oracle.com> Message-ID: A few (fairly inconsequential comments in-line and then an unresolved question at the bottom. Sorry to put the most important part last. Feel free to skip ahead to that question as I think it is the most important thing in the mail. On Mon, Jun 19, 2017 at 12:30 AM Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > > > On 06/15/2017 09:07 PM, Pepper Lebeck-Jobe wrote: > > *Question* > > Why must the source files which make up a module be on the source path > for > > the module to be compiled? > > There are a number of aspects to the answer for this. > > First, some background. > > It has been a decision of long standing that the module membership of a > compilation > unit is determined by the "host system", which in the case of > command-line javac, > means by the position of the file in the file system. The alternative, > which was rejected > early on, was to have to edit every single compilation unit in code that > was being > modularized to have a module declaration at the top, preceding the > package declaration. > I'm wondering if another alternative was considered. Namely, require explicit declaration in the module declaration for all packages which make up the module (even if they aren't exported by the module.) This would provide the same mapping as having each compilation unit declare module membership, but it would be consolidated in the module description and not require specification for every class declaration as membership in a package would imply membership in the module which has declared ownership of that package. > While it may seem to follow that for any compilation unit, you could > just look in some > appropriate enclosing directory to find the module declaration, there > are some > important use cases where that is not enough. Generally, these use cases > are when > the source for a module is spread across different directory hierarchies > with different > directories for the package root. The two most common cases of this are > when > some of the source for a module is generated, or when the source is a > combination > of some platform-independent code and some platform specific code. The > ability to > merge directory hierarchies like this is managed by using paths, as in > source paths > or class paths. > > Now, to some more specific reasons for the design decision. > > First ... consistency. It has always been the case for Jigsaw javac that > when compiling > code from multiple modules together, all the source files given on the > command line > had to be present on the module source path .. meaning, on the source > path for > a module on the module source path. That was always required for the > reasons described > earlier, to be able to determine the module membership of each source > file specified on > the comment line. That was initially different from the case of > compiling a single module, > which initially was more like compiling "traditional" non-modular code. > In time, it became > clear that was a bad choice and it was better to have the compilation > requirements > for all modular code be more consistent, whether compiling one module or > many. > But, right now, I don't think these requirements actually are consistent between compiling one module or many. For example, imagine this directory layout. src/ module-info.java com/ foo/ ModuleClass.java otherSrc/ com/ bar/ NotAModuleClass.java If I compile with this command line: javac -d build/classes/foo.module -sourcepath src:otherSrc $(find . -name "*.java") Then, javac will assume that com.bar.NotAModuleClass is a member of `foo.module` (the module declared in src/module-info.java) even though it is not rooted in the same filesystem directory with the module declaration file or in a directory with the same name as the declared module. Is the reasoning behind the design of this behavior summed up by this rule: if (there is exactly one module declaration among the sources on the command line) { all source files visible on the sourcepath must be part of that module } I'm not saying that this is a totally unreasonable rule. But, it does seem less strict than what would happen if multiple modules were being compiled with the --module-source-path argument and there was some rouge class file which wasn't on the --module-source-path but was specified on the command-line. Second ... to avoid obscure errors. In the initial design, when > compiling a single module, > javac tried to infer the module being compiled from the presence of a > module declaration > in a compilation unit specified on the command line, or on the source > path or a module > declaration on the class path. That led to the possibility of errors in > which the module > membership of a compilation unit specified on the command line (as > determined by its > position in the file system) could be different from the inferred module > being compiled. > For example, consider the case where the source path is empty, and the > command line > contains the source files for the module declaration for one module, and > the class > declarations for different module. There is no way, in that case, for > javac to detect the > misconfiguration and give a meaningful message. The solution was to > require that when > compiling modular code for a single module, all source files must appear > on the source > path so that javac can ensure that all sources files are part of the > same module. > I guess this answers my previous question. So, yes, the rule is: if a source file is both specified on the command line with a module declaration and in the sourcepath, then it must be meant to be part of the module being declared. I do believe this makes the semantics of the sourcepath difficult to understand because it has a different/additional meaning depending on whether or not a module-info.java file is among the sources being compiled. > That all being said, I understand the concerns that this sets up the > possibility of > files being implicitly compiled when that is not desired, by virtue of > being found > on the source path. I also agree that -implicit:none is not an ideal > solution to the > issue. In time, we could consider a new option to better address the > problem. > In the meantime, the short term options are to either synthesize a > suitable source > directory with links, or to use the Compiler API to provide a custom > file manager that > uses an equivalent synthetic source path. > In the short-term, we can probably synthesize a temporary directory with all the source files we know about and use that directory as the only element on the sourcepath when we know we are compiling a single module. -- Jon > I really appreciate your detailed explanation of why the design decisions have been made the way they have, but I feel like I'm still missing one important piece of the puzzle. According to this documentation: http://docs.oracle.com/javase/9/tools/javac.htm#JSWOR627 --- If -classpath, -classpath,, or -cp aren?t specified, then the user class path is the current directory. If the -sourcepath option isn?t specified, then the user class path is also searched for source files. --- So, if the default behavior (when -sourcepath is not specified) is essentially to treat the classpath as the sourcepath. Why in my example project here: https://github.com/eljobe/modules does this work javac -cp '' -d build/classes $(find src -name "*.java") but this fail javac -sourcepath '' -cp '' -d build/classes $(find src -name "*.java") It seems to me, that according to the documentation, this is only the difference between an implicitly (because the -cp option is empty) empty sourcepath and an explicitly empty sourcepath. One possibility is that the documentation is wrong and the default sourcepath includes some directories in addition to the classpath. In which case, I'd like to know what those directories are. I'm not sure what other explanation would cause this difference in behavior. Thanks again, Pepper From Alan.Bateman at oracle.com Tue Jun 20 10:20:16 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 20 Jun 2017 11:20:16 +0100 Subject: 8182482: Module System spec updates Message-ID: <8ca89ddf-03b6-9c68-2ea3-1a15512e6595@oracle.com> We have two javadoc/spec updates that I'd like to get into the JDK 9 Initial Release Candidate that is scheduled for this week. The spec updates are for two issues: 1. ServiceLoader: The API spec has been updated significantly to support modules but it needs another round of update to do clean-up to get it more readable and consistent, and also to align it with the JLS. Most of reorganization and re-wording has been proposed by Alex. Joe Darcy has also proposed a few adjustments. 2. Upgradable modules aren't specified anywhere. Java SE will designate a number of standard modules as upgradeable but we don't have anywhere in the docs to link to that or describe how the upgraded versions are used in preference to the modules built into the environment. The webrev with the proposed (docs only, no implementation) changes is here: http://cr.openjdk.java.net/~alanb/8182482/webrev/index.html The ServiceLoader diffs are hard to read. It might be easier to read the generated javadoc: http://cr.openjdk.java.net/~alanb/8182482/docs/java/util/ServiceLoader.html -Alan From forax at univ-mlv.fr Tue Jun 20 10:39:15 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 20 Jun 2017 12:39:15 +0200 (CEST) Subject: 8182482: Module System spec updates In-Reply-To: <8ca89ddf-03b6-9c68-2ea3-1a15512e6595@oracle.com> References: <8ca89ddf-03b6-9c68-2ea3-1a15512e6595@oracle.com> Message-ID: <187219535.968699.1497955155764.JavaMail.zimbra@u-pem.fr> Hi Alan, the doc is clearly better. Can you change A service is a single type, usually an interface or abstract class. A concrete class can be used, but this is not recommended. to A service is a single type, usually an interface. An abstract class or a concrete class can be used, but this is not recommended. An abstract class has a constructor so you can observe when a service implementation is instantiated by the ServiceLoader, which may make the code dependent of the loading order of the service implementations. So using an abstract class for a service implementation is also a bad idea. regards, R?mi ----- Mail original ----- > De: "Alan Bateman" > ?: "jigsaw-dev" > Envoy?: Mardi 20 Juin 2017 12:20:16 > Objet: 8182482: Module System spec updates > We have two javadoc/spec updates that I'd like to get into the JDK 9 > Initial Release Candidate that is scheduled for this week. > > The spec updates are for two issues: > > 1. ServiceLoader: The API spec has been updated significantly to support > modules but it needs another round of update to do clean-up to get it > more readable and consistent, and also to align it with the JLS. Most > of reorganization and re-wording has been proposed by Alex. Joe Darcy > has also proposed a few adjustments. > > 2. Upgradable modules aren't specified anywhere. Java SE will designate > a number of standard modules as upgradeable but we don't have anywhere > in the docs to link to that or describe how the upgraded versions are > used in preference to the modules built into the environment. > > The webrev with the proposed (docs only, no implementation) changes is here: > http://cr.openjdk.java.net/~alanb/8182482/webrev/index.html > > The ServiceLoader diffs are hard to read. It might be easier to read the > generated javadoc: > http://cr.openjdk.java.net/~alanb/8182482/docs/java/util/ServiceLoader.html > > -Alan From Alan.Bateman at oracle.com Tue Jun 20 11:30:20 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 20 Jun 2017 12:30:20 +0100 Subject: 8182482: Module System spec updates In-Reply-To: <187219535.968699.1497955155764.JavaMail.zimbra@u-pem.fr> References: <8ca89ddf-03b6-9c68-2ea3-1a15512e6595@oracle.com> <187219535.968699.1497955155764.JavaMail.zimbra@u-pem.fr> Message-ID: On 20/06/2017 11:39, Remi Forax wrote: > Hi Alan, > the doc is clearly better. > > Can you change > A service is a single type, usually an interface or abstract class. A concrete class can be used, but this is not recommended. > to > A service is a single type, usually an interface. An abstract class or a concrete class can be used, but this is not recommended. > > An abstract class has a constructor so you can observe when a service implementation is instantiated by the ServiceLoader, which may make the code dependent of the loading order of the service implementations. So using an abstract class for a service implementation is also a bad idea. > There shouldn't be any issue using an abstract class as the service. Sure, most developers will choose an interface but we have many examples where the service type is an abstract class (and there are corner cases with security where enforcement isn't possible when using an interface). The service provider can be abstract class too but only when it defines a public static provider method. I don't understand your point about an abstract class having a constructor. If it doesn't a static provider method then it won't compile as a module (it won't run either as it can't be instantiated). -Alan From mark.reinhold at oracle.com Tue Jun 20 11:55:57 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 20 Jun 2017 13:55:57 +0200 Subject: 8182482: Module System spec updates In-Reply-To: <8ca89ddf-03b6-9c68-2ea3-1a15512e6595@oracle.com> References: <8ca89ddf-03b6-9c68-2ea3-1a15512e6595@oracle.com> Message-ID: <20170620135557.582057517@eggemoggin.niobe.net> 2017/6/20 12:20:16 +0200, alan.bateman at oracle.com: > ... > > The webrev with the proposed (docs only, no implementation) changes is here: > http://cr.openjdk.java.net/~alanb/8182482/webrev/index.html > > The ServiceLoader diffs are hard to read. It might be easier to read the > generated javadoc: > http://cr.openjdk.java.net/~alanb/8182482/docs/java/util/ServiceLoader.html Looks good -- very good, in fact! Thanks for rewriting this. - Mark From Rony.Flatscher at wu.ac.at Tue Jun 20 13:02:25 2017 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Tue, 20 Jun 2017 15:02:25 +0200 Subject: 8182482: Module System spec updates In-Reply-To: <8ca89ddf-03b6-9c68-2ea3-1a15512e6595@oracle.com> References: <8ca89ddf-03b6-9c68-2ea3-1a15512e6595@oracle.com> Message-ID: Just a side-note: when printing with the latest Firefox the headers cover part of the text, which makes printing of such Javadocs somewhat useless. Not sure where to report this, so posting it here. The printout of the generated javadoc is enclosed or if the attachment gets stripped can be fetched from this location: ---rony On 20.06.2017 12:20, Alan Bateman wrote: > We have two javadoc/spec updates that I'd like to get into the JDK 9 Initial Release Candidate > that is scheduled for this week. > > The spec updates are for two issues: > > 1. ServiceLoader: The API spec has been updated significantly to support modules but it needs > another round of update to do clean-up to get it more readable and consistent, and also to align > it with the JLS. Most of reorganization and re-wording has been proposed by Alex. Joe Darcy has > also proposed a few adjustments. > > 2. Upgradable modules aren't specified anywhere. Java SE will designate a number of standard > modules as upgradeable but we don't have anywhere in the docs to link to that or describe how the > upgraded versions are used in preference to the modules built into the environment. > > The webrev with the proposed (docs only, no implementation) changes is here: > http://cr.openjdk.java.net/~alanb/8182482/webrev/index.html > > The ServiceLoader diffs are hard to read. It might be easier to read the generated javadoc: > http://cr.openjdk.java.net/~alanb/8182482/docs/java/util/ServiceLoader.html > > -Alan From forax at univ-mlv.fr Tue Jun 20 13:29:47 2017 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Tue, 20 Jun 2017 15:29:47 +0200 (CEST) Subject: 8182482: Module System spec updates In-Reply-To: References: <8ca89ddf-03b6-9c68-2ea3-1a15512e6595@oracle.com> <187219535.968699.1497955155764.JavaMail.zimbra@u-pem.fr> Message-ID: <1951638749.1102710.1497965387052.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Alan Bateman" > ?: "Remi Forax" > Cc: "jigsaw-dev" > Envoy?: Mardi 20 Juin 2017 13:30:20 > Objet: Re: 8182482: Module System spec updates > On 20/06/2017 11:39, Remi Forax wrote: >> Hi Alan, >> the doc is clearly better. >> >> Can you change >> A service is a single type, usually an interface or abstract class. A concrete >> class can be used, but this is not recommended. >> to >> A service is a single type, usually an interface. An abstract class or a >> concrete class can be used, but this is not recommended. >> >> An abstract class has a constructor so you can observe when a service >> implementation is instantiated by the ServiceLoader, which may make the code >> dependent of the loading order of the service implementations. So using an >> abstract class for a service implementation is also a bad idea. >> > There shouldn't be any issue using an abstract class as the service. > Sure, most developers will choose an interface but we have many examples > where the service type is an abstract class (and there are corner cases > with security where enforcement isn't possible when using an interface). Abstract classes are evil when the abstract class and the concrete class are not maintained by the same people, if the code of the abstract class change for whatever reason, it will break the subclasses. It's just bad design. And the code that enforce security do not have to be in the abstract class constructor, debugging a constructor in general is harder than any other methods because the object is partially initialized. When you are executing the constructor of an abstract class the object corresponding to this is not fully initialized. You can always 'layer up' and use factories instead. > > The service provider can be abstract class too but only when it defines > a public static provider method. yes, here, it's less problematic because in that case the abstract class and all subclasses will be maintained together. > > I don't understand your point about an abstract class having a > constructor. If it doesn't a static provider method then it won't > compile as a module (it won't run either as it can't be instantiated). ok, let's focus on abstract class defining a service. > > -Alan R?mi From mandy.chung at oracle.com Tue Jun 20 13:40:34 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 20 Jun 2017 06:40:34 -0700 Subject: 8182482: Module System spec updates In-Reply-To: <8ca89ddf-03b6-9c68-2ea3-1a15512e6595@oracle.com> References: <8ca89ddf-03b6-9c68-2ea3-1a15512e6595@oracle.com> Message-ID: <80814F6A-FA3F-4EC9-B7E6-31105C6BE25B@oracle.com> > On Jun 20, 2017, at 3:20 AM, Alan Bateman wrote: > > The webrev with the proposed (docs only, no implementation) changes is here: > http://cr.openjdk.java.net/~alanb/8182482/webrev/index.html > > The ServiceLoader diffs are hard to read. It might be easier to read the generated javadoc: > http://cr.openjdk.java.net/~alanb/8182482/docs/java/util/ServiceLoader.html > Looks good. Mandy From uschindler at apache.org Tue Jun 20 13:48:35 2017 From: uschindler at apache.org (Uwe Schindler) Date: Tue, 20 Jun 2017 15:48:35 +0200 Subject: 8182482: Module System spec updates In-Reply-To: <8ca89ddf-03b6-9c68-2ea3-1a15512e6595@oracle.com> References: <8ca89ddf-03b6-9c68-2ea3-1a15512e6595@oracle.com> Message-ID: <016801d2e9cb$ecbbcfd0$c6336f70$@apache.org> Hey Alan, very nice. Reads good. Although not in this patch, I most like the warning about the ServiceLoader#load(Class) method, context classloader, and caching JVM wide! This is also a great improvement in comparison to Java 8! We currently refactor Lucene because of this context classloader stupidness! 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: Tuesday, June 20, 2017 12:20 PM > To: jigsaw-dev > Subject: 8182482: Module System spec updates > > We have two javadoc/spec updates that I'd like to get into the JDK 9 > Initial Release Candidate that is scheduled for this week. > > The spec updates are for two issues: > > 1. ServiceLoader: The API spec has been updated significantly to support > modules but it needs another round of update to do clean-up to get it > more readable and consistent, and also to align it with the JLS. Most > of reorganization and re-wording has been proposed by Alex. Joe Darcy > has also proposed a few adjustments. > > 2. Upgradable modules aren't specified anywhere. Java SE will designate > a number of standard modules as upgradeable but we don't have anywhere > in the docs to link to that or describe how the upgraded versions are > used in preference to the modules built into the environment. > > The webrev with the proposed (docs only, no implementation) changes is > here: > http://cr.openjdk.java.net/~alanb/8182482/webrev/index.html > > The ServiceLoader diffs are hard to read. It might be easier to read the > generated javadoc: > http://cr.openjdk.java.net/~alanb/8182482/docs/java/util/ServiceLoader.ht > ml > > -Alan From Alan.Bateman at oracle.com Tue Jun 20 13:51:23 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 20 Jun 2017 14:51:23 +0100 Subject: 8182482: Module System spec updates In-Reply-To: References: <8ca89ddf-03b6-9c68-2ea3-1a15512e6595@oracle.com> Message-ID: On 20/06/2017 14:02, Rony G. Flatscher wrote: > Just a side-note: when printing with the latest Firefox the headers cover part of the text, which > makes printing of such Javadocs somewhat useless. Not sure where to report this, so posting it here. > > The printout of the generated javadoc is enclosed or if the attachment gets stripped can be fetched > from this location: > > I'm not 100% sure but it looks it hasn't read the CSS, maybe it's security setting that prevents it reading "../../stylesheet.css" ? -Alan From alex.buckley at oracle.com Tue Jun 20 18:09:14 2017 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 20 Jun 2017 11:09:14 -0700 Subject: 8182482: Module System spec updates In-Reply-To: <1951638749.1102710.1497965387052.JavaMail.zimbra@u-pem.fr> References: <8ca89ddf-03b6-9c68-2ea3-1a15512e6595@oracle.com> <187219535.968699.1497955155764.JavaMail.zimbra@u-pem.fr> <1951638749.1102710.1497965387052.JavaMail.zimbra@u-pem.fr> Message-ID: <594964CA.1000301@oracle.com> Hi Remi, On 6/20/2017 6:29 AM, forax at univ-mlv.fr wrote: > ok, let's focus on abstract class defining a service. I would be happy for the "Designing services" section to give more advice about the tradeoffs between an interface and an abstract class. Two sentences, written in a style that leads a junior developer but does not judge them if they don't follow the advice. Can you write it? :- ----- A service is a single type, usually an interface or abstract class. ***REMI'S TEXT HERE*** A concrete class can be used, but this is not recommended. The type may have any accessibility. The methods of a service are highly ... ----- Alex From Rony.Flatscher at wu.ac.at Tue Jun 20 19:51:48 2017 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Tue, 20 Jun 2017 21:51:48 +0200 Subject: 8182482: Module System spec updates In-Reply-To: <8ca89ddf-03b6-9c68-2ea3-1a15512e6595@oracle.com> References: <8ca89ddf-03b6-9c68-2ea3-1a15512e6595@oracle.com> Message-ID: Maybe a few little things: * in the Errors section, reason # 4 states: The service provider class file has more than one public static no-args method named "provider". There could be no more than one public static no-args method named "provider" in a class file, so this error reason should not be possible? * in the "stream" (method-detail) description, second paragraph, second sentence, there is a "the" too many: If a service provider cannot be loaded for any of *the* *the* reasons... * in the "load" (method-detail for: "public static ServiceLoader load?(Class service, ClassLoader loader)" ) description, section "Step 1", paragraph starting with "Ordering:", last sentence, a "the" is missing "... in same class loader ...", should read: "... in *the* same class loader..." * Documentation of "Parameters:" in all of the "load" and "loadInstalled" method-details reads: "service - The interface or abstract class representing the service", which may wrongly imply that a concrete class may not be supplied; for completeness of the documentation it should document that it may be a concrete class as well or just talk about something like: "Class representing the service, usually an interface class" to encourage usage of interface classes * in the "findFirst" (method-detail) description, second paragraph, second (last) sentence may have an "are" too many: "If there are no service providers *are* located then it uses a default implementation." The text explains ServiceLoader very clearly! ---rony On 20.06.2017 12:20, Alan Bateman wrote: > We have two javadoc/spec updates that I'd like to get into the JDK 9 Initial Release Candidate > that is scheduled for this week. > > The spec updates are for two issues: > > 1. ServiceLoader: The API spec has been updated significantly to support modules but it needs > another round of update to do clean-up to get it more readable and consistent, and also to align > it with the JLS. Most of reorganization and re-wording has been proposed by Alex. Joe Darcy has > also proposed a few adjustments. > > 2. Upgradable modules aren't specified anywhere. Java SE will designate a number of standard > modules as upgradeable but we don't have anywhere in the docs to link to that or describe how the > upgraded versions are used in preference to the modules built into the environment. > > The webrev with the proposed (docs only, no implementation) changes is here: > http://cr.openjdk.java.net/~alanb/8182482/webrev/index.html > > The ServiceLoader diffs are hard to read. It might be easier to read the generated javadoc: > http://cr.openjdk.java.net/~alanb/8182482/docs/java/util/ServiceLoader.html > > -Alan From pepper at gradle.com Wed Jun 21 01:23:11 2017 From: pepper at gradle.com (Pepper Lebeck-Jobe) Date: Wed, 21 Jun 2017 01:23:11 +0000 Subject: Explicitly empty sourcepath regression In-Reply-To: References: <9053b531-eb9d-8731-e622-ee90b3437eea@oracle.com> Message-ID: I'm still very interested in hearing your thoughts on the issues I brought up in the previous post to this thread, but I wanted to share an update with this group about how the Gradle team has decided to handle the sourcepath situation for our 4.1 release. We have decided to just drop the `-sourcepath ""` arguments from our `javac` invocations when we know that we are compiling for Java 9 AND that there is a `mould-info.java` on the command-line. We considered writing our own `JavaFileManager` implementation to wrap the standard `JavaFileManager` and filter results from calls to `list()` with `SOURCE_PATH` to eliminate any source files which were not already known to Gradle. However, this would have meant that we would need to synthesize a sourcepath which contained all of the source files we were passing on the command-line so that the standard `JavaFileManager` could find the files in the first place. Rather than tackle this complexity at this point, we decided to settle for the implicitly empty `sourcepath` which seems to work when compiling a single module. If you change the behavior of the implicitly empty `sourcepath` to match that of the explicitly empty `sourcepath` Gradle will not work with the release of the JDK that makes that change. So, it would be nice to get a warning if the decision is made to change those semantics to match. Thanks, Pepper On Mon, Jun 19, 2017 at 11:07 AM Pepper Lebeck-Jobe wrote: > A few (fairly inconsequential comments in-line and then an unresolved > question at the bottom. Sorry to put the most important part last. Feel > free to skip ahead to that question as I think it is the most important > thing in the mail. > > On Mon, Jun 19, 2017 at 12:30 AM Jonathan Gibbons < > jonathan.gibbons at oracle.com> wrote: > >> >> >> On 06/15/2017 09:07 PM, Pepper Lebeck-Jobe wrote: >> > *Question* >> > Why must the source files which make up a module be on the source path >> for >> > the module to be compiled? >> >> There are a number of aspects to the answer for this. >> >> First, some background. >> >> It has been a decision of long standing that the module membership of a >> compilation >> unit is determined by the "host system", which in the case of >> command-line javac, >> means by the position of the file in the file system. The alternative, >> which was rejected >> early on, was to have to edit every single compilation unit in code that >> was being >> modularized to have a module declaration at the top, preceding the >> package declaration. >> > > I'm wondering if another alternative was considered. Namely, require > explicit declaration in the module declaration for all packages which make > up the module (even if they aren't exported by the module.) This would > provide the same mapping as having each compilation unit declare module > membership, but it would be consolidated in the module description and not > require specification for every class declaration as membership in a > package would imply membership in the module which has declared ownership > of that package. > > >> While it may seem to follow that for any compilation unit, you could >> just look in some >> appropriate enclosing directory to find the module declaration, there >> are some >> important use cases where that is not enough. Generally, these use cases >> are when >> the source for a module is spread across different directory hierarchies >> with different >> directories for the package root. The two most common cases of this are >> when >> some of the source for a module is generated, or when the source is a >> combination >> of some platform-independent code and some platform specific code. The >> ability to >> merge directory hierarchies like this is managed by using paths, as in >> source paths >> or class paths. >> >> Now, to some more specific reasons for the design decision. >> >> First ... consistency. It has always been the case for Jigsaw javac that >> when compiling >> code from multiple modules together, all the source files given on the >> command line >> had to be present on the module source path .. meaning, on the source >> path for >> a module on the module source path. That was always required for the >> reasons described >> earlier, to be able to determine the module membership of each source >> file specified on >> the comment line. That was initially different from the case of >> compiling a single module, >> which initially was more like compiling "traditional" non-modular code. >> In time, it became >> clear that was a bad choice and it was better to have the compilation >> requirements >> for all modular code be more consistent, whether compiling one module or >> many. >> > > But, right now, I don't think these requirements actually are consistent > between compiling one module or many. For example, imagine this directory > layout. > > src/ > module-info.java > com/ > foo/ > ModuleClass.java > otherSrc/ > com/ > bar/ > NotAModuleClass.java > > If I compile with this command line: > javac -d build/classes/foo.module -sourcepath src:otherSrc $(find . -name > "*.java") > > Then, javac will assume that com.bar.NotAModuleClass is a member of > `foo.module` (the module declared in src/module-info.java) even though it > is not rooted in the same filesystem directory with the module declaration > file or in a directory with the same name as the declared module. Is the > reasoning behind the design of this behavior summed up by this rule: > > if (there is exactly one module declaration among the sources on the > command line) { > all source files visible on the sourcepath must be part of that module > } > > I'm not saying that this is a totally unreasonable rule. But, it does seem > less strict than what would happen if multiple modules were being compiled > with the --module-source-path argument and there was some rouge class file > which wasn't on the --module-source-path but was specified on the > command-line. > > Second ... to avoid obscure errors. In the initial design, when >> compiling a single module, >> javac tried to infer the module being compiled from the presence of a >> module declaration >> in a compilation unit specified on the command line, or on the source >> path or a module >> declaration on the class path. That led to the possibility of errors in >> which the module >> membership of a compilation unit specified on the command line (as >> determined by its >> position in the file system) could be different from the inferred module >> being compiled. >> For example, consider the case where the source path is empty, and the >> command line >> contains the source files for the module declaration for one module, and >> the class >> declarations for different module. There is no way, in that case, for >> javac to detect the >> misconfiguration and give a meaningful message. The solution was to >> require that when >> compiling modular code for a single module, all source files must appear >> on the source >> path so that javac can ensure that all sources files are part of the >> same module. >> > > I guess this answers my previous question. So, yes, the rule is: if a > source file is both specified on the command line with a module declaration > and in the sourcepath, then it must be meant to be part of the module being > declared. > > I do believe this makes the semantics of the sourcepath difficult to > understand because it has a different/additional meaning depending on > whether or not a module-info.java file is among the sources being compiled. > > >> That all being said, I understand the concerns that this sets up the >> possibility of >> files being implicitly compiled when that is not desired, by virtue of >> being found >> on the source path. I also agree that -implicit:none is not an ideal >> solution to the >> issue. In time, we could consider a new option to better address the >> problem. >> In the meantime, the short term options are to either synthesize a >> suitable source >> directory with links, or to use the Compiler API to provide a custom >> file manager that >> uses an equivalent synthetic source path. >> > > In the short-term, we can probably synthesize a temporary directory with > all the source files we know about and use that directory as the only > element on the sourcepath when we know we are compiling a single module. > > -- Jon >> > > I really appreciate your detailed explanation of why the design decisions > have been made the way they have, but I feel like I'm still missing one > important piece of the puzzle. > > According to this documentation: > http://docs.oracle.com/javase/9/tools/javac.htm#JSWOR627 > > --- > If -classpath, -classpath,, or -cp aren?t specified, then the user class > path is the current directory. > > If the -sourcepath option isn?t specified, then the user class path is > also searched for source files. > --- > > So, if the default behavior (when -sourcepath is not specified) is > essentially to treat the classpath as the sourcepath. > > Why in my example project here: https://github.com/eljobe/modules > does this work > javac -cp '' -d build/classes $(find src -name "*.java") > but this fail > javac -sourcepath '' -cp '' -d build/classes $(find src -name "*.java") > > It seems to me, that according to the documentation, this is only the > difference between an implicitly (because the -cp option is empty) empty > sourcepath and an explicitly empty sourcepath. > > One possibility is that the documentation is wrong and the default > sourcepath includes some directories in addition to the classpath. In which > case, I'd like to know what those directories are. > > I'm not sure what other explanation would cause this difference in > behavior. > > Thanks again, > Pepper > From huaming.li at oracle.com Wed Jun 21 06:10:14 2017 From: huaming.li at oracle.com (Hamlin Li) Date: Wed, 21 Jun 2017 14:10:14 +0800 Subject: 8182482: Module System spec updates In-Reply-To: References: <8ca89ddf-03b6-9c68-2ea3-1a15512e6595@oracle.com> Message-ID: <3424080d-264c-ea9e-1587-0093428d5bb1@oracle.com> On 2017/6/21 3:51, Rony G. Flatscher wrote: > Maybe a few little things: > > * in the Errors section, reason # 4 states: > > The service provider class file has more than one public static no-args method named > "provider". > > There could be no more than one public static no-args method named "provider" in a class file, > so this error reason should not be possible? > Hi Rony, It's possible to have 2 public static no-args method "provider" in a service provider *class file*, JVM spec allows it, as method return type is also part of method descriptor. And I still have questions: Why need to have this restriction in java API doc? Will there be corresponding update in JVM spec? When will this restriction be verified, at linking time? Thank you -Hamlin From Alan.Bateman at oracle.com Wed Jun 21 07:51:23 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 21 Jun 2017 08:51:23 +0100 Subject: 8182482: Module System spec updates In-Reply-To: <3424080d-264c-ea9e-1587-0093428d5bb1@oracle.com> References: <8ca89ddf-03b6-9c68-2ea3-1a15512e6595@oracle.com> <3424080d-264c-ea9e-1587-0093428d5bb1@oracle.com> Message-ID: On 21/06/2017 07:10, Hamlin Li wrote: > : > > It's possible to have 2 public static no-args method "provider" in a > service provider *class file*, JVM spec allows it, Right, you can't do this in the Java Language but the JVMS allows it. The most obvious usage of this "feature" is covariant return types where the java compiler will generate a bridge method with the less specific return type from the superclass. In the Core Reflection APIs then getMethods and getMethod need to deal with this so that the user of API only sees the overriding method. > > And I still have questions: > Why need to have this restriction in java API doc? For completeness only as it's one of the reasons why SCE is thrown. Note that it's also not "new" in this update, instead the wording for many of the error cases has been refreshed. > Will there be corresponding update in JVM spec? When will this > restriction be verified, at linking time? No impact. -Alan From huaming.li at oracle.com Wed Jun 21 08:27:30 2017 From: huaming.li at oracle.com (Hamlin Li) Date: Wed, 21 Jun 2017 16:27:30 +0800 Subject: 8182482: Module System spec updates In-Reply-To: References: <8ca89ddf-03b6-9c68-2ea3-1a15512e6595@oracle.com> <3424080d-264c-ea9e-1587-0093428d5bb1@oracle.com> Message-ID: <8803adf2-d1b1-55f2-5eb5-734957e9c160@oracle.com> Hi Alan, Thank you for explanation, it's much clear for me. Besides of it, I have some minor comments about the doc: In section "Timing of provider discovery", it says as below: Each invocation of the|iterator|method returns an|Iterator|that first yields all of the elements cached from previous iteration, in **instantiation order**, and then lazily locates and instantiates any remaining providers, adding each one to the cache in turn. But in API doc for iterator(), it says: Caching: The iterator returned by this method first yields all of the elements of the provider cache, in **the order that they were loaded**. In API doc for findFirst(), it says: Load the first available service provider of this loader's service. By comparing to API doc of iterator() and stream(), should above line be "Load *and *instantiate** the first available service provider of this loader's service." Thank you -Hamlin On 2017/6/21 15:51, Alan Bateman wrote: > On 21/06/2017 07:10, Hamlin Li wrote: >> : >> >> It's possible to have 2 public static no-args method "provider" in a >> service provider *class file*, JVM spec allows it, > Right, you can't do this in the Java Language but the JVMS allows it. > The most obvious usage of this "feature" is covariant return types > where the java compiler will generate a bridge method with the less > specific return type from the superclass. In the Core Reflection APIs > then getMethods and getMethod need to deal with this so that the user > of API only sees the overriding method. > > >> >> And I still have questions: >> Why need to have this restriction in java API doc? > For completeness only as it's one of the reasons why SCE is thrown. > Note that it's also not "new" in this update, instead the wording for > many of the error cases has been refreshed. > > > >> Will there be corresponding update in JVM spec? When will this >> restriction be verified, at linking time? > No impact. > > -Alan From Alan.Bateman at oracle.com Wed Jun 21 11:43:07 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 21 Jun 2017 12:43:07 +0100 Subject: 8182482: Module System spec updates In-Reply-To: <8803adf2-d1b1-55f2-5eb5-734957e9c160@oracle.com> References: <8ca89ddf-03b6-9c68-2ea3-1a15512e6595@oracle.com> <3424080d-264c-ea9e-1587-0093428d5bb1@oracle.com> <8803adf2-d1b1-55f2-5eb5-734957e9c160@oracle.com> Message-ID: <80ed27c0-4b46-25c2-dd83-3707df0dd10e@oracle.com> On 21/06/2017 09:27, Hamlin Li wrote: > : > > > Besides of it, I have some minor comments about the doc: > > > In section "Timing of provider discovery", it says as below: > > Each invocation of the|iterator|method returns an|Iterator|that first > yields all of the elements cached from previous iteration, in > **instantiation order**, and then lazily locates and instantiates any > remaining providers, adding each one to the cache in turn. > > But in API doc for iterator(), it says: > > Caching: The iterator returned by this method first yields all of the > elements of the provider cache, in **the order that they were loaded** > There is an inconsistency here, it would be clearer to say that it's the order that they were loaded and instantiated. This wording has been there since Java SE 6 but I agree it all needs to be re-examined. So at some point there will be another big update to the ServiceLoader javadoc but more likely to be for Java SE 10 given that JDK 9 is at GAC this week. -Alan From Alan.Bateman at oracle.com Wed Jun 21 11:52:57 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 21 Jun 2017 12:52:57 +0100 Subject: 8182482: Module System spec updates In-Reply-To: References: <8ca89ddf-03b6-9c68-2ea3-1a15512e6595@oracle.com> Message-ID: <86513e11-b0dc-e104-5da8-5b925bde0d41@oracle.com> On 20/06/2017 20:51, Rony G. Flatscher wrote: > Maybe a few little things: > > : > > * in the "stream" (method-detail) description, second paragraph, second sentence, there is a "the" > too many: > > If a service provider cannot be loaded for any of *the* *the* reasons... Thanks. > > * in the "load" (method-detail for: "public static ServiceLoader load?(Class service, > ClassLoader loader)" ) description, section "Step 1", paragraph starting with "Ordering:", last > sentence, a "the" is missing "... in same class loader ...", should read: "... in *the* same > class loader..." Thanks. > > * Documentation of "Parameters:" in all of the "load" and "loadInstalled" method-details reads: > "service - The interface or abstract class representing the service", which may wrongly imply > that a concrete class may not be supplied; for completeness of the documentation it should > document that it may be a concrete class as well or just talk about something like: "Class > representing the service, usually an interface class" to encourage usage of interface classes This hasn't changed in this update (you'll see the same in Java SE 8) but I agree it hints that a concrete class is rejected (which it isn't). > > * in the "findFirst" (method-detail) description, second paragraph, second (last) sentence may > have an "are" too many: "If there are no service providers *are* located then it uses a default > implementation." > I noticed this too before pushing the changes so it has been fixed in jdk9/dev. -Alan. From forax at univ-mlv.fr Wed Jun 21 19:49:29 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 21 Jun 2017 21:49:29 +0200 (CEST) Subject: 8182482: Module System spec updates In-Reply-To: <594964CA.1000301@oracle.com> References: <8ca89ddf-03b6-9c68-2ea3-1a15512e6595@oracle.com> <187219535.968699.1497955155764.JavaMail.zimbra@u-pem.fr> <1951638749.1102710.1497965387052.JavaMail.zimbra@u-pem.fr> <594964CA.1000301@oracle.com> Message-ID: <320299585.1808760.1498074569678.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Alex Buckley" > ?: "jigsaw-dev" > Envoy?: Mardi 20 Juin 2017 20:09:14 > Objet: Re: 8182482: Module System spec updates > Hi Remi, > > On 6/20/2017 6:29 AM, forax at univ-mlv.fr wrote: >> ok, let's focus on abstract class defining a service. > > I would be happy for the "Designing services" section to give more > advice about the tradeoffs between an interface and an abstract class. > Two sentences, written in a style that leads a junior developer but does > not judge them if they don't follow the advice. Can you write it? :- sure let's try: if you are wondering when to use an interface and when to use an abstract class, you can use this advice: most of the time you should favor interfaces, unless you want to execute your own code as part of any service implementations like by example when you want to add a security check to validate something about the implementation. I'm sure you will be able to transform it in proper English. > > ----- > A service is a single type, usually an interface or abstract class. > ***REMI'S TEXT HERE*** A concrete class can be used, but this is not > recommended. The type may have any accessibility. > > The methods of a service are highly ... > ----- > > Alex R?mi From huaming.li at oracle.com Thu Jun 22 00:34:00 2017 From: huaming.li at oracle.com (Hamlin Li) Date: Thu, 22 Jun 2017 08:34:00 +0800 Subject: 8182482: Module System spec updates In-Reply-To: <80ed27c0-4b46-25c2-dd83-3707df0dd10e@oracle.com> References: <8ca89ddf-03b6-9c68-2ea3-1a15512e6595@oracle.com> <3424080d-264c-ea9e-1587-0093428d5bb1@oracle.com> <8803adf2-d1b1-55f2-5eb5-734957e9c160@oracle.com> <80ed27c0-4b46-25c2-dd83-3707df0dd10e@oracle.com> Message-ID: <0446de69-45b1-4833-9b14-340ac6fc5e28@oracle.com> On 2017/6/21 19:43, Alan Bateman wrote: > > > On 21/06/2017 09:27, Hamlin Li wrote: >> : >> >> >> Besides of it, I have some minor comments about the doc: >> >> >> In section "Timing of provider discovery", it says as below: >> >> Each invocation of the|iterator|method returns an|Iterator|that first >> yields all of the elements cached from previous iteration, in >> **instantiation order**, and then lazily locates and instantiates any >> remaining providers, adding each one to the cache in turn. >> >> But in API doc for iterator(), it says: >> >> Caching: The iterator returned by this method first yields all of the >> elements of the provider cache, in **the order that they were loaded** >> > There is an inconsistency here, it would be clearer to say that it's > the order that they were loaded and instantiated. This wording has > been there since Java SE 6 but I agree it all needs to be re-examined. > So at some point there will be another big update to the ServiceLoader > javadoc but more likely to be for Java SE 10 given that JDK 9 is at > GAC this week. Hi Alan, Got it, Thank you for planing to update it, especially for "load" and "instantiate", in several places they are used in a mixed way. Thank you -Hamlin > > -Alan From alex.buckley at oracle.com Thu Jun 22 00:55:45 2017 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 21 Jun 2017 17:55:45 -0700 Subject: 8182482: Module System spec updates In-Reply-To: <0446de69-45b1-4833-9b14-340ac6fc5e28@oracle.com> References: <8ca89ddf-03b6-9c68-2ea3-1a15512e6595@oracle.com> <3424080d-264c-ea9e-1587-0093428d5bb1@oracle.com> <8803adf2-d1b1-55f2-5eb5-734957e9c160@oracle.com> <80ed27c0-4b46-25c2-dd83-3707df0dd10e@oracle.com> <0446de69-45b1-4833-9b14-340ac6fc5e28@oracle.com> Message-ID: <594B1591.8040506@oracle.com> On 6/21/2017 5:34 PM, Hamlin Li wrote: > Got it, Thank you for planing to update it, especially for "load" and > "instantiate", in several places they are used in a mixed way. Yes, it is critical to be clear about: - when a service provider is discovered (search a family of loaders or layers, depending on how the service loader was created), versus - when a service provider is loaded (not by the load* methods! and maybe the provider is found in the cache...), versus - when a service provider is instantiated (streaming lets you defer that, iteration doesn't). Lots of puzzle pieces that need to snap together. Alex From huaming.li at oracle.com Thu Jun 22 05:25:34 2017 From: huaming.li at oracle.com (Hamlin Li) Date: Thu, 22 Jun 2017 13:25:34 +0800 Subject: 8182482: Module System spec updates In-Reply-To: <594B1591.8040506@oracle.com> References: <8ca89ddf-03b6-9c68-2ea3-1a15512e6595@oracle.com> <3424080d-264c-ea9e-1587-0093428d5bb1@oracle.com> <8803adf2-d1b1-55f2-5eb5-734957e9c160@oracle.com> <80ed27c0-4b46-25c2-dd83-3707df0dd10e@oracle.com> <0446de69-45b1-4833-9b14-340ac6fc5e28@oracle.com> <594B1591.8040506@oracle.com> Message-ID: Hi Alex, Yes, that's what I mean. Thank you -Hamlin On 2017/6/22 8:55, Alex Buckley wrote: > On 6/21/2017 5:34 PM, Hamlin Li wrote: >> Got it, Thank you for planing to update it, especially for "load" and >> "instantiate", in several places they are used in a mixed way. > > Yes, it is critical to be clear about: > > - when a service provider is discovered (search a family of loaders or > layers, depending on how the service loader was created), versus > > - when a service provider is loaded (not by the load* methods! and > maybe the provider is found in the cache...), versus > > - when a service provider is instantiated (streaming lets you defer > that, iteration doesn't). > > Lots of puzzle pieces that need to snap together. > > Alex From karen.kinnear at oracle.com Fri Jun 23 20:46:42 2017 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 23 Jun 2017 16:46:42 -0400 Subject: where's Karen 6/24-7/5 Message-ID: <0920B75A-09CF-4DC6-8B2C-AEF39236F1C0@oracle.com> Scotland - Aberdeen area and Orkney Islands - exploring Neolithic, Bronze Age, Iron Age, Pictish, Viking and WWII artifacts. Will make our hotspot sources seem relatively recent :-) Back July 5th. thanks, Karen From paul.bakker.nl at gmail.com Sun Jun 25 01:56:43 2017 From: paul.bakker.nl at gmail.com (Paul Bakker) Date: Sat, 24 Jun 2017 18:56:43 -0700 Subject: --illegal-access=warn not printing any warnings Message-ID: <624C4551-18CF-415C-9213-2B7B916AFC4F@gmail.com> The following code uses an encapsulated type: import sun.security.x509.X500Name; public class EncapsulatedTypes { public static void main(String... args) throws Exception { System.out.println(new X500Name("test.com", "test", "test", "US")); } } When running this code with "java --illegal-access=deny" it fails like I expected. Exception in thread "main" java.lang.IllegalAccessError: class EncapsulatedTypes (in unnamed module @0x6bc168e5) cannot access class sun.security.x509.X500Name (in module java.base) because module java.base does not export sun.security.x509 to unnamed module @0x6bc168e5 at EncapsulatedTypes.main(EncapsulatedTypes.java:8) When running with the default behavior or even with --illegal-access=warn or --illegal-access=debug, no warnings are generated. I have other (larger) examples where the warnings are shown correctly. Why doesn't this happen for this example? I'm running build 9-ea+174-jigsaw-nightly-h6526-20170617. Thanks, Paul From paul.bakker.nl at gmail.com Sun Jun 25 02:06:11 2017 From: paul.bakker.nl at gmail.com (Paul Bakker) Date: Sat, 24 Jun 2017 19:06:11 -0700 Subject: --illegal-access=warn not printing any warnings In-Reply-To: <624C4551-18CF-415C-9213-2B7B916AFC4F@gmail.com> References: <624C4551-18CF-415C-9213-2B7B916AFC4F@gmail.com> Message-ID: Answering my own question, this is clear after reading the proposal once more. Warnings are generated for reflective access only. Paul > On Jun 24, 2017, at 6:56 PM, Paul Bakker wrote: > > The following code uses an encapsulated type: > > import sun.security.x509.X500Name; > public class EncapsulatedTypes { > public static void main(String... args) throws Exception { > System.out.println(new X500Name("test.com ", "test", "test", "US")); > } > } > > When running this code with "java --illegal-access=deny" it fails like I expected. > > Exception in thread "main" java.lang.IllegalAccessError: class EncapsulatedTypes (in unnamed module @0x6bc168e5) cannot access class sun.security.x509.X500Name (in module java.base) because module java.base does not export sun.security.x509 to unnamed module @0x6bc168e5 > at EncapsulatedTypes.main(EncapsulatedTypes.java:8) > > When running with the default behavior or even with --illegal-access=warn or --illegal-access=debug, no warnings are generated. > > I have other (larger) examples where the warnings are shown correctly. Why doesn't this happen for this example? > > I'm running build 9-ea+174-jigsaw-nightly-h6526-20170617. > > Thanks, > > Paul From alan.bateman at oracle.com Mon Jun 26 07:03:56 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 26 Jun 2017 07:03:56 +0000 Subject: hg: jigsaw/jake: 5 new changesets Message-ID: <201706260703.v5Q73u07017569@aojmv0008.oracle.com> Changeset: 7df4f16bfa8f Author: mr Date: 2017-06-19 18:20 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/7df4f16bfa8f 8182408: Simplify the API-specification overview page Reviewed-by: erikj, mchung, jrose, alanb ! make/Docs.gmk Changeset: 985eae459953 Author: mchung Date: 2017-06-19 12:25 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/985eae459953 8182492: docs bundle needs legal notices for 3rd party libraries distributed for javadoc search Reviewed-by: jjg ! make/Docs.gmk Changeset: 8f7227c6012b Author: ihse Date: 2017-06-20 13:12 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/8f7227c6012b 8179537: Update testing.md for more clarity regarding JTReg configuration Reviewed-by: erikj ! common/doc/testing.html ! common/doc/testing.md Changeset: 77a9deaa0b4c Author: lana Date: 2017-06-22 18:42 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/77a9deaa0b4c Added tag jdk-9+175 for changeset 8f7227c6012b ! .hgtags Changeset: 23f2ed94b8d4 Author: alanb Date: 2017-06-26 07:49 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/23f2ed94b8d4 Merge ! .hgtags ! make/Docs.gmk From alan.bateman at oracle.com Mon Jun 26 07:03:57 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 26 Jun 2017 07:03:57 +0000 Subject: hg: jigsaw/jake/corba: 3 new changesets Message-ID: <201706260703.v5Q73vFF017600@aojmv0008.oracle.com> Changeset: dc78a3dd6b3a Author: mchung Date: 2017-06-17 11:50 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/dc78a3dd6b3a 8182416: Clean up module-info.java like move requires transitive adjacent to exports Reviewed-by: alanb ! src/java.corba/share/classes/module-info.java Changeset: 40fb9f229471 Author: lana Date: 2017-06-22 18:42 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/40fb9f229471 Added tag jdk-9+175 for changeset dc78a3dd6b3a ! .hgtags Changeset: 654548ff7426 Author: alanb Date: 2017-06-26 07:51 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/654548ff7426 Merge ! .hgtags ! src/java.corba/share/classes/module-info.java From alan.bateman at oracle.com Mon Jun 26 07:03:56 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 26 Jun 2017 07:03:56 +0000 Subject: hg: jigsaw/jake/jaxws: 4 new changesets Message-ID: <201706260703.v5Q73uLL017596@aojmv0008.oracle.com> Changeset: 083973007bef Author: mchung Date: 2017-06-17 11:51 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/083973007bef 8182416: Clean up module-info.java like move requires transitive adjacent to exports Reviewed-by: alanb ! src/java.activation/share/classes/module-info.java ! src/java.xml.bind/share/classes/module-info.java ! src/java.xml.ws.annotation/share/classes/module-info.java ! src/java.xml.ws/share/classes/module-info.java ! src/jdk.xml.bind/share/classes/module-info.java ! src/jdk.xml.ws/share/classes/module-info.java Changeset: a5d361b9d1f7 Author: aefimov Date: 2017-06-18 23:07 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/a5d361b9d1f7 8176508: Update JAX-WS RI integration to latest version Reviewed-by: lancea, mchung, alanb, iris ! src/java.activation/share/classes/javax/activation/CommandInfo.java ! src/java.activation/share/classes/javax/activation/CommandObject.java ! src/java.activation/share/classes/javax/activation/DataHandler.java ! src/java.activation/share/classes/javax/activation/DataSource.java ! src/java.activation/share/classes/javax/activation/MailcapCommandMap.java ! src/java.activation/share/classes/javax/activation/MimeType.java ! src/java.activation/share/classes/javax/activation/MimeTypeParameterList.java ! src/java.activation/share/classes/javax/activation/MimetypesFileTypeMap.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/marshaller/MinimumEscapeHandler.java + src/java.xml.bind/share/classes/com/sun/xml/internal/bind/marshaller/NoEscapeHandler.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/BridgeImpl.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/MarshallerImpl.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/output/FastInfosetStreamWriterOutput.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/output/StAXExStreamWriterOutput.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/output/XMLStreamWriterOutput.java ! src/java.xml.bind/share/classes/javax/xml/bind/ContextFinder.java ! src/java.xml.bind/share/classes/javax/xml/bind/JAXBContext.java ! src/java.xml.bind/share/classes/javax/xml/bind/JAXBContextFactory.java ! src/java.xml.bind/share/classes/javax/xml/bind/Messages.java ! src/java.xml.bind/share/classes/javax/xml/bind/Messages.properties + src/java.xml.bind/share/classes/javax/xml/bind/ModuleUtil.java ! src/java.xml.bind/share/classes/javax/xml/bind/Unmarshaller.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/client/p2p/HttpSOAPConnection.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/client/p2p/HttpSOAPConnectionFactory.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/MessagingException.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/BMMimeMultipart.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/InternetHeaders.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/MimeMultipart.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/MimePartDataSource.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/MimePullMultipart.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/ParameterList.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/util/ASCIIUtility.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/util/QDecoderStream.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/util/QPDecoderStream.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/util/QPEncoderStream.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/util/UUDecoderStream.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/AttachmentPartImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ContextClassloaderLocal.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/MessageFactoryImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/MessageImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/SAAJMetaFactoryImpl.java + src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPDocumentFragment.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPDocumentImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPFactoryImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPIOException.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPPartImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/StaxLazySourceBridge.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/StaxReaderBridge.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/dynamic/SOAPFactoryDynamicImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/dynamic/SOAPMessageFactoryDynamicImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/BodyElementImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/BodyImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/CDATAImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/DetailEntryImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/DetailImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/ElementFactory.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/ElementImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/EnvelopeImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/FaultElementImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/HeaderElementImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/HeaderImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/LocalStrings.properties + src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/NamedNodeMapImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/SOAPCommentImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/SOAPTextImpl.java + src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/TextImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Body1_1Impl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/BodyElement1_1Impl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Detail1_1Impl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/DetailEntry1_1Impl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Envelope1_1Impl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Fault1_1Impl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/FaultElement1_1Impl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Header1_1Impl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/HeaderElement1_1Impl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Message1_1Impl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/SOAPFactory1_1Impl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/SOAPMessageFactory1_1Impl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/SOAPPart1_1Impl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Body1_2Impl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/BodyElement1_2Impl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Detail1_2Impl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/DetailEntry1_2Impl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Envelope1_2Impl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Fault1_2Impl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/FaultElement1_2Impl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Header1_2Impl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/HeaderElement1_2Impl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Message1_2Impl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/SOAPFactory1_2Impl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/SOAPMessageFactory1_2Impl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/SOAPPart1_2Impl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/ByteInputStream.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/JAXMStreamSource.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/NamespaceContextIterator.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/RejectDoctypeSaxFilter.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/TeeInputStream.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/stax/LazyEnvelopeStaxReader.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/stax/SaajStaxWriter.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/stax/SaajStaxWriterEx.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/api/message/saaj/SAAJMessageHeaders.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/api/server/SDDocumentSource.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/api/streaming/XMLStreamReaderFactory.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/api/streaming/XMLStreamWriterFactory.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/model/RuntimeModeler.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/policy/privateutil/LocalizationMessages.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/policy/sourcemodel/attach/ContextClassloaderLocal.java + src/java.xml.ws/share/classes/com/sun/xml/internal/ws/policy/sourcemodel/attach/ContextClassloaderLocalMessages.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/resources/AddressingMessages.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/resources/BindingApiMessages.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/resources/ClientMessages.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/resources/DispatchMessages.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/resources/EncodingMessages.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/resources/HandlerMessages.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/resources/HttpserverMessages.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/resources/ManagementMessages.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/resources/ModelerMessages.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/resources/PolicyMessages.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/resources/ProviderApiMessages.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/resources/SenderMessages.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/resources/ServerMessages.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/resources/SoapMessages.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/resources/StreamingMessages.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/resources/TubelineassemblyMessages.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/resources/UtilMessages.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/resources/WsdlmodelMessages.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/resources/WsservletMessages.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/resources/XmlmessageMessages.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/resources/modeler.properties ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/resources/modeler_de.properties ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/resources/modeler_es.properties ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/resources/modeler_fr.properties ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/resources/modeler_it.properties ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/resources/modeler_ja.properties ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/resources/modeler_ko.properties ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/resources/modeler_pt_BR.properties ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/resources/modeler_zh_CN.properties ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/resources/modeler_zh_TW.properties ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/util/HandlerAnnotationProcessor.java + src/java.xml.ws/share/classes/com/sun/xml/internal/ws/util/MrJarUtil.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/util/Pool.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/util/exception/JAXWSExceptionBase.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/util/pipe/AbstractSchemaValidationTube.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/util/version.properties ! src/java.xml.ws/share/classes/javax/xml/soap/AttachmentPart.java ! src/java.xml.ws/share/classes/javax/xml/soap/Detail.java ! src/java.xml.ws/share/classes/javax/xml/soap/MimeHeaders.java ! src/java.xml.ws/share/classes/javax/xml/soap/Node.java ! src/java.xml.ws/share/classes/javax/xml/soap/SAAJMetaFactory.java ! src/java.xml.ws/share/classes/javax/xml/soap/SOAPElement.java ! src/java.xml.ws/share/classes/javax/xml/soap/SOAPElementFactory.java ! src/java.xml.ws/share/classes/javax/xml/soap/SOAPException.java ! src/java.xml.ws/share/classes/javax/xml/soap/SOAPFactory.java ! src/java.xml.ws/share/classes/javax/xml/soap/SOAPFault.java ! src/java.xml.ws/share/classes/javax/xml/soap/SOAPHeader.java ! src/java.xml.ws/share/classes/javax/xml/soap/SOAPMessage.java ! src/java.xml.ws/share/classes/javax/xml/soap/SOAPPart.java ! src/java.xml.ws/share/classes/javax/xml/soap/ServiceLoaderUtil.java ! src/java.xml.ws/share/classes/javax/xml/soap/package-info.java ! src/java.xml.ws/share/classes/javax/xml/ws/Action.java ! src/java.xml.ws/share/classes/javax/xml/ws/AsyncHandler.java ! src/java.xml.ws/share/classes/javax/xml/ws/BindingProvider.java ! src/java.xml.ws/share/classes/javax/xml/ws/BindingType.java ! src/java.xml.ws/share/classes/javax/xml/ws/Dispatch.java ! src/java.xml.ws/share/classes/javax/xml/ws/Endpoint.java ! src/java.xml.ws/share/classes/javax/xml/ws/EndpointReference.java ! src/java.xml.ws/share/classes/javax/xml/ws/FaultAction.java ! src/java.xml.ws/share/classes/javax/xml/ws/Holder.java ! src/java.xml.ws/share/classes/javax/xml/ws/Provider.java ! src/java.xml.ws/share/classes/javax/xml/ws/RequestWrapper.java ! src/java.xml.ws/share/classes/javax/xml/ws/RespectBinding.java ! src/java.xml.ws/share/classes/javax/xml/ws/Response.java ! src/java.xml.ws/share/classes/javax/xml/ws/ResponseWrapper.java ! src/java.xml.ws/share/classes/javax/xml/ws/Service.java ! src/java.xml.ws/share/classes/javax/xml/ws/ServiceMode.java ! src/java.xml.ws/share/classes/javax/xml/ws/WebEndpoint.java ! src/java.xml.ws/share/classes/javax/xml/ws/WebServiceClient.java ! src/java.xml.ws/share/classes/javax/xml/ws/WebServiceContext.java ! src/java.xml.ws/share/classes/javax/xml/ws/WebServiceFeature.java ! src/java.xml.ws/share/classes/javax/xml/ws/WebServiceProvider.java ! src/java.xml.ws/share/classes/javax/xml/ws/WebServiceRef.java ! src/java.xml.ws/share/classes/javax/xml/ws/WebServiceRefs.java ! src/java.xml.ws/share/classes/javax/xml/ws/handler/Handler.java ! src/java.xml.ws/share/classes/javax/xml/ws/handler/LogicalHandler.java ! src/java.xml.ws/share/classes/javax/xml/ws/handler/MessageContext.java + src/java.xml.ws/share/classes/javax/xml/ws/handler/package-info.java - src/java.xml.ws/share/classes/javax/xml/ws/handler/package.html ! src/java.xml.ws/share/classes/javax/xml/ws/handler/soap/SOAPHandler.java + src/java.xml.ws/share/classes/javax/xml/ws/handler/soap/package-info.java - src/java.xml.ws/share/classes/javax/xml/ws/handler/soap/package.html + src/java.xml.ws/share/classes/javax/xml/ws/http/package-info.java - src/java.xml.ws/share/classes/javax/xml/ws/http/package.html ! src/java.xml.ws/share/classes/javax/xml/ws/soap/Addressing.java ! src/java.xml.ws/share/classes/javax/xml/ws/soap/MTOM.java + src/java.xml.ws/share/classes/javax/xml/ws/soap/package-info.java - src/java.xml.ws/share/classes/javax/xml/ws/soap/package.html ! src/java.xml.ws/share/classes/javax/xml/ws/spi/Provider.java ! src/java.xml.ws/share/classes/javax/xml/ws/spi/ServiceDelegate.java ! src/java.xml.ws/share/classes/javax/xml/ws/spi/WebServiceFeatureAnnotation.java ! src/java.xml.ws/share/classes/javax/xml/ws/spi/http/HttpContext.java + src/java.xml.ws/share/classes/javax/xml/ws/spi/package-info.java - src/java.xml.ws/share/classes/javax/xml/ws/spi/package.html ! src/java.xml.ws/share/classes/javax/xml/ws/wsaddressing/W3CEndpointReference.java ! src/java.xml.ws/share/classes/module-info.java ! src/jdk.xml.bind/share/classes/com/sun/codemodel/internal/JModuleDirective.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle.properties ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_de.properties ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_es.properties ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_fr.properties ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_it.properties ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_ja.properties ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_ko.properties ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_pt_BR.properties ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_zh_CN.properties ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_zh_TW.properties ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle.properties ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle_de.properties ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle_es.properties ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle_fr.properties ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle_it.properties ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle_ja.properties ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle_ko.properties ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle_pt_BR.properties ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle_zh_CN.properties ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle_zh_TW.properties ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/Options.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/SpecVersion.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/internalizer/DOMForest.java ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/processor/ProcessorException.java ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/ConfigurationMessages.java ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/GeneratorMessages.java ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/JavacompilerMessages.java ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/ModelMessages.java ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/ModelerMessages.java ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/ProcessorMessages.java ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/UtilMessages.java ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/WebserviceapMessages.java ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/WscompileMessages.java ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/WsdlMessages.java - src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/newmessages.properties ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/wscompile.properties ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/wscompile_de.properties ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/wscompile_es.properties ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/wscompile_fr.properties ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/wscompile_it.properties ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/wscompile_ja.properties ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/wscompile_ko.properties ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/wscompile_pt_BR.properties ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/wscompile_zh_CN.properties ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/wscompile_zh_TW.properties ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/util/WSDLParseException.java ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/version.properties ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wsdl/framework/ParseException.java ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wsdl/framework/ValidationException.java ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wsdl/parser/DOMForest.java Changeset: ea819b6009d3 Author: lana Date: 2017-06-22 18:42 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/ea819b6009d3 Added tag jdk-9+175 for changeset a5d361b9d1f7 ! .hgtags Changeset: 7a78968f7be4 Author: alanb Date: 2017-06-26 07:50 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/7a78968f7be4 Merge ! .hgtags ! src/java.activation/share/classes/javax/activation/MailcapCommandMap.java ! src/java.activation/share/classes/module-info.java ! src/java.xml.bind/share/classes/javax/xml/bind/ContextFinder.java ! src/java.xml.bind/share/classes/module-info.java ! src/java.xml.ws.annotation/share/classes/module-info.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/model/RuntimeModeler.java ! src/java.xml.ws/share/classes/javax/xml/soap/ServiceLoaderUtil.java - src/java.xml.ws/share/classes/javax/xml/ws/handler/package.html - src/java.xml.ws/share/classes/javax/xml/ws/handler/soap/package.html - src/java.xml.ws/share/classes/javax/xml/ws/http/package.html - src/java.xml.ws/share/classes/javax/xml/ws/soap/package.html - src/java.xml.ws/share/classes/javax/xml/ws/spi/package.html ! src/java.xml.ws/share/classes/module-info.java ! src/jdk.xml.bind/share/classes/module-info.java - src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/newmessages.properties ! src/jdk.xml.ws/share/classes/module-info.java From alan.bateman at oracle.com Mon Jun 26 07:03:56 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 26 Jun 2017 07:03:56 +0000 Subject: hg: jigsaw/jake/nashorn: 3 new changesets Message-ID: <201706260703.v5Q73uM3017591@aojmv0008.oracle.com> Changeset: 734b3209b6ed Author: mchung Date: 2017-06-17 11:50 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/734b3209b6ed 8182416: Clean up module-info.java like move requires transitive adjacent to exports Reviewed-by: alanb ! src/jdk.scripting.nashorn.shell/share/classes/module-info.java ! src/jdk.scripting.nashorn/share/classes/module-info.java Changeset: 3c6fbdf6e785 Author: lana Date: 2017-06-22 18:42 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/3c6fbdf6e785 Added tag jdk-9+175 for changeset 734b3209b6ed ! .hgtags Changeset: 26582f7254cc Author: alanb Date: 2017-06-26 07:50 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/26582f7254cc Merge ! .hgtags ! src/jdk.scripting.nashorn.shell/share/classes/module-info.java ! src/jdk.scripting.nashorn/share/classes/module-info.java From alan.bateman at oracle.com Mon Jun 26 07:03:57 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 26 Jun 2017 07:03:57 +0000 Subject: hg: jigsaw/jake/hotspot: 6 new changesets Message-ID: <201706260703.v5Q73vii017604@aojmv0008.oracle.com> Changeset: 8346c00b2ba6 Author: mchung Date: 2017-06-17 11:50 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/8346c00b2ba6 8182416: Clean up module-info.java like move requires transitive adjacent to exports Reviewed-by: alanb ! src/jdk.aot/share/classes/module-info.java ! src/jdk.internal.vm.compiler/share/classes/module-info.java Changeset: 516a043eb368 Author: fyang Date: 2017-06-20 17:00 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/516a043eb368 8182581: aarch64: fix for crash caused by earlyret of compiled method Summary: fix jvm crash caused by earlyret of compiled method for aarch64 port Reviewed-by: aph Contributed-by: snazarkin at azul.com ! src/cpu/aarch64/vm/abstractInterpreter_aarch64.cpp Changeset: 16c9c159df90 Author: vlivanov Date: 2017-06-20 14:37 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/16c9c159df90 8181872: C1: possible overflow when strength reducing integer multiply by constant Reviewed-by: kvn ! src/cpu/aarch64/vm/c1_LIRGenerator_aarch64.cpp ! src/cpu/arm/vm/c1_LIRGenerator_arm.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp + test/compiler/c1/MultiplyByMaxInt.java Changeset: 8f04d457168b Author: vlivanov Date: 2017-06-20 13:44 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/8f04d457168b Merge Changeset: 76a497562014 Author: lana Date: 2017-06-22 18:42 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/76a497562014 Added tag jdk-9+175 for changeset 8f04d457168b ! .hgtags Changeset: eaab39334301 Author: alanb Date: 2017-06-26 07:50 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/eaab39334301 Merge ! .hgtags ! src/share/vm/c1/c1_LIRGenerator.cpp From alan.bateman at oracle.com Mon Jun 26 07:03:58 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 26 Jun 2017 07:03:58 +0000 Subject: hg: jigsaw/jake/jaxp: 4 new changesets Message-ID: <201706260703.v5Q73wnC017621@aojmv0008.oracle.com> Changeset: bc9aafd4cee2 Author: mchung Date: 2017-06-17 11:50 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/bc9aafd4cee2 8182416: Clean up module-info.java like move requires transitive adjacent to exports Reviewed-by: alanb ! src/java.xml/share/classes/module-info.java ! src/jdk.xml.dom/share/classes/module-info.java Changeset: 736412a8dcce Author: aefimov Date: 2017-06-18 23:10 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/736412a8dcce 8176508: Update JAX-WS RI integration to latest version Reviewed-by: lancea, mchung, alanb, iris ! src/java.xml/share/classes/module-info.java Changeset: 38cf34e23280 Author: lana Date: 2017-06-22 18:42 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/38cf34e23280 Added tag jdk-9+175 for changeset 736412a8dcce ! .hgtags Changeset: a7e5de96193c Author: alanb Date: 2017-06-26 07:50 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/a7e5de96193c Merge ! .hgtags ! src/java.xml/share/classes/module-info.java ! src/jdk.xml.dom/share/classes/module-info.java From alan.bateman at oracle.com Mon Jun 26 07:03:59 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 26 Jun 2017 07:03:59 +0000 Subject: hg: jigsaw/jake/jdk: 14 new changesets Message-ID: <201706260704.v5Q740vs017658@aojmv0008.oracle.com> Changeset: a59b6b3fc4dd Author: mchung Date: 2017-06-17 11:50 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a59b6b3fc4dd 8182416: Clean up module-info.java like move requires transitive adjacent to exports Reviewed-by: alanb ! src/java.base/share/classes/module-info.java ! src/java.datatransfer/share/classes/module-info.java ! src/java.desktop/share/classes/module-info.java ! src/java.logging/share/classes/module-info.java ! src/java.management.rmi/share/classes/module-info.java ! src/java.management/share/classes/module-info.java ! src/java.naming/share/classes/module-info.java ! src/java.prefs/share/classes/module-info.java ! src/java.rmi/share/classes/module-info.java ! src/java.scripting/share/classes/module-info.java ! src/java.se.ee/share/classes/module-info.java ! src/java.security.jgss/share/classes/module-info.java ! src/java.security.sasl/share/classes/module-info.java ! src/java.smartcardio/share/classes/module-info.java ! src/java.sql.rowset/share/classes/module-info.java ! src/java.sql/share/classes/module-info.java ! src/java.transaction/share/classes/module-info.java ! src/java.xml.crypto/share/classes/module-info.java ! src/jdk.accessibility/share/classes/module-info.java ! src/jdk.attach/share/classes/module-info.java ! src/jdk.charsets/share/classes/module-info.java ! src/jdk.crypto.cryptoki/share/classes/module-info.java ! src/jdk.editpad/share/classes/module-info.java ! src/jdk.httpserver/share/classes/module-info.java ! src/jdk.incubator.httpclient/share/classes/module-info.java ! src/jdk.internal.ed/share/classes/module-info.java ! src/jdk.internal.jvmstat/share/classes/module-info.java ! src/jdk.jartool/share/classes/module-info.java ! src/jdk.jconsole/share/classes/module-info.java ! src/jdk.jsobject/share/classes/module-info.java ! src/jdk.jstatd/share/classes/module-info.java ! src/jdk.naming.dns/share/classes/module-info.java ! src/jdk.naming.rmi/share/classes/module-info.java ! src/jdk.policytool/share/classes/module-info.java ! src/jdk.security.auth/share/classes/module-info.java ! src/jdk.security.jgss/share/classes/module-info.java ! src/jdk.unsupported/share/classes/module-info.java ! src/jdk.zipfs/share/classes/module-info.java Changeset: 875f8e460638 Author: serb Date: 2017-06-18 17:33 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/875f8e460638 8180889: Cleanup of javadoc in java.datatransfer module Reviewed-by: prr, azvegint ! src/java.datatransfer/share/classes/java/awt/datatransfer/Clipboard.java ! src/java.datatransfer/share/classes/java/awt/datatransfer/ClipboardOwner.java ! src/java.datatransfer/share/classes/java/awt/datatransfer/DataFlavor.java ! src/java.datatransfer/share/classes/java/awt/datatransfer/FlavorEvent.java ! src/java.datatransfer/share/classes/java/awt/datatransfer/FlavorListener.java ! src/java.datatransfer/share/classes/java/awt/datatransfer/FlavorMap.java ! src/java.datatransfer/share/classes/java/awt/datatransfer/FlavorTable.java ! src/java.datatransfer/share/classes/java/awt/datatransfer/MimeType.java ! src/java.datatransfer/share/classes/java/awt/datatransfer/MimeTypeParameterList.java ! src/java.datatransfer/share/classes/java/awt/datatransfer/MimeTypeParseException.java ! src/java.datatransfer/share/classes/java/awt/datatransfer/StringSelection.java ! src/java.datatransfer/share/classes/java/awt/datatransfer/SystemFlavorMap.java ! src/java.datatransfer/share/classes/java/awt/datatransfer/Transferable.java ! src/java.datatransfer/share/classes/java/awt/datatransfer/UnsupportedFlavorException.java ! src/java.datatransfer/share/classes/sun/datatransfer/DataFlavorUtil.java ! src/java.datatransfer/share/classes/sun/datatransfer/DesktopDatatransferService.java Changeset: 4fbcae493269 Author: aefimov Date: 2017-06-18 23:10 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4fbcae493269 8176508: Update JAX-WS RI integration to latest version Reviewed-by: lancea, mchung, alanb, iris ! test/jdk/modules/etc/JdkQualifiedExportTest.java Changeset: 6a4875229b96 Author: serb Date: 2017-06-19 07:19 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6a4875229b96 8181894: java.desktop module documentation has links to technotes Reviewed-by: mchung ! src/java.desktop/share/classes/javax/imageio/spi/IIORegistry.java ! src/java.desktop/share/classes/javax/imageio/spi/ServiceRegistry.java ! src/java.desktop/share/classes/javax/print/StreamPrintServiceFactory.java ! src/java.desktop/share/classes/javax/print/package-info.java ! src/java.desktop/share/classes/javax/swing/filechooser/package-info.java Changeset: d0a0f9e3cf9f Author: mullan Date: 2017-06-19 08:16 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d0a0f9e3cf9f 8181295: Document that SecurityManager::checkPackageAccess may be called by the VM Reviewed-by: mchung ! src/java.base/share/classes/java/lang/SecurityManager.java Changeset: 2cd9961940f9 Author: weijun Date: 2017-06-19 22:54 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2cd9961940f9 8182118: Package summary is missing in jdk.security.auth module Reviewed-by: mullan, mchung ! src/jdk.security.auth/share/classes/com/sun/security/auth/callback/package-info.java ! src/jdk.security.auth/share/classes/com/sun/security/auth/login/package-info.java ! src/jdk.security.auth/share/classes/com/sun/security/auth/module/package-info.java ! src/jdk.security.auth/share/classes/com/sun/security/auth/package-info.java ! src/jdk.security.auth/share/classes/module-info.java Changeset: fd2e6410fd7a Author: mchung Date: 2017-06-19 13:59 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd2e6410fd7a 8181834: Broken link in jdk.jdi module documentation Reviewed-by: sspitsyn ! src/jdk.jdi/share/classes/module-info.java Changeset: 6fcde0dd00b2 Author: alanb Date: 2017-06-20 15:22 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6fcde0dd00b2 8182482: Module System spec updates Reviewed-by: darcy, mr, mchung Contributed-by: alex.buckley at oracle.com, alan.bateman at oracle.com ! src/java.base/share/classes/java/lang/module/package-info.java ! src/java.base/share/classes/java/util/ServiceLoader.java Changeset: 79db2bd40baf Author: mchung Date: 2017-06-20 08:42 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/79db2bd40baf 8182596: Fix broken links in com.sun.tools.attach.VirtualMachine Reviewed-by: alanb ! src/jdk.attach/share/classes/com/sun/tools/attach/VirtualMachine.java Changeset: 51f5d60713b5 Author: psandoz Date: 2017-06-20 08:52 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/51f5d60713b5 8182023: some java.util.jar docs contain links to technotes Reviewed-by: mchung Contributed-by: brent.christian at oracle.com, paul.sandoz at oracle.com ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/java/lang/Package.java ! src/java.base/share/classes/java/util/jar/Attributes.java ! src/java.base/share/classes/java/util/jar/Manifest.java ! src/java.base/share/classes/java/util/jar/package-info.java ! src/java.management/share/classes/javax/management/remote/JMXConnectorFactory.java ! src/java.management/share/classes/javax/management/remote/JMXConnectorServerFactory.java Changeset: b252dd92a359 Author: mullan Date: 2017-06-20 14:11 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b252dd92a359 8182609: Update ECC license file Reviewed-by: mchung Contributed-by: jeannette.hung at oracle.com ! src/jdk.crypto.ec/share/legal/ecc.md Changeset: e6c4f6ef717d Author: wetmore Date: 2017-06-20 12:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e6c4f6ef717d 8178114: Fix guide links in security APIs Reviewed-by: xuelei, mullan, weijun ! src/java.base/share/classes/java/lang/SecurityManager.java ! src/java.base/share/classes/java/security/AlgorithmParameterGenerator.java ! src/java.base/share/classes/java/security/AlgorithmParameterGeneratorSpi.java ! src/java.base/share/classes/java/security/Key.java ! src/java.base/share/classes/java/security/KeyPairGenerator.java ! src/java.base/share/classes/java/security/KeyPairGeneratorSpi.java ! src/java.base/share/classes/java/security/Provider.java ! src/java.base/share/classes/java/security/Security.java ! src/java.base/share/classes/java/security/cert/CRL.java ! src/java.base/share/classes/java/security/cert/package-info.java ! src/java.base/share/classes/java/security/interfaces/package-info.java ! src/java.base/share/classes/java/security/package-info.java ! src/java.base/share/classes/java/security/spec/package-info.java ! src/java.base/share/classes/javax/crypto/Cipher.java ! src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java ! src/java.base/share/classes/javax/crypto/KeyGenerator.java ! src/java.base/share/classes/javax/crypto/KeyGeneratorSpi.java ! src/java.base/share/classes/javax/crypto/interfaces/package-info.java ! src/java.base/share/classes/javax/crypto/package-info.java ! src/java.base/share/classes/javax/crypto/spec/SecretKeySpec.java ! src/java.base/share/classes/javax/crypto/spec/package-info.java ! src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java ! src/java.base/share/classes/javax/net/ssl/KeyManagerFactory.java ! src/java.base/share/classes/javax/net/ssl/SSLParameters.java ! src/java.base/share/classes/javax/net/ssl/TrustManagerFactory.java ! src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosPrincipal.java ! src/java.security.jgss/share/classes/org/ietf/jgss/package.html ! src/java.security.sasl/share/classes/javax/security/sasl/Sasl.java ! src/java.security.sasl/share/classes/javax/security/sasl/package-info.java ! src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/TransformService.java ! src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/XMLSignatureFactory.java ! src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/keyinfo/KeyInfoFactory.java Changeset: f3cf7fd26baa Author: lana Date: 2017-06-22 18:42 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f3cf7fd26baa Added tag jdk-9+175 for changeset e6c4f6ef717d ! .hgtags Changeset: 911ab13492eb Author: alanb Date: 2017-06-26 07:49 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/911ab13492eb Merge ! .hgtags ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/java/lang/Package.java ! src/java.base/share/classes/java/lang/SecurityManager.java ! src/java.base/share/classes/java/lang/module/package-info.java ! src/java.base/share/classes/java/security/Provider.java ! src/java.base/share/classes/java/util/ServiceLoader.java ! src/java.base/share/classes/module-info.java ! src/java.datatransfer/share/classes/sun/datatransfer/DataFlavorUtil.java ! src/java.desktop/share/classes/module-info.java ! src/java.logging/share/classes/module-info.java ! src/java.management/share/classes/javax/management/remote/JMXConnectorFactory.java ! src/java.management/share/classes/module-info.java ! src/java.naming/share/classes/module-info.java ! src/java.prefs/share/classes/module-info.java ! src/java.rmi/share/classes/module-info.java ! src/java.scripting/share/classes/module-info.java ! src/java.se.ee/share/classes/module-info.java ! src/java.security.jgss/share/classes/module-info.java ! src/java.security.sasl/share/classes/module-info.java ! src/java.smartcardio/share/classes/module-info.java ! src/java.sql.rowset/share/classes/module-info.java ! src/java.sql/share/classes/module-info.java ! src/java.transaction/share/classes/module-info.java ! src/java.xml.crypto/share/classes/module-info.java ! src/jdk.accessibility/share/classes/module-info.java ! src/jdk.attach/share/classes/module-info.java ! src/jdk.charsets/share/classes/module-info.java ! src/jdk.crypto.cryptoki/share/classes/module-info.java ! src/jdk.httpserver/share/classes/module-info.java ! src/jdk.internal.jvmstat/share/classes/module-info.java ! src/jdk.jartool/share/classes/module-info.java ! src/jdk.jconsole/share/classes/module-info.java ! src/jdk.jdi/share/classes/module-info.java ! src/jdk.jsobject/share/classes/module-info.java ! src/jdk.naming.dns/share/classes/module-info.java ! src/jdk.naming.rmi/share/classes/module-info.java ! src/jdk.policytool/share/classes/module-info.java ! src/jdk.security.auth/share/classes/module-info.java ! src/jdk.security.jgss/share/classes/module-info.java ! src/jdk.unsupported/share/classes/module-info.java ! src/jdk.zipfs/share/classes/module-info.java From alan.bateman at oracle.com Mon Jun 26 07:03:59 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 26 Jun 2017 07:03:59 +0000 Subject: hg: jigsaw/jake/langtools: 7 new changesets Message-ID: <201706260703.v5Q73xpO017640@aojmv0008.oracle.com> Changeset: bd10ad9aefb3 Author: mchung Date: 2017-06-17 11:50 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/bd10ad9aefb3 8182416: Clean up module-info.java like move requires transitive adjacent to exports Reviewed-by: alanb ! src/java.compiler/share/classes/module-info.java ! src/jdk.compiler/share/classes/module-info.java ! src/jdk.javadoc/share/classes/module-info.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleInfoBuilder.java ! src/jdk.jdeps/share/classes/module-info.java ! src/jdk.jshell/share/classes/module-info.java Changeset: c899c71eb7d2 Author: jlahoda Date: 2017-06-19 05:56 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/c899c71eb7d2 8182162: Remove -XD-Xmodule Summary: Removing the undocumented -XD-Xmodule: option. Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java - test/tools/javac/modules/LegacyXModuleTest.java Changeset: 14169b37b44f Author: mchung Date: 2017-06-19 12:25 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/14169b37b44f 8182492: docs bundle needs legal notices for 3rd party libraries distributed for javadoc search Reviewed-by: jjg + src/jdk.javadoc/share/legal/pako.md Changeset: 51b4cd2af28e Author: darcy Date: 2017-06-19 15:06 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/51b4cd2af28e 8163989: Clarify ModuleElement spec Reviewed-by: abuckley, jjg ! src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java ! src/java.compiler/share/classes/javax/lang/model/element/PackageElement.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! test/tools/javac/modules/EdgeCases.java + test/tools/javac/processing/model/element/TestModuleElementNames.java ! test/tools/javac/processing/model/element/TestPackageElement.java Changeset: 83f6eb009d8f Author: darcy Date: 2017-06-19 17:13 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/83f6eb009d8f 8182566: Including missing test update for JDK-8163989 Reviewed-by: jjg ! test/tools/javac/file/MultiReleaseJar/MutliReleaseModuleInfoTest.java Changeset: 141a3c187e1a Author: lana Date: 2017-06-22 18:42 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/141a3c187e1a Added tag jdk-9+175 for changeset 83f6eb009d8f ! .hgtags Changeset: e2475ff79b59 Author: alanb Date: 2017-06-26 07:49 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/e2475ff79b59 Merge ! .hgtags ! src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java ! src/java.compiler/share/classes/javax/lang/model/element/PackageElement.java ! src/java.compiler/share/classes/module-info.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/jdk.compiler/share/classes/module-info.java ! src/jdk.javadoc/share/classes/module-info.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleInfoBuilder.java ! src/jdk.jdeps/share/classes/module-info.java ! src/jdk.jshell/share/classes/module-info.java ! test/tools/javac/modules/EdgeCases.java - test/tools/javac/modules/LegacyXModuleTest.java From uschindler at apache.org Mon Jun 26 07:35:52 2017 From: uschindler at apache.org (Uwe Schindler) Date: Mon, 26 Jun 2017 09:35:52 +0200 Subject: Missing translation for "--illegal-access"; Hadoop problems with build 175 Message-ID: <007d01d2ee4e$d98bc000$8ca34000$@apache.org> Hi, I was trying the recent non-jigsaw build 175 of JDK 9. This one now has the "--illegal-access" setting. But on my German Windows system this has wrong help text on the command line: C:\...>java -X [...] --permit-illegal-access L?sst unzul?ssigen Zugriff f?r Mitglieder mit den Typen in den benannten Modulen nach Code in unbenannten Modulen zu. Diese Kompatibilit?tsoption wird im n?chsten Release entfernt. [...] Of course this command line option no longer works: C:\...>java --permit-illegal-access -version Unrecognized option: --permit-illegal-access Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. C:\...>java --illegal-access=deny -version java version "9" Java(TM) SE Runtime Environment (build 9+175) Java HotSpot(TM) 64-Bit Server VM (build 9+175, mixed mode) So I just wanted to give you some feedback that translations are obviously missing. FYI, the Linux version in English returns the correct text. As build 175 seems to be the first release candidate (it no longer has "-ea" in the version string), this is something to take care. FYI, the new version string (just "9") again caused some serious problem in open source projects. This time Hadoop, see https://issues.apache.org/jira/browse/HADOOP-14586. Issue is the following static final constant, leading to NoClassDefFound error and a cascade of classes no longer initializing: private static boolean IS_JAVA7_OR_ABOVE = System.getProperty("java.version").substring(0, 3).compareTo("1.7") >= 0; Damn! ?? (the above code is IMHO just horrible wrong, never ever do something like this). In a ddition, it no even has a doPrivileged! Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ From Alan.Bateman at oracle.com Mon Jun 26 08:00:07 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 26 Jun 2017 09:00:07 +0100 Subject: Missing translation for "--illegal-access"; Hadoop problems with build 175 In-Reply-To: <007d01d2ee4e$d98bc000$8ca34000$@apache.org> References: <007d01d2ee4e$d98bc000$8ca34000$@apache.org> Message-ID: <7906db8f-bec2-e978-6681-d14c9d4a3d62@oracle.com> On 26/06/2017 08:35, Uwe Schindler wrote: > : > > So I just wanted to give you some feedback that translations are obviously missing. FYI, the Linux version in English returns the correct text. The last translation drop went into jdk-9+172 so it's out of sync with the CLI/usage messages in builds since then. In addition to --illegal-access, there are a few other changes to, and at least one new, error message(s) that also need updated translations. > > FYI, the new version string (just "9") again caused some serious problem in open source projects. This time Hadoop, see https://issues.apache.org/jira/browse/HADOOP-14586. Issue is the following static final constant, leading to NoClassDefFound error and a cascade of classes no longer initializing: > private static boolean IS_JAVA7_OR_ABOVE = > System.getProperty("java.version").substring(0, 3).compareTo("1.7") >= 0; > > Damn! ?? (the above code is IMHO just horrible wrong, never ever do something like this). In a ddition, it no even has a doPrivileged! > jdk-9+175 was supposed to be the first GA candidate so this is why the pre-release identifier "ea" was dropped. Hopefully the Hadoop maintainers will read JEP 223 to see how to parse version strings going forward. -Alan. From robbiexgibson at yahoo.com Tue Jun 27 07:24:31 2017 From: robbiexgibson at yahoo.com (Robert Gibson) Date: Tue, 27 Jun 2017 09:24:31 +0200 Subject: Proposal (revised): Allow illegal access to internal APIs by default in JDK 9 Message-ID: <12FE7672-9709-4168-BD6D-689F2667F3ED@yahoo.com> Hi Mark, What is the intended interaction between this proposal and Java Web Start? I'm testing with JDK EA build 175 and it looks like a VM launched through Web Start is running with --illegal-access=deny, with no possibility of changing it - is this by design? (I have filed a few bugs in this area in case it is by accident, but they are not showing up in Jira, or they are targeted for JDK 10 which is obviously too late, if we are talking about unintentional behaviour.) Thanks, Robert From Alan.Bateman at oracle.com Tue Jun 27 07:34:20 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 27 Jun 2017 08:34:20 +0100 Subject: Proposal (revised): Allow illegal access to internal APIs by default in JDK 9 In-Reply-To: <12FE7672-9709-4168-BD6D-689F2667F3ED@yahoo.com> References: <12FE7672-9709-4168-BD6D-689F2667F3ED@yahoo.com> Message-ID: <4aa005fa-95b1-836c-cc60-8e166f5730f5@oracle.com> On 27/06/2017 08:24, Robert Gibson wrote: > Hi Mark, > What is the intended interaction between this proposal and Java Web Start? I'm testing with JDK EA build 175 and it looks like a VM launched through Web Start is running with --illegal-access=deny, with no possibility of changing it - is this by design? (I have filed a few bugs in this area in case it is by accident, but they are not showing up in Jira, or they are targeted for JDK 10 which is obviously too late, if we are talking about unintentional behaviour.) > Applets and JNLP applications are intentionally launched with `--illegal-access=deny`. If JNLP applications need to break into JDK classes then the finer grained `--add-exports` and `--add-opens` options can be specified in the JNLP. The Java Control Panel can also be used to specify `--illegal-access=permit` if needed too. -Alan From robbiexgibson at yahoo.com Tue Jun 27 07:46:36 2017 From: robbiexgibson at yahoo.com (Robert Gibson) Date: Tue, 27 Jun 2017 09:46:36 +0200 Subject: Proposal (revised): Allow illegal access to internal APIs by default in JDK 9 In-Reply-To: <4aa005fa-95b1-836c-cc60-8e166f5730f5@oracle.com> References: <12FE7672-9709-4168-BD6D-689F2667F3ED@yahoo.com> <4aa005fa-95b1-836c-cc60-8e166f5730f5@oracle.com> Message-ID: On 27 Jun 2017, at 09:34, Alan Bateman wrote: > >> On 27/06/2017 08:24, Robert Gibson wrote: >> Hi Mark, >> What is the intended interaction between this proposal and Java Web Start? I'm testing with JDK EA build 175 and it looks like a VM launched through Web Start is running with --illegal-access=deny, with no possibility of changing it - is this by design? (I have filed a few bugs in this area in case it is by accident, but they are not showing up in Jira, or they are targeted for JDK 10 which is obviously too late, if we are talking about unintentional behaviour.) >> > Applets and JNLP applications are intentionally launched with `--illegal-access=deny`. If JNLP applications need to break into JDK classes then the finer grained `--add-exports` and `--add-opens` options can be specified in the JNLP. The Java Control Panel can also be used to specify `--illegal-access=permit` if needed too. > > -Alan Hi Alan, Thanks for your quick response. No debug option? Robert From Alan.Bateman at oracle.com Tue Jun 27 08:18:52 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 27 Jun 2017 09:18:52 +0100 Subject: Proposal (revised): Allow illegal access to internal APIs by default in JDK 9 In-Reply-To: References: <12FE7672-9709-4168-BD6D-689F2667F3ED@yahoo.com> <4aa005fa-95b1-836c-cc60-8e166f5730f5@oracle.com> Message-ID: <6ead8902-ea06-0874-60b9-3ebb1b25e7f2@oracle.com> On 27/06/2017 08:46, Robert Gibson wrote: > : > Hi Alan, > Thanks for your quick response. No debug option? > Not in the JNLP but you should be able to use the Java Control Panel to add `--illegal-access=debug`. -Alan. From gunnar at hibernate.org Tue Jun 27 13:28:54 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Tue, 27 Jun 2017 15:28:54 +0200 Subject: Missing translation for "--illegal-access"; Hadoop problems with build 175 In-Reply-To: <7906db8f-bec2-e978-6681-d14c9d4a3d62@oracle.com> References: <007d01d2ee4e$d98bc000$8ca34000$@apache.org> <7906db8f-bec2-e978-6681-d14c9d4a3d62@oracle.com> Message-ID: > jdk-9+175 was supposed to be the first GA candidate so this is > why the pre-release identifier "ea" was dropped. Hopefully the > Hadoop maintainers will read JEP 223 to see how to parse version > strings going forward. I noticed that at least two popular Maven plug-ins are affected, too: the Maven JavaDoc plug-in and the Enforcer plug-in. They both use rather old versions of Apache Commons Lang (2.x) whose utility method SystemUtils#getJavaVersionAsFloat() runs into a StringIndexOutOfBoundsException due to the changed version format as of b175. Perhaps some Apache committers are present here who could take a look at this one? 2017-06-26 10:00 GMT+02:00 Alan Bateman : > On 26/06/2017 08:35, Uwe Schindler wrote: > >> : >> >> So I just wanted to give you some feedback that translations are >> obviously missing. FYI, the Linux version in English returns the correct >> text. >> > The last translation drop went into jdk-9+172 so it's out of sync with the > CLI/usage messages in builds since then. In addition to --illegal-access, > there are a few other changes to, and at least one new, error message(s) > that also need updated translations. > > >> FYI, the new version string (just "9") again caused some serious problem >> in open source projects. This time Hadoop, see >> https://issues.apache.org/jira/browse/HADOOP-14586. Issue is the >> following static final constant, leading to NoClassDefFound error and a >> cascade of classes no longer initializing: >> private static boolean IS_JAVA7_OR_ABOVE = >> System.getProperty("java.version").substring(0, >> 3).compareTo("1.7") >= 0; >> >> Damn! [image: ??] (the above code is IMHO just horrible wrong, never >> ever do something like this). In a ddition, it no even has a doPrivileged! >> >> jdk-9+175 was supposed to be the first GA candidate so this is why the > pre-release identifier "ea" was dropped. Hopefully the Hadoop maintainers > will read JEP 223 to see how to parse version strings going forward. > > -Alan. > From uschindler at apache.org Tue Jun 27 13:46:48 2017 From: uschindler at apache.org (Uwe Schindler) Date: Tue, 27 Jun 2017 15:46:48 +0200 Subject: Missing translation for "--illegal-access"; Hadoop problems with build 175 In-Reply-To: References: <007d01d2ee4e$d98bc000$8ca34000$@apache.org> <7906db8f-bec2-e978-6681-d14c9d4a3d62@oracle.com> Message-ID: <01d401d2ef4b$d511b9a0$7f352ce0$@apache.org> Hi, Could you please open issues on the two Maven plugins? Please be also sure that you first update your POM file to use the latest version of those plugins. Unfortunately, after a long discussion with Maven people, it does not seem to be possible that Maven enforces a higher plugin version automatically (for commonly used plugins like javadocs, compiler,?) if Java 9 is detected. This brings the additional burden of migrating legacy POMs up to newer plugin versions ? unfortunately. About the issue in commons-lang: Unfortunately I am not sure if the old commons-lang v2 is still maintained (I think it?s dead). So I think the two plugins should drop this dependency and migrate to a newer one, or use some other way of detecting Java versions. Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ From: gunnar.morling at googlemail.com [mailto:gunnar.morling at googlemail.com] On Behalf Of Gunnar Morling Sent: Tuesday, June 27, 2017 3:29 PM To: Alan Bateman Cc: Uwe Schindler ; jigsaw-dev ; jdk9-dev at openjdk.java.net Subject: Re: Missing translation for "--illegal-access"; Hadoop problems with build 175 > jdk-9+175 was supposed to be the first GA candidate so this is > why the pre-release identifier "ea" was dropped. Hopefully the > Hadoop maintainers will read JEP 223 to see how to parse version > strings going forward. I noticed that at least two popular Maven plug-ins are affected, too: the Maven JavaDoc plug-in and the Enforcer plug-in. They both use rather old versions of Apache Commons Lang (2.x) whose utility method SystemUtils#getJavaVersionAsFloat() runs into a StringIndexOutOfBoundsException due to the changed version format as of b175. Perhaps some Apache committers are present here who could take a look at this one? 2017-06-26 10:00 GMT+02:00 Alan Bateman >: On 26/06/2017 08:35, Uwe Schindler wrote: : So I just wanted to give you some feedback that translations are obviously missing. FYI, the Linux version in English returns the correct text. The last translation drop went into jdk-9+172 so it's out of sync with the CLI/usage messages in builds since then. In addition to --illegal-access, there are a few other changes to, and at least one new, error message(s) that also need updated translations. FYI, the new version string (just "9") again caused some serious problem in open source projects. This time Hadoop, see https://issues.apache.org/jira/browse/HADOOP-14586. Issue is the following static final constant, leading to NoClassDefFound error and a cascade of classes no longer initializing: private static boolean IS_JAVA7_OR_ABOVE = System.getProperty("java.version").substring(0, 3).compareTo("1.7") >= 0; Damn! (the above code is IMHO just horrible wrong, never ever do something like this). In a ddition, it no even has a doPrivileged! jdk-9+175 was supposed to be the first GA candidate so this is why the pre-release identifier "ea" was dropped. Hopefully the Hadoop maintainers will read JEP 223 to see how to parse version strings going forward. -Alan. From gunnar at hibernate.org Tue Jun 27 15:07:57 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Tue, 27 Jun 2017 17:07:57 +0200 Subject: Missing translation for "--illegal-access"; Hadoop problems with build 175 In-Reply-To: <01d401d2ef4b$d511b9a0$7f352ce0$@apache.org> References: <007d01d2ee4e$d98bc000$8ca34000$@apache.org> <7906db8f-bec2-e978-6681-d14c9d4a3d62@oracle.com> <01d401d2ef4b$d511b9a0$7f352ce0$@apache.org> Message-ID: I am using the latest released versions. But they plug-in developers are aware of that compatibility issue with b175: the Enforcer plug-in has been updated to Commons Lang 3.5 just yesterday, for the JavaDoc plug-in a pull request is pending. So I'd hope the issue will be fixed in the next released versions of those plug-ins. 2017-06-27 15:46 GMT+02:00 Uwe Schindler : > Hi, > > > > Could you please open issues on the two Maven plugins? Please be also sure > that you first update your POM file to use the latest version of those > plugins. Unfortunately, after a long discussion with Maven people, it does > not seem to be possible that Maven enforces a higher plugin version > automatically (for commonly used plugins like javadocs, compiler,?) if Java > 9 is detected. This brings the additional burden of migrating legacy POMs up > to newer plugin versions ? unfortunately. > > > > About the issue in commons-lang: Unfortunately I am not sure if the old > commons-lang v2 is still maintained (I think it?s dead). So I think the two > plugins should drop this dependency and migrate to a newer one, or use some > other way of detecting Java versions. > > > > Uwe > > > > ----- > > Uwe Schindler > > uschindler at apache.org > > ASF Member, Apache Lucene PMC / Committer > > Bremen, Germany > > http://lucene.apache.org/ > > > > From: gunnar.morling at googlemail.com [mailto:gunnar.morling at googlemail.com] > On Behalf Of Gunnar Morling > Sent: Tuesday, June 27, 2017 3:29 PM > To: Alan Bateman > Cc: Uwe Schindler ; jigsaw-dev > ; jdk9-dev at openjdk.java.net > Subject: Re: Missing translation for "--illegal-access"; Hadoop problems > with build 175 > > > >> jdk-9+175 was supposed to be the first GA candidate so this is > >> why the pre-release identifier "ea" was dropped. Hopefully the > >> Hadoop maintainers will read JEP 223 to see how to parse version > >> strings going forward. > > > > I noticed that at least two popular Maven plug-ins are affected, too: the > Maven JavaDoc plug-in and the Enforcer plug-in. > > > > They both use rather old versions of Apache Commons Lang (2.x) whose utility > method SystemUtils#getJavaVersionAsFloat() runs into a > StringIndexOutOfBoundsException due to the changed version format as of > b175. Perhaps some Apache committers are present here who could take a look > at this one? > > > > > > > > > > > > 2017-06-26 10:00 GMT+02:00 Alan Bateman : > > On 26/06/2017 08:35, Uwe Schindler wrote: > > : > > So I just wanted to give you some feedback that translations are obviously > missing. FYI, the Linux version in English returns the correct text. > > The last translation drop went into jdk-9+172 so it's out of sync with the > CLI/usage messages in builds since then. In addition to --illegal-access, > there are a few other changes to, and at least one new, error message(s) > that also need updated translations. > > > FYI, the new version string (just "9") again caused some serious problem in > open source projects. This time Hadoop, see > https://issues.apache.org/jira/browse/HADOOP-14586. Issue is the following > static final constant, leading to NoClassDefFound error and a cascade of > classes no longer initializing: > private static boolean IS_JAVA7_OR_ABOVE = > System.getProperty("java.version").substring(0, 3).compareTo("1.7") >>= 0; > > Damn! (the above code is IMHO just horrible wrong, never ever do something > like this). In a ddition, it no even has a doPrivileged! > > jdk-9+175 was supposed to be the first GA candidate so this is why the > pre-release identifier "ea" was dropped. Hopefully the Hadoop maintainers > will read JEP 223 to see how to parse version strings going forward. > > -Alan. > > From sesuncedu at gmail.com Tue Jun 27 19:59:48 2017 From: sesuncedu at gmail.com (Simon Spero) Date: Tue, 27 Jun 2017 15:59:48 -0400 Subject: Missing translation for "--illegal-access"; Hadoop problems with build 175 In-Reply-To: References: <007d01d2ee4e$d98bc000$8ca34000$@apache.org> <7906db8f-bec2-e978-6681-d14c9d4a3d62@oracle.com> <01d401d2ef4b$d511b9a0$7f352ce0$@apache.org> Message-ID: On Tue, Jun 27, 2017 at 11:07 AM, Gunnar Morling wrote: > I am using the latest released versions. But they plug-in developers are > aware of that compatibility issue with b175: the Enforcer plug-in has been > updated to Commons Lang 3.5 just yesterday, for the JavaDoc plug-in a pull > request is pending. > FYSA: commons-lang 3.5 has a bit better version support, but it is not real 223?. The latest release of commons-lang is 3.6, which is the first version tested with jdk 9. https://issues.apache.org/jira/projects/LANG/versions/12338238 Note that in order for some unit tests to pass, the test runner has to open java.lang and java.lang.reflect. https://issues.apache.org/jira/browse/LANG-1265 Simon ? More 556 - it'll probably work, but it blow up in your face. It would be nice if j.l.Runtime.Version could be used, but that begs the question. From sesuncedu at gmail.com Tue Jun 27 21:32:07 2017 From: sesuncedu at gmail.com (Simon Spero) Date: Tue, 27 Jun 2017 17:32:07 -0400 Subject: Missing translation for "--illegal-access"; Hadoop problems with build 175 In-Reply-To: References: <007d01d2ee4e$d98bc000$8ca34000$@apache.org> <7906db8f-bec2-e978-6681-d14c9d4a3d62@oracle.com> <01d401d2ef4b$d511b9a0$7f352ce0$@apache.org> Message-ID: Of course, the existing commons-lang code is looking at java.specification.version, which according to .223 need not change for new versions of the specification. " The minor version number, incremented for a minor update release that may contain [..] revisions to standard APIs mandated by a Maintenance Release of the relevant Platform Specification" But Minor #1 (GA) java.version 1.9.0_20 9.1.2 java.specification.version 1.9 9 So it's all, um, good? From robbiexgibson at yahoo.com Wed Jun 28 07:54:11 2017 From: robbiexgibson at yahoo.com (Robert Gibson) Date: Wed, 28 Jun 2017 09:54:11 +0200 Subject: Proposal (revised): Allow illegal access to internal APIs by default in JDK 9 In-Reply-To: <6ead8902-ea06-0874-60b9-3ebb1b25e7f2@oracle.com> References: <12FE7672-9709-4168-BD6D-689F2667F3ED@yahoo.com> <4aa005fa-95b1-836c-cc60-8e166f5730f5@oracle.com> <6ead8902-ea06-0874-60b9-3ebb1b25e7f2@oracle.com> Message-ID: <4078F6B6-C687-4AF2-981D-AEEC082E60C8@yahoo.com> > On 27 Jun 2017, at 10:18, Alan Bateman wrote: > > > >> On 27/06/2017 08:46, Robert Gibson wrote: >> : >> Hi Alan, >> Thanks for your quick response. No debug option? >> > Not in the JNLP but you should be able to use the Java Control Panel to add `--illegal-access=debug`. > > -Alan. Thanks for the follow-up: the debug option doesn't seem to work, bug report filed as 9049772 - hope it doesn't get targeted to 10 ;) Regards, Robert From Alan.Bateman at oracle.com Wed Jun 28 08:57:42 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 28 Jun 2017 09:57:42 +0100 Subject: Proposal (revised): Allow illegal access to internal APIs by default in JDK 9 In-Reply-To: <4078F6B6-C687-4AF2-981D-AEEC082E60C8@yahoo.com> References: <12FE7672-9709-4168-BD6D-689F2667F3ED@yahoo.com> <4aa005fa-95b1-836c-cc60-8e166f5730f5@oracle.com> <6ead8902-ea06-0874-60b9-3ebb1b25e7f2@oracle.com> <4078F6B6-C687-4AF2-981D-AEEC082E60C8@yahoo.com> Message-ID: <28f2433f-e949-426b-f675-148644aa9e1a@oracle.com> On 28/06/2017 08:54, Robert Gibson wrote: > : > Thanks for the follow-up: the debug option doesn't seem to work, bug report filed as 9049772 - hope it doesn't get targeted to 10 ;) > If the illegal access is succeeding then it means Java Web Start has picked up the option that you added via Control Panel. I can't tell if you are opened the JNLP in the browser or using the `javaws` CLI but I assume this issue is about where stderr has been directed. -Alan From forax at univ-mlv.fr Wed Jun 28 11:12:57 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 28 Jun 2017 13:12:57 +0200 (CEST) Subject: Non Standadrd Module Attribute Message-ID: <491260050.1686448.1498648377024.JavaMail.zimbra@u-pem.fr> Hi Alan, hi all, i've implemented the non standard attributes ModuleTarget, ModuleHashes and ModuleResolution in ASM. First, given that i was not able to find a document that describe them, i've used the javadoc of the classes inside jdk.internal.module.ClassFileAttributes. I've discovered that the jdk modules have an attribute ModuleTarget that can have a null platform, why not removing the ModuleTarget attribute from the module-info instead ? And for the module jdk.incubator.httpclient, the value of the resolution is 9, so it means DO_NOT_RESOLVE_BY_DEFAULT | WARN_INCUBATING; What is the exact meaning of DO_NOT_RESOLVE_BY_DEFAULT ? regards, R?mi From Alan.Bateman at oracle.com Wed Jun 28 12:22:23 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 28 Jun 2017 13:22:23 +0100 Subject: Non Standadrd Module Attribute In-Reply-To: <491260050.1686448.1498648377024.JavaMail.zimbra@u-pem.fr> References: <491260050.1686448.1498648377024.JavaMail.zimbra@u-pem.fr> Message-ID: On 28/06/2017 12:12, Remi Forax wrote: > Hi Alan, hi all, > i've implemented the non standard attributes ModuleTarget, ModuleHashes and ModuleResolution in ASM. > > First, given that i was not able to find a document that describe them, i've used the javadoc of the classes inside jdk.internal.module.ClassFileAttributes. JEP 261 needs a big update and I think is the right place to document the JDK-specific class file attributes (except maybe ModuleResolution where they could be a case to document it in JEP 11 instead). > I've discovered that the jdk modules have an attribute ModuleTarget that can have a null platform, why not removing the ModuleTarget attribute from the module-info instead ? The ModuleTarget attribute is removed at link time from all modules except java.base (need to retain it in java.base to allow it be compared with any platform specific modules on the module path). The jlink system modules plugin has an option to retain the ModuleTarget attribute if you want. As regards allowing the target_platform to be 0 (meaning not present) then it may be a left over from when the attribute had multiple values - it was possible for it to only have the OS name or architecture for example. > And for the module jdk.incubator.httpclient, the value of the resolution is 9, so it means DO_NOT_RESOLVE_BY_DEFAULT | WARN_INCUBATING; > What is the exact meaning of DO_NOT_RESOLVE_BY_DEFAULT ? > From JEP 11 "incubator modules are not resolved by default for applications on the class path". -Alan From robbiexgibson at yahoo.com Wed Jun 28 13:46:54 2017 From: robbiexgibson at yahoo.com (Robert Gibson) Date: Wed, 28 Jun 2017 15:46:54 +0200 Subject: Proposal (revised): Allow illegal access to internal APIs by default in JDK 9 In-Reply-To: <28f2433f-e949-426b-f675-148644aa9e1a@oracle.com> References: <12FE7672-9709-4168-BD6D-689F2667F3ED@yahoo.com> <4aa005fa-95b1-836c-cc60-8e166f5730f5@oracle.com> <6ead8902-ea06-0874-60b9-3ebb1b25e7f2@oracle.com> <4078F6B6-C687-4AF2-981D-AEEC082E60C8@yahoo.com> <28f2433f-e949-426b-f675-148644aa9e1a@oracle.com> Message-ID: > On 28 Jun 2017, at 10:57, Alan Bateman wrote: > If the illegal access is succeeding then it means Java Web Start has picked up the option that you added via Control Panel. I can't tell if you are opened the JNLP in the browser or using the `javaws` CLI but I assume this issue is about where stderr has been directed. > > -Alan Sure. (It actually doesn't make any difference how the app is started, browser or javaws, results are the same in either case.) Filed as JDK-8183110. Thanks, Robert From Alan.Bateman at oracle.com Wed Jun 28 15:31:09 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 28 Jun 2017 16:31:09 +0100 Subject: Proposal (revised): Allow illegal access to internal APIs by default in JDK 9 In-Reply-To: References: <12FE7672-9709-4168-BD6D-689F2667F3ED@yahoo.com> <4aa005fa-95b1-836c-cc60-8e166f5730f5@oracle.com> <6ead8902-ea06-0874-60b9-3ebb1b25e7f2@oracle.com> <4078F6B6-C687-4AF2-981D-AEEC082E60C8@yahoo.com> <28f2433f-e949-426b-f675-148644aa9e1a@oracle.com> Message-ID: <01ac773d-b0d2-54bb-cf75-0bbb2be85a4a@oracle.com> On 28/06/2017 14:46, Robert Gibson wrote: > Sure. > (It actually doesn't make any difference how the app is started, browser or javaws, results are the same in either case.) > > Can you confirm that this is Windows only? Andy tells me that javaws.exe is the equivalent of javaw.exe rather than java.exe, which is why I'm asking. -Alan From robbiexgibson at yahoo.com Wed Jun 28 15:40:48 2017 From: robbiexgibson at yahoo.com (Robert Gibson) Date: Wed, 28 Jun 2017 17:40:48 +0200 Subject: Proposal (revised): Allow illegal access to internal APIs by default in JDK 9 In-Reply-To: <01ac773d-b0d2-54bb-cf75-0bbb2be85a4a@oracle.com> References: <12FE7672-9709-4168-BD6D-689F2667F3ED@yahoo.com> <4aa005fa-95b1-836c-cc60-8e166f5730f5@oracle.com> <6ead8902-ea06-0874-60b9-3ebb1b25e7f2@oracle.com> <4078F6B6-C687-4AF2-981D-AEEC082E60C8@yahoo.com> <28f2433f-e949-426b-f675-148644aa9e1a@oracle.com> <01ac773d-b0d2-54bb-cf75-0bbb2be85a4a@oracle.com> Message-ID: On 28 Jun 2017, at 17:31, Alan Bateman wrote: > > On 28/06/2017 14:46, Robert Gibson wrote: >> Sure. >> (It actually doesn't make any difference how the app is started, browser or javaws, results are the same in either case.) >> >> > Can you confirm that this is Windows only? Andy tells me that javaws.exe is the equivalent of javaw.exe rather than java.exe, which is why I'm asking. > > -Alan Sorry, the only Linux environments I have access to are headless and Web Start doesn?t start (no X11 libraries). Robert From forax at univ-mlv.fr Thu Jun 29 02:04:29 2017 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 29 Jun 2017 04:04:29 +0200 (CEST) Subject: Non Standadrd Module Attribute In-Reply-To: References: <491260050.1686448.1498648377024.JavaMail.zimbra@u-pem.fr> Message-ID: <819517103.1941373.1498701869362.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Alan Bateman" > ?: "Remi Forax" , "jigsaw-dev" > Envoy?: Mercredi 28 Juin 2017 14:22:23 > Objet: Re: Non Standadrd Module Attribute > On 28/06/2017 12:12, Remi Forax wrote: >> Hi Alan, hi all, >> i've implemented the non standard attributes ModuleTarget, ModuleHashes and >> ModuleResolution in ASM. >> >> First, given that i was not able to find a document that describe them, i've >> used the javadoc of the classes inside jdk.internal.module.ClassFileAttributes. > JEP 261 needs a big update and I think is the right place to document > the JDK-specific class file attributes (except maybe ModuleResolution > where they could be a case to document it in JEP 11 instead). > >> I've discovered that the jdk modules have an attribute ModuleTarget that can >> have a null platform, why not removing the ModuleTarget attribute from the >> module-info instead ? > The ModuleTarget attribute is removed at link time from all modules > except java.base (need to retain it in java.base to allow it be compared > with any platform specific modules on the module path). The jlink system > modules plugin has an option to retain the ModuleTarget attribute if you > want. > > As regards allowing the target_platform to be 0 (meaning not present) > then it may be a left over from when the attribute had multiple values - > it was possible for it to only have the OS name or architecture for example. yes, it's what i'm believing too. To take an example, currently, the module-info of java.sql as n attribute ModuleTarget which is empty, IMO only java.base should have a module attribute ModuleTarget. > >> And for the module jdk.incubator.httpclient, the value of the resolution is 9, >> so it means DO_NOT_RESOLVE_BY_DEFAULT | WARN_INCUBATING; >> What is the exact meaning of DO_NOT_RESOLVE_BY_DEFAULT ? >> > From JEP 11 "incubator modules are not resolved by default for > applications on the class path". in that case why java.xml.bind which is not resolved by default too, does not have an attribute ModuleResolution ? > > -Alan R?mi From Alan.Bateman at oracle.com Thu Jun 29 08:12:02 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 29 Jun 2017 09:12:02 +0100 Subject: Non Standadrd Module Attribute In-Reply-To: <819517103.1941373.1498701869362.JavaMail.zimbra@u-pem.fr> References: <491260050.1686448.1498648377024.JavaMail.zimbra@u-pem.fr> <819517103.1941373.1498701869362.JavaMail.zimbra@u-pem.fr> Message-ID: <896203f6-96b0-18d8-eaea-3121a7104662@oracle.com> On 29/06/2017 03:04, forax at univ-mlv.fr wrote: > : > yes, it's what i'm believing too. > To take an example, currently, the module-info of java.sql as n attribute ModuleTarget which is empty, IMO only java.base should have a module attribute ModuleTarget. Okay, I understand what you are saying now. When the jlink plugin re-writes the module-info.class in the jimage file then it amounts to changing the target_platform_index to 0 rather than removing the ModuleTarget attribute completely. This is benign because the system ModuleFinder doesn't parse module-info.class resources in the image, and if it did, it tolerates the target_platform_index being 0. I'm guessing you see it because you are reading the module-info.class in the jimage container. >> : >> >> From JEP 11 "incubator modules are not resolved by default for >> applications on the class path". > in that case why java.xml.bind which is not resolved by default too, does not have an attribute ModuleResolution ? > The policy in JEP 261 for the default set of root modules pre-dates this attribute. Yes, it would be possible to implement that policy (or a slight variation of) using this attribute although it would introduce a small inconsistency for the upgrade module path, say where you deployed an upgraded version of java.xml.bind that didn't have the attribute - would you want that to be resolved because it exports an API? -Alan From alexander.udalov at jetbrains.com Fri Jun 30 16:41:32 2017 From: alexander.udalov at jetbrains.com (Alexander Udalov) Date: Fri, 30 Jun 2017 19:41:32 +0300 Subject: Exporting a package with no Java sources Message-ID: 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 mark.reinhold at oracle.com Fri Jun 30 21:36:08 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 30 Jun 2017 14:36:08 -0700 (PDT) Subject: RFR 8182776/8183161/8183251: Miscellaneous API doc fixes Message-ID: <20170630213608.0A5718091A@eggemoggin.niobe.net> 8182776: Fix typo "upgradeble" in the javadoc of upgradeable modules 8183161: Remove extraneous font-family style attributes from module declarations 8183251: Meta "keywords" tag malformed in overview-summary.html and related pages http://cr.openjdk.java.net/~mr/rev/8182776/jdk9-dev.patch http://cr.openjdk.java.net/~mr/rev/8182776/api/ (sample output) None of these is truly P1 but they're all fairly embarrassing and the fixes are low-risk, so since we know we're going to do another build next week anyway I'd like to include this patch. The fix for 8183251 doesn't solve the problem of `

` occurring inside `

`, but this only ever happens in the frame-summary pages and appears to do no harm when rendered. This patch includes a few minor editorial fixes, e.g., changing `@link` tags to `@linkplain` where appropriate in module declarations. Thanks, - Mark From jonathan.gibbons at oracle.com Fri Jun 30 23:08:09 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 30 Jun 2017 16:08:09 -0700 Subject: RFR 8182776/8183161/8183251: Miscellaneous API doc fixes In-Reply-To: <20170630213608.0A5718091A@eggemoggin.niobe.net> References: <20170630213608.0A5718091A@eggemoggin.niobe.net> Message-ID: <5956D9D9.1010104@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 And for those that can see images in line: Screnshot of mismatched header fonts The screenshot has also been attached to the appropriate bug: JDK-8183161 I would recommend that JDK-8183161 should be "Not An Issue" and the changes reverted in the proposed patch. -- Jon On 06/30/2017 02:36 PM, mark.reinhold at oracle.com wrote: > 8182776: Fix typo "upgradeble" in the javadoc of upgradeable modules > 8183161: Remove extraneous font-family style attributes from module declarations > 8183251: Meta "keywords" tag malformed in overview-summary.html and related pages > > http://cr.openjdk.java.net/~mr/rev/8182776/jdk9-dev.patch > http://cr.openjdk.java.net/~mr/rev/8182776/api/ (sample output) > > None of these is truly P1 but they're all fairly embarrassing and the > fixes are low-risk, so since we know we're going to do another build next > week anyway I'd like to include this patch. > > The fix for 8183251 doesn't solve the problem of `
` occurring inside > `

`, but this only ever happens in the frame-summary pages and appears > to do no harm when rendered. > > This patch includes a few minor editorial fixes, e.g., changing `@link` > tags to `@linkplain` where appropriate in module declarations. > > Thanks, > - Mark