hg: jigsaw/jake/jdk: Add test for checking StackTraceElement format
Changeset: e0864f0eb268 Author:mchung Date: 2016-09-15 15:17 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e0864f0eb268 Add test for checking StackTraceElement format + test/java/lang/StackTraceElement/SerialTest.java
hg: jigsaw/jake/jaxp: 6 new changesets
Changeset: bba703e3281b Author:joehw Date: 2016-09-07 11:00 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/bba703e3281b 8165116: redirect function is not allowed even with enableExtensionFunctions Reviewed-by: lancea ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/TransletOutput.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/AbstractTranslet.java ! test/javax/xml/jaxp/unittest/transform/XSLTFunctionsTest.java Changeset: 540334ae53fe Author:fyuan Date: 2016-09-08 12:33 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/540334ae53fe 8165617: Cleanup whitespace in jaxp/test Summary: Removed the extra LF from the java files Reviewed-by: joehw ! src/java.xml/share/classes/javax/xml/datatype/XMLGregorianCalendar.java ! src/java.xml/share/classes/module-info.java ! src/jdk.xml.dom/share/classes/module-info.java ! test/javax/xml/jaxp/functional/javax/xml/datatype/ptests/DurationTest.java ! test/javax/xml/jaxp/functional/javax/xml/datatype/ptests/FactoryNewInstanceTest.java ! test/javax/xml/jaxp/functional/javax/xml/datatype/ptests/XMLGregorianCalendarTest.java ! test/javax/xml/jaxp/functional/javax/xml/parsers/ptests/DBFNamespaceTest.java ! test/javax/xml/jaxp/functional/javax/xml/parsers/ptests/DocumentBuilderFactoryTest.java ! test/javax/xml/jaxp/functional/javax/xml/parsers/ptests/DocumentBuilderImpl01.java ! test/javax/xml/jaxp/functional/javax/xml/parsers/ptests/FactoryConfErrorTest.java ! test/javax/xml/jaxp/functional/javax/xml/parsers/ptests/SAXFactoryNewInstanceTest.java ! test/javax/xml/jaxp/functional/javax/xml/parsers/ptests/SAXParserFactTest.java ! test/javax/xml/jaxp/functional/javax/xml/parsers/ptests/SAXParserTest.java ! test/javax/xml/jaxp/functional/javax/xml/parsers/ptests/SAXParserTest02.java ! test/javax/xml/jaxp/functional/javax/xml/parsers/ptests/SAXParserTest03.java ! test/javax/xml/jaxp/functional/javax/xml/stream/ptests/XMLEventFactoryNewInstanceTest.java ! test/javax/xml/jaxp/functional/javax/xml/stream/ptests/XMLInputFactoryNewInstanceTest.java ! test/javax/xml/jaxp/functional/javax/xml/transform/ptests/Bug6384418Test.java ! test/javax/xml/jaxp/functional/javax/xml/transform/ptests/DOMResultTest.java ! test/javax/xml/jaxp/functional/javax/xml/transform/ptests/ErrorListenerTest.java ! test/javax/xml/jaxp/functional/javax/xml/transform/ptests/SAXSourceTest.java ! test/javax/xml/jaxp/functional/javax/xml/transform/ptests/SAXTFactoryTest.java ! test/javax/xml/jaxp/functional/javax/xml/transform/ptests/StreamResultTest.java ! test/javax/xml/jaxp/functional/javax/xml/transform/ptests/TfClearParamTest.java ! test/javax/xml/jaxp/functional/javax/xml/transform/ptests/TransformTest.java ! test/javax/xml/jaxp/functional/javax/xml/transform/ptests/TransformerExcpTest.java ! test/javax/xml/jaxp/functional/javax/xml/transform/ptests/TransformerFactoryTest.java ! test/javax/xml/jaxp/functional/javax/xml/transform/ptests/TransformerTest.java ! test/javax/xml/jaxp/functional/javax/xml/transform/ptests/TransformerTest02.java ! test/javax/xml/jaxp/functional/javax/xml/transform/ptests/TransformerTest03.java ! test/javax/xml/jaxp/functional/javax/xml/transform/ptests/URIResolverTest.java ! test/javax/xml/jaxp/functional/javax/xml/transform/ptests/othervm/TFCErrorTest.java ! test/javax/xml/jaxp/functional/javax/xml/validation/ptests/SchemaFactoryTest.java ! test/javax/xml/jaxp/functional/javax/xml/validation/ptests/TypeInfoProviderTest.java ! test/javax/xml/jaxp/functional/javax/xml/validation/ptests/ValidatorHandlerTest.java ! test/javax/xml/jaxp/functional/javax/xml/validation/ptests/ValidatorTest.java ! test/javax/xml/jaxp/functional/javax/xml/xpath/ptests/XPathExpressionTest.java ! test/javax/xml/jaxp/functional/javax/xml/xpath/ptests/XPathFactoryTest.java ! test/javax/xml/jaxp/functional/javax/xml/xpath/ptests/XPathFunctionResolverTest.java ! test/javax/xml/jaxp/functional/javax/xml/xpath/ptests/XPathTest.java ! test/javax/xml/jaxp/functional/org/w3c/dom/ptests/AttrTest.java ! test/javax/xml/jaxp/functional/org/w3c/dom/ptests/CommentTest.java ! test/javax/xml/jaxp/functional/org/w3c/dom/ptests/DocumentTest.java ! test/javax/xml/jaxp/functional/org/w3c/dom/ptests/DocumentTypeTest.java ! test/javax/xml/jaxp/functional/org/w3c/dom/ptests/DomImplementationTest.java ! test/javax/xml/jaxp/functional/org/w3c/dom/ptests/ElementTest.java ! test/javax/xml/jaxp/functional/org/w3c/dom/ptests/EntityChildTest.java ! test/javax/xml/jaxp/functional/org/w3c/dom/ptests/NamedNodeMapTest.java ! test/javax/xml/jaxp/functional/org/w3c/dom/ptests/NodeListTest.java ! test/javax/xml/jaxp/functional/org/w3c/dom/ptests/NodeTest.java ! test/javax/xml/jaxp/functional/org/w3c/dom/ptests/NotationTest.java ! test/javax/xml/jaxp/functional/org/w3c/dom/ptests/PITest.java ! test/javax/xml/jaxp/functional/org/w3c/dom/ptests/TextTest.java ! test/javax/xml/jaxp/functional/org/w3c/dom/ptests/TypeInfoT
hg: jigsaw/jake: 7 new changesets
Changeset: 24efaaddd376 Author:sundar Date: 2016-09-08 14:35 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/24efaaddd376 8165595: Main class should be set for nashorn modules Reviewed-by: jlaskey, erikj ! make/CreateJmods.gmk Changeset: 6e62bbd02e6b Author:lana Date: 2016-09-08 22:13 + URL: http://hg.openjdk.java.net/jigsaw/jake/rev/6e62bbd02e6b Merge Changeset: 3a0e05d75dec Author:sundar Date: 2016-09-12 18:25 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/3a0e05d75dec 8165772: fix for 8165595 results in failure of jdk/test/tools/launcher/VersionCheck.java Reviewed-by: alanb, jlaskey ! make/CreateJmods.gmk Changeset: 3ec350f5f32a Author:naoto Date: 2016-09-12 09:38 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/3ec350f5f32a 8165605: Thai resources in jdk.localedata cause split package issue with java.base Reviewed-by: mchung, erikj ! make/CompileJavaModules.gmk Changeset: 1da725c7601e Author:mchung Date: 2016-09-15 13:14 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/1da725c7601e Merge ! make/CompileJavaModules.gmk ! make/CreateJmods.gmk Changeset: 73b0b2cf7c44 Author:lana Date: 2016-09-15 17:15 + URL: http://hg.openjdk.java.net/jigsaw/jake/rev/73b0b2cf7c44 Added tag jdk-9+136 for changeset 3ec350f5f32a ! .hgtags Changeset: 7b25afe560e2 Author:mchung Date: 2016-09-15 13:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/7b25afe560e2 Merge
hg: jigsaw/jake/langtools: 7 new changesets
Changeset: 589ff4d43428 Author:vromero Date: 2016-09-06 17:04 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/589ff4d43428 8162546: change hidden options -Xdebug to --debug, -XshouldStop to --should-stop, and -diags to --diags Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/options/Options.java ! src/jdk.jshell/share/classes/jdk/jshell/TaskFactory.java ! test/tools/javac/ClassFileModifiers/ClassModifiers.java ! test/tools/javac/ClassFileModifiers/MemberModifiers.java ! test/tools/javac/Diagnostics/6722234/T6722234a.java ! test/tools/javac/Diagnostics/6722234/T6722234b.java ! test/tools/javac/Diagnostics/6722234/T6722234c.java ! test/tools/javac/Diagnostics/6722234/T6722234d.java ! test/tools/javac/Diagnostics/6862608/T6862608a.java ! test/tools/javac/Diagnostics/6862608/T6862608b.java ! test/tools/javac/Diagnostics/7010608/Test.java ! test/tools/javac/Diagnostics/8010387/T8010387.java ! test/tools/javac/InterfaceMemberClassModifiers.java ! test/tools/javac/T5003235/T5003235a.java ! test/tools/javac/T5003235/T5003235b.java ! test/tools/javac/T6214885.java ! test/tools/javac/T8026963/TypeAnnotationsCrashWithErroneousTreeTest.java ! test/tools/javac/annotations/neg/8022765/VerifyErroneousAnnotationsAttributed.java ! test/tools/javac/annotations/typeAnnotations/newlocations/AfterMethodTypeParams.java ! test/tools/javac/api/6731573/T6731573.java ! test/tools/javac/api/taskListeners/EventsBalancedTest.java ! test/tools/javac/completionDeps/DepsAndAnno.java ! test/tools/javac/completionDeps/DepsAndDocLint.java ! test/tools/javac/diags/CheckResourceKeys.java ! test/tools/javac/diags/examples/ApplicableMethodFound.java ! test/tools/javac/diags/examples/ApplicableMethodFound1.java ! test/tools/javac/diags/examples/DeferredMethodInst.java ! test/tools/javac/diags/examples/LambdaStat.java ! test/tools/javac/diags/examples/MrefStat.java ! test/tools/javac/diags/examples/MrefStat1.java ! test/tools/javac/diags/examples/NotApplicableMethodFound.java ! test/tools/javac/diags/examples/PartialInstSig.java ! test/tools/javac/diags/examples/VerboseResolveMulti.java ! test/tools/javac/diags/examples/VerboseResolveMulti1.java ! test/tools/javac/diags/examples/WhereCaptured.java ! test/tools/javac/diags/examples/WhereCaptured1.java ! test/tools/javac/diags/examples/WhereFreshTvar.java ! test/tools/javac/diags/examples/WhereIntersection.java ! test/tools/javac/diags/examples/WhereIntersection2.java ! test/tools/javac/diags/examples/WhereTypeVar.java ! test/tools/javac/diags/examples/WhereTypeVar2.java ! test/tools/javac/failover/CheckAttributedTree.java ! test/tools/javac/failover/FailOver01.java ! test/tools/javac/failover/FailOver02.java ! test/tools/javac/failover/FailOver03.java ! test/tools/javac/failover/FailOver04.java ! test/tools/javac/failover/FailOver05.java ! test/tools/javac/failover/FailOver06.java ! test/tools/javac/failover/FailOver07.java ! test/tools/javac/failover/FailOver08.java ! test/tools/javac/failover/FailOver09.java ! test/tools/javac/failover/FailOver10.java ! test/tools/javac/failover/FailOver11.java ! test/tools/javac/failover/FailOver12.java ! test/tools/javac/failover/FailOver13.java ! test/tools/javac/failover/FailOver14.java ! test/tools/javac/failover/FailOver15.java ! test/tools/javac/generics/inference/8158355/T8158355.java ! test/tools/javac/lambda/MostSpecific09.java ! test/tools/javac/lambda/MostSpecific09.out ! test/tools/javac/lambda/TestLambdaToMethodStats.java ! test/tools/javac/lambda/XDdumpLambdaToMethodStats.java ! test/tools/javac/lambda/bridge/TestMetafactoryBridges.java ! test/tools/javac/lambda/mostSpecific/StructuralMostSpecificTest.java ! test/tools/javac/missingSuperRecovery/MissingSuperRecovery.java ! test/tools/javac/modules/AddLimitMods.java ! test/tools/javac/policy/test3/Test.java ! test/tools/javac/positions/TreeEndPosTest.java ! test/tools/javac/protectedAccess/ProtectedMemberAccess2.java ! test/tools/javac/protectedAccess/ProtectedMemberAccess3.java ! test/tools/javac/protectedAccess/ProtectedMemberAccess4.java ! test/tools/javac/resolve/ResolveHarness.java ! test/tools/javac/unicode/UnicodeNewline.java ! test/tools/sjavac/JavacOptionPrep.java Changeset: e07ed6317649 Author:rfield Date: 2016-09-07 12:15 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/e07ed6317649 8080352: jshell tool: Error message for using "package" should be more descriptive than "Failed" Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/jdk/jshell/ReplParser.java ! test/jdk/jshell/RejectedFailedTest.java Changeset: 560204c4944f Author:jlahoda Date: 2016-09-08 15:48 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/560204c4944f 8131025: JShell: crash on tab-complete reference to bad class file Summary: Catching CompletionFai
hg: jigsaw/jake/nashorn: 5 new changesets
Changeset: 925e7b26b363 Author:hannesw Date: 2016-09-07 22:48 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/925e7b26b363 8077149: __noSuchProperty__ and __noSuchMethod__ invocations are not properly guarded Reviewed-by: jlaskey, mhaupt ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/SharedPropertyMap.java + test/script/basic/JDK-8077149.js Changeset: f11b8f5c4ccb Author:lana Date: 2016-09-08 22:13 + URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/f11b8f5c4ccb Merge Changeset: ea1e3e3e6d92 Author:mchung Date: 2016-09-15 13:14 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/ea1e3e3e6d92 Merge Changeset: 17ed43add2f9 Author:lana Date: 2016-09-15 17:15 + URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/17ed43add2f9 Added tag jdk-9+136 for changeset f11b8f5c4ccb ! .hgtags Changeset: 0f5a26cc67b0 Author:mchung Date: 2016-09-15 13:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/0f5a26cc67b0 Merge ! .hgtags
hg: jigsaw/jake/jdk: 37 new changesets
Changeset: 7c15548ab9d6 Author:shurailine Date: 2016-09-06 17:07 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7c15548ab9d6 8148859: Fix module dependences for java/time tests Reviewed-by: alanb, rriggs ! test/java/time/TEST.properties Changeset: 76ba1b74f268 Author:smarks Date: 2016-09-06 16:08 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/76ba1b74f268 8159404: throw UnsupportedOperationException unconditionally for mutator methods Reviewed-by: martin, psandoz ! src/java.base/share/classes/java/util/ImmutableCollections.java ! src/java.base/share/classes/java/util/List.java ! src/java.base/share/classes/java/util/Map.java ! src/java.base/share/classes/java/util/Set.java ! test/java/util/Collection/MOAT.java Changeset: 60d7fbe25cd7 Author:igerasim Date: 2016-09-07 10:14 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/60d7fbe25cd7 8165413: Typos in javadoc: extra period, wrong number, misspelled word Reviewed-by: weijun, mullan ! src/java.base/share/classes/java/security/DigestInputStream.java ! src/java.base/share/classes/java/security/KeyPairGenerator.java ! src/java.base/share/classes/java/security/SignatureSpi.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/SerialVersionUIDAdder.java ! src/java.base/share/classes/sun/security/ssl/ClientHandshaker.java ! src/java.desktop/share/classes/com/sun/media/sound/DLSInfo.java Changeset: c49bca5eedb3 Author:sundar Date: 2016-09-07 18:35 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c49bca5eedb3 8165503: jlink exclude VM plugin's handling of jvmlibs is wrong Reviewed-by: jlaskey ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ExcludeVMPlugin.java Changeset: 7916fca71cd6 Author:skovalev Date: 2016-09-07 10:04 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7916fca71cd6 8165604: Fix module dependencies for sun/util/* tests Reviewed-by: rriggs, naoto ! test/sun/util/locale/provider/Bug8038436.java ! test/sun/util/locale/provider/Bug8152817.java ! test/sun/util/resources/Calendar/Bug4518811.java ! test/sun/util/resources/Calendar/Bug4527203.java ! test/sun/util/resources/Locale/Bug4429024.java ! test/sun/util/resources/Locale/Bug4965260.java ! test/sun/util/resources/Locale/Bug6275682.java ! test/sun/util/resources/TimeZone/Bug4938846.java ! test/sun/util/resources/TimeZone/Bug6271396.java ! test/sun/util/resources/TimeZone/Bug6317929.java ! test/sun/util/resources/TimeZone/Bug6377794.java ! test/sun/util/resources/TimeZone/Bug6442006.java ! test/sun/util/resources/cldr/Bug8134250.java ! test/sun/util/resources/cldr/Bug8145136.java Changeset: fc1be68dffc8 Author:ksrini Date: 2016-09-07 10:58 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fc1be68dffc8 8151901: test/tools/pack200/Pack200Test fails on verifying native unpacked JAR Reviewed-by: jrose ! src/java.base/share/classes/com/sun/java/util/jar/pack/Package.java ! src/java.base/share/classes/com/sun/java/util/jar/pack/PackageReader.java ! test/ProblemList.txt ! test/tools/pack200/Pack200Test.java ! test/tools/pack200/pack200-verifier/data/golden.jar Changeset: 0ac0a3b43f0a Author:smarks Date: 2016-09-07 14:59 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0ac0a3b43f0a 8165636: add removal text to Runtime.traceInstructions/MethodCalls deprecation text Reviewed-by: iris, darcy, mchung ! src/java.base/share/classes/java/lang/Runtime.java Changeset: 30aba497f34e Author:sundar Date: 2016-09-08 20:21 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/30aba497f34e 8165697: jlink running on Mac with Windows jmods produces non-runnable image Reviewed-by: jlaskey, redestad ! src/jdk.jlink/share/classes/jdk/tools/jlink/builder/DefaultImageBuilder.java Changeset: 32540f1a8a70 Author:coffeys Date: 2016-09-08 16:16 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/32540f1a8a70 8165711: java/net/SetFactoryPermission/SetFactoryPermission.java needs to run in ovm mode Reviewed-by: chegar ! test/java/net/SetFactoryPermission/SetFactoryPermission.java Changeset: c2895dc9842f Author:mchung Date: 2016-09-08 09:45 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c2895dc9842f 8165563: ClassLoader::getSystemClassLoader will never be null Reviewed-by: alanb, dholmes, psandoz ! src/java.base/share/classes/java/lang/ClassLoader.java Changeset: 10d8bdeabfa5 Author:skovalev Date: 2016-09-08 09:59 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/10d8bdeabfa5 8165583: Fix module dependencies for jdk/java/util/* tests Reviewed-by: alanb ! test/java/util/Calendar/Bug4302966.java ! test/java/util/Date/Bug8135055.java ! test/java/util/Formatter/FormatLocale.java ! test/java/util/ResourceBundle/modules/security/TestPermission.java ! test/java/util/ServiceLoader/modules/ServicesTest.java ! test/java/util/T
hg: jigsaw/jake/jaxws: 2 new changesets
Changeset: 297c16d401c5 Author:lana Date: 2016-09-15 17:15 + URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/297c16d401c5 Added tag jdk-9+136 for changeset 09ec13a99f50 ! .hgtags Changeset: b70d94739d62 Author:mchung Date: 2016-09-15 13:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/b70d94739d62 Merge
hg: jigsaw/jake/corba: 2 new changesets
Changeset: 258cf18fa7fc Author:lana Date: 2016-09-15 17:15 + URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/258cf18fa7fc Added tag jdk-9+136 for changeset aa053a3faf26 ! .hgtags Changeset: cbdc0699e357 Author:mchung Date: 2016-09-15 13:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/cbdc0699e357 Merge
hg: jigsaw/jake/hotspot: 2 new changesets
Changeset: 6bddcf692e1d Author:lana Date: 2016-09-15 17:15 + URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6bddcf692e1d Added tag jdk-9+136 for changeset a20da289f646 ! .hgtags Changeset: 89d191b6c6ee Author:mchung Date: 2016-09-15 13:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/89d191b6c6ee Merge ! .hgtags
hg: jigsaw/jake/jdk: Fixup test @modules to access private field
Changeset: 570f2e8d2b6c Author:mchung Date: 2016-09-15 13:14 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/570f2e8d2b6c Fixup test @modules to access private field ! test/sun/security/krb5/tools/KtabZero.java
Re: #ServiceLoaderEnhancements
Best to wait for the spec. On 9/15/2016 12:34 PM, Peter Levart wrote: On 09/15/2016 05:51 PM, Alan Bateman wrote: On 15/09/2016 07:54, Peter Levart wrote: One thing that is not clear is whether the yyy in "provides xxx with yyy" directive of module declaration must be a concrete class and a subtype of service type when the service is obtained via a static method. For example, is the following a valid configuration: Service type A, implementation class B (a subtype of A), static method declared in C (unrelated to A) with return type B (or A or anything between A and B?). If yyy defines the static factory method then it does not need to be a sub-type of xxx, the return type from the public provider() method just needs to be xxx or a sub-type of. So the example is okay, no need for C to extend/implement A. I should note that the implementation isn't aligned with this yet but there are updates to both javac and SL coming that will align it with the current proposal. -Alan ...so yyy can be any class or interface. It's provider() method can even instantiate and return an instance of some class that is not part of the module that provides the service. Hm... Regards, Peter
Re: #ServiceLoaderEnhancements
On 09/15/2016 05:51 PM, Alan Bateman wrote: On 15/09/2016 07:54, Peter Levart wrote: One thing that is not clear is whether the yyy in "provides xxx with yyy" directive of module declaration must be a concrete class and a subtype of service type when the service is obtained via a static method. For example, is the following a valid configuration: Service type A, implementation class B (a subtype of A), static method declared in C (unrelated to A) with return type B (or A or anything between A and B?). If yyy defines the static factory method then it does not need to be a sub-type of xxx, the return type from the public provider() method just needs to be xxx or a sub-type of. So the example is okay, no need for C to extend/implement A. I should note that the implementation isn't aligned with this yet but there are updates to both javac and SL coming that will align it with the current proposal. -Alan ...so yyy can be any class or interface. It's provider() method can even instantiate and return an instance of some class that is not part of the module that provides the service. Hm... Regards, Peter
hg: jigsaw/jake/hotspot: 8162998: Check at module definition that a package named java is not being defined to a class loader other than the boot or platform loader
Changeset: de2b914558cd Author:lfoltan Date: 2016-09-15 11:25 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/de2b914558cd 8162998: Check at module definition that a package named java is not being defined to a class loader other than the boot or platform loader Summary: Added new prohibited package check to JVM_DefineModule and JVM_AddModulePackage Reviewed-by: hseigel, mchung ! src/share/vm/classfile/moduleEntry.hpp ! src/share/vm/classfile/modules.cpp ! src/share/vm/oops/instanceKlass.cpp ! test/runtime/modules/JVMAddModulePackage.java ! test/runtime/modules/JVMDefineModule.java
hg: jigsaw/jake/jdk: 8162998: Check at module definition that a package named java is not being defined to a class loader other than the boot or platform loader
Changeset: b25ebe289b7c Author:lfoltan Date: 2016-09-15 11:27 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b25ebe289b7c 8162998: Check at module definition that a package named java is not being defined to a class loader other than the boot or platform loader Summary: Fix test to adhere to this prohibited package check Reviewed-by: hseigel, mchung ! test/java/lang/reflect/Module/WithSecurityManager.java
JDK 9 Early Access with Project Jigsaw, build 135 on 09-14-2016 (#5500)
The EA download [1] has been refreshed with new builds that are mostly aligned with the current proposals for JPMS issues [2]. Not everything is there yet of course (and some areas need a few more iterations) but there is enough to test and try things out. For #ReflectiveAccessToNonExportedTypes and #AwkwardStrongEncapsulation then the initial support for `weak module` and `exports private` is in place. These are probably the highest priority changes to try out. The changes to setAccessible in #AwkwardStrongEncapsulation is going to be disruptive and will no doubt expose hacks in many areas. We've run into several of these already. The command line option to allow existing code to break into non-public types/members is --add-exports-private. The format of the value passed to this option is the same--add-exports. With #AddExportsInManifest then there are equivalents in the application JAR main manifest to try out too. As part of the #ClassLoaderNames then the format of the stack trace elements has changed. For #ServiceLoaderEnhancements then the implementation is mostly aligned, except for the static factory method which needs an update to javac and SL to align with the proposal (should be there soon, just not in this build). Several people have brought up #ResourceEncapsulation and #ClassFilesAsResources here so it would be good to try this out. As always, the most valuable feedback is from those trying out the builds so please let us know what you have tried and what works or doesn't work. -Alan [1] https://jdk9.java.net/jigsaw/ [2] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-September/009365.html
Re: RFR 8160063: Provide a means to disable a plugin via the command line
-—disable-plugin can allow any plugin if present, regardless whether it’s auto-enabled or not. If the plugin is disabled, -—disable-plugin will just be nop. Looking at Plugin.State::DISABLED: DISABLED: The plugin is not exposed in help and will be not called. It’s unclear this is needed. I guess this was defined to allow a plugin to handle the disable option like --generate-jli-classes=none. I don’t see when a plugin is added to jlink with DISABLED state. We should revisit Plugin.State enum. Mandy > On Sep 15, 2016, at 9:36 AM, Sundararajan Athijegannathan > wrote: > > With "--disable ", user can pass any plugin name - even the > plugins that are *not* auto-enabled. We may have to check and report. > But, --disable- options are added only for auto-enabled > plugins. > > --disable- will automatically fail as > "unsupported option". > > -Sundar > > > On 9/15/2016 9:57 PM, Paul Sandoz wrote: >>> On 15 Sep 2016, at 09:06, Mandy Chung wrote: >>> >>> On Sep 15, 2016, at 8:26 AM, Alan Bateman wrote: On 15/09/2016 07:31, Sundararajan Athijegannathan wrote: > Please review http://cr.openjdk.java.net/~sundar/8160063/webrev.01/ for > https://bugs.openjdk.java.net/browse/JDK-8160063 > > * Adding --disable- option for any plugin that is > auto-enabled. > Should this be --disable-plugin rather than synthesizing an option? >>> jlink --disable-plugin generate-jli-classes does read better. The option >>> is more obvious. >>> >>> The other way to look at this option is an option provided by each plugin >>> like --generate-jli-classes=none. >>> >>> Given that the plugin name is arbitrary, "--disable-plugin ” >>> would be more obvious and I have no issue to go with that. >>> >> Yes, that is better. I am guessing the "-disable-” approach was >> proposed to be consistent with the plugin configuration options, so perhaps >> that should also be reconsidered? >> >> Paul. >> Also would I be correct to say anarchy such as `jlink --disable-generate-jli-classes --generate-jli-classes` would actually run the plugin? Related is whether it's warning or fatal when an unknown plugin is specified. >>> Good question. --disable-generate-jli-classes removes the plugin from the >>> map and so it won’t run. When an unknown plugin is specified, I suggest it >>> should be fatal and I think that’s the current behavior. >>> >>> If both the option to disable and to enable are specified (in any order), >>> fatal would be helpful such that the user is prompted to ask one thing not >>> the other. >>> >>> Mandy >>> >
Re: RFR 8160063: Provide a means to disable a plugin via the command line
With "--disable ", user can pass any plugin name - even the plugins that are *not* auto-enabled. We may have to check and report. But, --disable- options are added only for auto-enabled plugins. --disable- will automatically fail as "unsupported option". -Sundar On 9/15/2016 9:57 PM, Paul Sandoz wrote: >> On 15 Sep 2016, at 09:06, Mandy Chung wrote: >> >> >>> On Sep 15, 2016, at 8:26 AM, Alan Bateman wrote: >>> >>> On 15/09/2016 07:31, Sundararajan Athijegannathan wrote: >>> Please review http://cr.openjdk.java.net/~sundar/8160063/webrev.01/ for https://bugs.openjdk.java.net/browse/JDK-8160063 * Adding --disable- option for any plugin that is auto-enabled. >>> Should this be --disable-plugin rather than synthesizing an >>> option? >>> >> jlink --disable-plugin generate-jli-classes does read better. The option is >> more obvious. >> >> The other way to look at this option is an option provided by each plugin >> like --generate-jli-classes=none. >> >> Given that the plugin name is arbitrary, "--disable-plugin ” >> would be more obvious and I have no issue to go with that. >> > Yes, that is better. I am guessing the "-disable-” approach was > proposed to be consistent with the plugin configuration options, so perhaps > that should also be reconsidered? > > Paul. > >>> Also would I be correct to say anarchy such as `jlink >>> --disable-generate-jli-classes --generate-jli-classes` would actually run >>> the plugin? Related is whether it's warning or fatal when an unknown plugin >>> is specified. >> Good question. --disable-generate-jli-classes removes the plugin from the >> map and so it won’t run. When an unknown plugin is specified, I suggest it >> should be fatal and I think that’s the current behavior. >> >> If both the option to disable and to enable are specified (in any order), >> fatal would be helpful such that the user is prompted to ask one thing not >> the other. >> >> Mandy >>
Re: RFR 8160063: Provide a means to disable a plugin via the command line
> On 15 Sep 2016, at 09:06, Mandy Chung wrote: > > >> On Sep 15, 2016, at 8:26 AM, Alan Bateman wrote: >> >> On 15/09/2016 07:31, Sundararajan Athijegannathan wrote: >> >>> Please review http://cr.openjdk.java.net/~sundar/8160063/webrev.01/ for >>> https://bugs.openjdk.java.net/browse/JDK-8160063 >>> >>> * Adding --disable- option for any plugin that is auto-enabled. >>> >> Should this be --disable-plugin rather than synthesizing an >> option? >> > > jlink --disable-plugin generate-jli-classes does read better. The option is > more obvious. > > The other way to look at this option is an option provided by each plugin > like --generate-jli-classes=none. > > Given that the plugin name is arbitrary, "--disable-plugin ” > would be more obvious and I have no issue to go with that. > Yes, that is better. I am guessing the "-disable-” approach was proposed to be consistent with the plugin configuration options, so perhaps that should also be reconsidered? Paul. > >> Also would I be correct to say anarchy such as `jlink >> --disable-generate-jli-classes --generate-jli-classes` would actually run >> the plugin? Related is whether it's warning or fatal when an unknown plugin >> is specified. > > Good question. --disable-generate-jli-classes removes the plugin from the > map and so it won’t run. When an unknown plugin is specified, I suggest it > should be fatal and I think that’s the current behavior. > > If both the option to disable and to enable are specified (in any order), > fatal would be helpful such that the user is prompted to ask one thing not > the other. > > Mandy >
Re: RFR 8160063: Provide a means to disable a plugin via the command line
> On Sep 15, 2016, at 8:26 AM, Alan Bateman wrote: > > On 15/09/2016 07:31, Sundararajan Athijegannathan wrote: > >> Please review http://cr.openjdk.java.net/~sundar/8160063/webrev.01/ for >> https://bugs.openjdk.java.net/browse/JDK-8160063 >> >> * Adding --disable- option for any plugin that is auto-enabled. >> > Should this be --disable-plugin rather than synthesizing an > option? > jlink --disable-plugin generate-jli-classes does read better. The option is more obvious. The other way to look at this option is an option provided by each plugin like --generate-jli-classes=none. Given that the plugin name is arbitrary, "--disable-plugin ” would be more obvious and I have no issue to go with that. > Also would I be correct to say anarchy such as `jlink > --disable-generate-jli-classes --generate-jli-classes` would actually run the > plugin? Related is whether it's warning or fatal when an unknown plugin is > specified. Good question. --disable-generate-jli-classes removes the plugin from the map and so it won’t run. When an unknown plugin is specified, I suggest it should be fatal and I think that’s the current behavior. If both the option to disable and to enable are specified (in any order), fatal would be helpful such that the user is prompted to ask one thing not the other. Mandy
Re: #ServiceLoaderEnhancements
On 15/09/2016 07:54, Peter Levart wrote: One thing that is not clear is whether the yyy in "provides xxx with yyy" directive of module declaration must be a concrete class and a subtype of service type when the service is obtained via a static method. For example, is the following a valid configuration: Service type A, implementation class B (a subtype of A), static method declared in C (unrelated to A) with return type B (or A or anything between A and B?). If yyy defines the static factory method then it does not need to be a sub-type of xxx, the return type from the public provider() method just needs to be xxx or a sub-type of. So the example is okay, no need for C to extend/implement A. I should note that the implementation isn't aligned with this yet but there are updates to both javac and SL coming that will align it with the current proposal. -Alan
Re: RFR 8160063: Provide a means to disable a plugin via the command line
On 15/09/2016 07:31, Sundararajan Athijegannathan wrote: Please review http://cr.openjdk.java.net/~sundar/8160063/webrev.01/ for https://bugs.openjdk.java.net/browse/JDK-8160063 * Adding --disable- option for any plugin that is auto-enabled. Should this be --disable-plugin rather than synthesizing an option? Also would I be correct to say anarchy such as `jlink --disable-generate-jli-classes --generate-jli-classes` would actually run the plugin? Related is whether it's warning or fatal when an unknown plugin is specified. -Alan
Re: RFR 8160063: Provide a means to disable a plugin via the command line
> On Sep 15, 2016, at 7:31 AM, Sundararajan Athijegannathan > wrote: > > Please review http://cr.openjdk.java.net/~sundar/8160063/webrev.01/ for > https://bugs.openjdk.java.net/browse/JDK-8160063 > > * Adding --disable- option for any plugin that is auto-enabled. A consistent mechanism to disable a plugin is good. The Section class is not used anywhere. Should the entire class be removed? Or move it to JmodArchive to replace the final String constants. Can you include "--disable-” and its help message in jlink —-list-plugins help output? It can be placed toward the bottom before: For options requiring a , the value will be a comma separated list of elements each using one the following forms: glob: regex: @ where filename is the name of a file containing patterns to be used, one pattern per line Can you also fix the two long lines above as missing \n in main.extended.help.footer Otherwise, looks fine. Mandy
Re: #ServiceLoaderEnhancements
Hi, Reading number (2) of the proposal... the static provider() method (declared by "provider class") and returning a "provider object" sounds confusing when coupled with number (3) which proposes a ServiceLoader.Provider interface. Should Provider interface be renamed to ProviderFactory? Or should rather ServiceLoader documentation be revised to stop talking about service providers and talk about service types(s) and service implementation(s) or service implmenetation classes instead? It's OK for a module to "provide" a service of some "service type" with some "service implementation class", but it is strange to call the implementation class a provider class and an instance of it a provider object. I think there's one level of indirection that is too much in the speak currently. If you agree with above, then I propose the static method to simply be called "getInstance()" and (to make it parallel with constructor) don't require it to be a public method in a public class if the service is provided by a module. One thing that is not clear is whether the yyy in "provides xxx with yyy" directive of module declaration must be a concrete class and a subtype of service type when the service is obtained via a static method. For example, is the following a valid configuration: Service type A, implementation class B (a subtype of A), static method declared in C (unrelated to A) with return type B (or A or anything between A and B?). I think the constraints could be more easily understood if the method was called getInstance() and required to have the same return type as the declaring class. The service implementation class could then be anything (perhaps a subtype of the methods's return type/declaring class). The interface in (3) can then be called ServiceLoader.Provider. What do you think?
Re: RFR 8160063: Provide a means to disable a plugin via the command line
+1 > On Sep 15, 2016, at 11:31 AM, Sundararajan Athijegannathan > wrote: > > Please review http://cr.openjdk.java.net/~sundar/8160063/webrev.01/ for > https://bugs.openjdk.java.net/browse/JDK-8160063 > > * Adding --disable- option for any plugin that is auto-enabled. > * Removed ad-hoc "none" option of generate-jli-classes plugin. > * Simple test to make sure --disable-generate-jli-classes option is accepted. > * Manual verified that when generate-jli-classes plugin is deactivated, JLI > classes are not generated. > > Thanks, > -Sundar >
Re: RFR 8160063: Provide a means to disable a plugin via the command line
+1 I agree it's good with a standard way to disable plugins like this on a high level. This also solves an issue I was just about to file a bug for where the GenerateJLIClassesPlugin generates a few basic forms even when "disabled" with =none /Claes On 2016-09-15 16:31, Sundararajan Athijegannathan wrote: Please review http://cr.openjdk.java.net/~sundar/8160063/webrev.01/ for https://bugs.openjdk.java.net/browse/JDK-8160063 * Adding --disable- option for any plugin that is auto-enabled. * Removed ad-hoc "none" option of generate-jli-classes plugin. * Simple test to make sure --disable-generate-jli-classes option is accepted. * Manual verified that when generate-jli-classes plugin is deactivated, JLI classes are not generated. Thanks, -Sundar
Re: RFR 8160063: Provide a means to disable a plugin via the command line
Also piggybacking clean-up in unusued code in JLinkTask.java (Section enum) -Sundar On 15/09/16, 8:01 PM, Sundararajan Athijegannathan wrote: Please review http://cr.openjdk.java.net/~sundar/8160063/webrev.01/ for https://bugs.openjdk.java.net/browse/JDK-8160063 * Adding --disable- option for any plugin that is auto-enabled. * Removed ad-hoc "none" option of generate-jli-classes plugin. * Simple test to make sure --disable-generate-jli-classes option is accepted. * Manual verified that when generate-jli-classes plugin is deactivated, JLI classes are not generated. Thanks, -Sundar
RFR 8160063: Provide a means to disable a plugin via the command line
Please review http://cr.openjdk.java.net/~sundar/8160063/webrev.01/ for https://bugs.openjdk.java.net/browse/JDK-8160063 * Adding --disable- option for any plugin that is auto-enabled. * Removed ad-hoc "none" option of generate-jli-classes plugin. * Simple test to make sure --disable-generate-jli-classes option is accepted. * Manual verified that when generate-jli-classes plugin is deactivated, JLI classes are not generated. Thanks, -Sundar