From mandy.chung at oracle.com Tue Mar 1 00:43:26 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 01 Mar 2016 00:43:26 +0000 Subject: hg: jigsaw/jake/jdk: 8150664: Split "provides" lines in module-info.java get ignored Message-ID: <201603010043.u210hQjG005748@aojmv0008.oracle.com> Changeset: d8e638c47144 Author: mchung Date: 2016-02-29 16:40 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d8e638c47144 8150664: Split "provides" lines in module-info.java get ignored ! make/src/classes/build/tools/jigsaw/GenGraphs.java ! make/src/classes/build/tools/module/GenModuleInfoSource.java ! make/src/classes/build/tools/module/ModuleInfoReader.java ! src/java.management/share/classes/module-info.java From mandy.chung at oracle.com Tue Mar 1 04:47:54 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 01 Mar 2016 04:47:54 +0000 Subject: hg: jigsaw/jake/jdk: Missing -ljvm in libinstrument dependency Message-ID: <201603010447.u214lsSj029308@aojmv0008.oracle.com> Changeset: 424361a2e9dd Author: mchung Date: 2016-02-29 20:47 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/424361a2e9dd Missing -ljvm in libinstrument dependency ! make/lib/Lib-java.instrument.gmk From mandy.chung at oracle.com Tue Mar 1 04:59:37 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 01 Mar 2016 04:59:37 +0000 Subject: hg: jigsaw/jake/langtools: Update jdeps to generate dotfile for -s -m option Message-ID: <201603010459.u214xbN3002901@aojmv0008.oracle.com> Changeset: f12657c2358d Author: mchung Date: 2016-02-29 20:58 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/f12657c2358d Update jdeps to generate dotfile for -s -m option ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsTask.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleAnalyzer.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModulePaths.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps.properties From felix.yang at oracle.com Tue Mar 1 05:47:14 2016 From: felix.yang at oracle.com (Felix Yang) Date: Tue, 1 Mar 2016 13:47:14 +0800 Subject: RFR 8141609: Need test for jrtfs that runs on JDK 8 to target a JDK 9 image In-Reply-To: <56CED599.6060307@oracle.com> References: <56CBD497.9090609@oracle.com> <56CC6F5A.5090901@oracle.com> <56CC80A6.9020401@oracle.com> <56CEB135.2070005@oracle.com> <56CED599.6060307@oracle.com> Message-ID: <56D52CE2.9060107@oracle.com> Hi Alan, please review the new webrev: http://cr.openjdk.java.net/~xiaofeya/8141609/webrev.02/ Major changes: 1. remove checking for 'java.version' in JrtfsTestMain and add new check for 'release' file 2. In order to avoid dup tests with Basic.java, add new BaseTest.java, which is a plain java app rather than testng tests. As stated before, only moved those tests more related with 'functionality', not contents. Thanks, Felix On 2016/2/25 18:21, Felix Yang wrote: > > > On 2016/2/25 15:45, Alan Bateman wrote: >> >> On 24/02/2016 04:01, Felix Yang wrote: >>> Jon and Alan, >>> thanks a lot for this comment. Fixed it in new webrev: >>> http://cr.openjdk.java.net/~xiaofeya/8141609/webrev.01/ >>> >> I think JrtfsJarTest will also need to check the `release` file in >> $JDK8_HOME to check that it's a JDK 8 release. Its a properties file >> so should be easy. I bring this up because I'm not sure that we can >> guarantee that JT_JAVA is a JDK 8 build. > This has been checked at beginning of JrtfsTestMain. It will quit > silently if not launched with a JDK 8. But, it looks checking > 'release' file is a more light weight solution. I will adjust it. Hope > its format is identical for all releases. > > -Felix >> >> On JrtfsTestMain then it looks like it's a copy of the jrtfs >> Basic.java test. I wonder if we should strip it down a bit to make it >> easier to maintain. I don't object to pushing the test as in into >> jake but there will be some clean-up required. > If you don't mind, how about abstract a super class for "Basic"? Basic > is a testng test rather than plain java app. > > -Felix >> >> -Alan > From felix.yang at oracle.com Tue Mar 1 06:05:34 2016 From: felix.yang at oracle.com (Felix Yang) Date: Tue, 1 Mar 2016 14:05:34 +0800 Subject: RFR 8078812, Test RMI with client and servers as modules In-Reply-To: References: Message-ID: <56D5312E.9030508@oracle.com> Ping... -Felix On 2016/2/24 14:06, Felix Yang wrote: > Hi all, > please review the new tests to use RMI in module world. > > Webrev: > http://cr.openjdk.java.net/~xiaofeya/8078812/webrev.00/ > Bug: > https://bugs.openjdk.java.net/browse/JDK-8078812 > > Thanks, > Felix From Alan.Bateman at oracle.com Tue Mar 1 08:07:52 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 1 Mar 2016 08:07:52 +0000 Subject: RFR 8141609: Need test for jrtfs that runs on JDK 8 to target a JDK 9 image In-Reply-To: <56D52CE2.9060107@oracle.com> References: <56CBD497.9090609@oracle.com> <56CC6F5A.5090901@oracle.com> <56CC80A6.9020401@oracle.com> <56CEB135.2070005@oracle.com> <56CED599.6060307@oracle.com> <56D52CE2.9060107@oracle.com> Message-ID: <56D54DD8.5060503@oracle.com> On 01/03/2016 05:47, Felix Yang wrote: > Hi Alan, > please review the new webrev: > http://cr.openjdk.java.net/~xiaofeya/8141609/webrev.02/ > > Major changes: > 1. remove checking for 'java.version' in JrtfsTestMain and add new > check for 'release' file > 2. In order to avoid dup tests with Basic.java, add new BaseTest.java, > which is a plain java app rather than testng tests. As stated before, > only moved those tests more related with 'functionality', not contents. > This refactors the main unit test for jrtfs and means it can't use newer APIs or language features. I'm interested in Sundar's view on this but I think I would prefer to need to keep the test separate so that it can compile to -target 8. Also I assume it just needs to do a few sanity checks, like walk the file system. Once we have something simple in place then we can add tests to it if needed. -Alan From jan.lahoda at oracle.com Tue Mar 1 13:49:40 2016 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Tue, 01 Mar 2016 13:49:40 +0000 Subject: hg: jigsaw/jake/langtools: Addressing some of the comments by anazarov. Message-ID: <201603011349.u21Dne6w028098@aojmv0008.oracle.com> Changeset: dfccd8d116a6 Author: jlahoda Date: 2016-03-01 14:48 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/dfccd8d116a6 Addressing some of the comments by anazarov. ! 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/6627362/T6627362.java ! test/tools/javac/classfiles/attributes/Module/ModuleTest.java ! test/tools/javac/diags/examples/InvalidDefaultInterface/processors/CreateBadClassFile.java ! test/tools/javac/diags/examples/InvalidStaticInterface/processors/CreateBadClassFile.java ! test/tools/javac/modules/AddLimitMods.java ! test/tools/javac/modules/AutomaticModules.java ! test/tools/javac/modules/DuplicateClassTest.java ! test/tools/javac/modules/PackageConflictTest.java ! test/tools/javac/modules/PluginsInModulesTest.java ! test/tools/javac/modules/ProvidesTest.java From lois.foltan at oracle.com Tue Mar 1 14:48:34 2016 From: lois.foltan at oracle.com (lois.foltan at oracle.com) Date: Tue, 01 Mar 2016 14:48:34 +0000 Subject: hg: jigsaw/jake/hotspot: 8150674: [TESTBUG] SharedArchiveFile/SharedStrings.java fails: "WhiteBox.class : no such file or directory" Message-ID: <201603011448.u21EmYxr018978@aojmv0008.oracle.com> Changeset: 295296819a56 Author: mseledtsov Date: 2016-02-29 11:09 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/295296819a56 8150674: [TESTBUG] SharedArchiveFile/SharedStrings.java fails: "WhiteBox.class : no such file or directory" Summary: placing classes to be added to jar into JT-Reg scratch directory Reviewed-by: jiangli, ccheung ! test/runtime/SharedArchiveFile/BasicJarBuilder.java ! test/runtime/SharedArchiveFile/BootAppendTests.java ! test/runtime/SharedArchiveFile/SharedStrings.java From jan.lahoda at oracle.com Tue Mar 1 17:31:26 2016 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Tue, 01 Mar 2016 17:31:26 +0000 Subject: hg: jigsaw/jake/langtools: 8148608: Intermittent java.nio.file.ProviderNotFoundException when building Jake Message-ID: <201603011731.u21HVQTI017491@aojmv0008.oracle.com> Changeset: a8d05939727f Author: jlahoda Date: 2016-03-01 17:58 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/a8d05939727f 8148608: Intermittent java.nio.file.ProviderNotFoundException when building Jake Summary: Using Files.isRegularFile instead of !Files.isDirectory-Files.exists to check if a path is a file, to avoid trouble when a directory is created inbetween the isDirectory and exists calls. ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java From mark.reinhold at oracle.com Tue Mar 1 17:43:05 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 1 Mar 2016 09:43:05 -0800 (PST) Subject: Java Platform Module System: Issue Summary Message-ID: <20160301174305.170B49C6B1@eggemoggin.niobe.net> I've prepared a list of open issues in the proposed design, gathered from this list and the JSR 376 e-mail lists (EG, comments, and observers) [1]. Comments and discussion are welcome here on jigsaw-dev, but the best way to make sure that the EG sees any specific comment or suggestion is to send it to the EG's "suggestion box" list, jpms-spec-comments [2]. The issue list is meant to be a living document, updated regularly as work progresses. Each issue is assigned a unique hash tag for use in the e-mail messages and other textual media in which the issues will be discussed so that such discussions can be discovered, tracked, and summarized. To that end, if you wish to open a thread on an issue then please make sure to include its hash tag in the subject line of your message. - Mark [1] http://openjdk.java.net/projects/jigsaw/spec/issues/ [2] http://mail.openjdk.java.net/mailman/listinfo/jpms-spec-comments From mandy.chung at oracle.com Tue Mar 1 22:01:40 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 01 Mar 2016 22:01:40 +0000 Subject: hg: jigsaw/jake: 5 new changesets Message-ID: <201603012201.u21M1eLg025439@aojmv0008.oracle.com> Changeset: 0a08d245efbc Author: erikj Date: 2016-02-17 17:03 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/0a08d245efbc 8149963: build errors during API docs build Reviewed-by: ihse, tbell ! make/Javadoc.gmk Changeset: 9f9fe6bb2568 Author: mchung Date: 2016-02-17 17:45 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/9f9fe6bb2568 8074069: Move com.oracle.net and com.oracle.nio APIs to jdk.net module Reviewed-by: alanb ! modules.xml Changeset: 4d65eba233a8 Author: lana Date: 2016-02-18 13:40 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/4d65eba233a8 Merge Changeset: dbd93bfcf008 Author: lana Date: 2016-02-25 09:41 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/dbd93bfcf008 Added tag jdk-9+107 for changeset 4d65eba233a8 ! .hgtags Changeset: 568c22a88db6 Author: henryjen Date: 2016-03-01 13:08 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/568c22a88db6 Merge ! make/Javadoc.gmk From mandy.chung at oracle.com Tue Mar 1 22:01:44 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 01 Mar 2016 22:01:44 +0000 Subject: hg: jigsaw/jake/corba: 4 new changesets Message-ID: <201603012201.u21M1iEd025539@aojmv0008.oracle.com> Changeset: a98f572e2ceb Author: msheppar Date: 2016-02-16 12:37 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/a98f572e2ceb 8144144: ORB destroy() leaks filedescriptors after unsuccessful connection Reviewed-by: chegar, coffeys ! src/java.corba/share/classes/com/sun/corba/se/impl/transport/CorbaInboundConnectionCacheImpl.java ! src/java.corba/share/classes/com/sun/corba/se/impl/transport/CorbaTransportManagerImpl.java ! src/java.corba/share/classes/com/sun/corba/se/impl/transport/SelectorImpl.java ! src/java.corba/share/classes/com/sun/corba/se/impl/transport/SocketOrChannelAcceptorImpl.java ! src/java.corba/share/classes/com/sun/corba/se/impl/transport/SocketOrChannelConnectionImpl.java ! src/java.corba/share/classes/com/sun/corba/se/pept/transport/InboundConnectionCache.java Changeset: 49202432b694 Author: lana Date: 2016-02-18 13:42 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/49202432b694 Merge Changeset: 84f2862a25eb Author: lana Date: 2016-02-25 09:41 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/84f2862a25eb Added tag jdk-9+107 for changeset 49202432b694 ! .hgtags Changeset: b0b6ca30a395 Author: henryjen Date: 2016-03-01 13:08 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/b0b6ca30a395 Merge From mandy.chung at oracle.com Tue Mar 1 22:02:00 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 01 Mar 2016 22:02:00 +0000 Subject: hg: jigsaw/jake/hotspot: 137 new changesets Message-ID: <201603012202.u21M22t5025761@aojmv0008.oracle.com> Changeset: a006fd32b6fd Author: thartmann Date: 2016-02-05 12:43 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a006fd32b6fd 8149109: [TESTBUG] TestRegisterRestoring.java fails with "VM option 'SafepointALot' is develop" Summary: Added missing -XX:+IgnoreUnrecognizedVMOptions. Reviewed-by: vlivanov ! test/compiler/runtime/safepoints/TestRegisterRestoring.java Changeset: f918c20107d9 Author: thartmann Date: 2016-02-04 12:33 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f918c20107d9 8143897: Weblogic12medrec assert(handler_address == SharedRuntime::compute_compiled_exc_handler(nm, pc, exception, force_unwind, true)) failed: Must be the same Summary: ExceptionCache read is lock-free and assume strong memory ordering in write code. Added storestore memory barrier in write path to handle this. Reviewed-by: kvn, thartmann, dlong Contributed-by: Jamsheed Mohammed ! src/share/vm/code/nmethod.cpp Changeset: 9fdc8f5bd110 Author: rschatz Date: 2016-02-03 12:16 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9fdc8f5bd110 8146608: [JVMCI] DebugInfo Tests on DeoptimizeALot runs fails in assert(_pc == *pc_addr || pc == *pc_addr) frame::patch_pc() /frame_x86.cpp:285 Reviewed-by: twisti ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotCompiledCode.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotCompiledNmethod.java ! src/share/vm/jvmci/jvmciCodeInstaller.cpp ! src/share/vm/jvmci/jvmciCodeInstaller.hpp ! src/share/vm/jvmci/jvmciJavaClasses.hpp ! test/compiler/jvmci/code/TestAssembler.java ! test/compiler/jvmci/code/amd64/AMD64TestAssembler.java ! test/compiler/jvmci/code/sparc/SPARCTestAssembler.java ! test/compiler/jvmci/errors/CodeInstallerTest.java ! test/compiler/jvmci/errors/TestInvalidCompilationResult.java ! test/compiler/jvmci/errors/TestInvalidDebugInfo.java ! test/compiler/jvmci/errors/TestInvalidOopMap.java ! test/compiler/jvmci/events/JvmciNotifyInstallEventTest.java Changeset: 94e5372b45b7 Author: dnsimon Date: 2016-02-03 12:16 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/94e5372b45b7 8148981: remove ResolvedJavaType.getClassFilePath() Reviewed-by: twisti ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedObjectTypeImpl.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedPrimitiveType.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/ResolvedJavaType.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java Changeset: 9a75a19921a7 Author: neliasso Date: 2016-01-22 15:25 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9a75a19921a7 8063112: Compiler diagnostic commands should have locking instead of safepoint Summary: Remove unnecessary vm-ops and add locking instead, improve output Reviewed-by: kvn ! src/share/vm/code/codeCache.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vm_operations.cpp ! src/share/vm/runtime/vm_operations.hpp ! src/share/vm/services/diagnosticCommand.cpp Changeset: e8f933e6ff33 Author: thartmann Date: 2016-02-05 15:38 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e8f933e6ff33 Merge Changeset: f012e415c2c3 Author: rschatz Date: 2016-02-05 11:33 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f012e415c2c3 8149105: typo in jvmciCodeInstaller.cpp Reviewed-by: twisti ! src/share/vm/jvmci/jvmciCodeInstaller.cpp Changeset: 52c440e4596f Author: twisti Date: 2016-02-05 18:24 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/52c440e4596f Merge Changeset: b2819023eecf Author: zmajo Date: 2016-02-08 08:57 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b2819023eecf 8148758: Compilation fails with "this call site should not be polymorphic" Summary: Change test to run in interpreter-only mode. Reviewed-by: kvn ! test/testlibrary_tests/whitebox/vm_flags/IntxTest.java Changeset: 0b9079d2ccdb Author: neliasso Date: 2016-02-08 14:05 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0b9079d2ccdb 8148696: Race loading hsdis may cause SIGSEGV Summary: Guard library loading with a lock Reviewed-by: vlivanov ! src/share/vm/compiler/disassembler.hpp Changeset: dab018e73d4b Author: tpivovarova Date: 2016-02-05 21:16 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/dab018e73d4b 8149135: [jittester] Makefile copies JitTesterDriver in incorrect directory and always uses default value for number-of-tests and seed Reviewed-by: iignatyev ! test/testlibrary/jittester/Makefile Changeset: 23e81ab5a8d2 Author: tpivovarova Date: 2016-02-08 16:44 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/23e81ab5a8d2 Merge Changeset: 9804aba8dc16 Author: ppunegov Date: 2016-02-05 18:05 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9804aba8dc16 8148864: Quarantine CompilerControl tests Summary: exclude tests affected by JDK-8148563 and JDK-8140354 from execution Reviewed-by: kvn ! test/compiler/compilercontrol/commandfile/PrintTest.java ! test/compiler/compilercontrol/commands/PrintTest.java ! test/compiler/compilercontrol/directives/PrintTest.java ! test/compiler/compilercontrol/jcmd/PrintDirectivesTest.java ! test/compiler/compilercontrol/jcmd/StressAddMultiThreadedTest.java ! test/compiler/compilercontrol/mixed/RandomValidCommandsTest.java Changeset: 14ff406f87e3 Author: ppunegov Date: 2016-02-08 18:52 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/14ff406f87e3 Merge Changeset: 41c72c1fe11f Author: never Date: 2016-02-05 12:27 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/41c72c1fe11f 8149076: [JVMCI] missing ResourceMark in JVMCIRuntime::initialize_HotSpotJVMCIRuntime Reviewed-by: twisti, iignatyev ! src/share/vm/jvmci/jvmciRuntime.cpp ! test/compiler/jvmci/JVM_GetJVMCIRuntimeTest.java Changeset: 219b7048c2b6 Author: never Date: 2016-02-08 12:13 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/219b7048c2b6 Merge Changeset: cb4f9170ea47 Author: dnsimon Date: 2016-02-08 18:52 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/cb4f9170ea47 8149019: remove redundant modifiers Reviewed-by: twisti ! .mx.jvmci/suite.py ! src/jdk.vm.ci/share/classes/jdk.vm.ci.aarch64/src/jdk/vm/ci/aarch64/AArch64.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.aarch64/src/jdk/vm/ci/aarch64/AArch64Kind.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.amd64/src/jdk/vm/ci/amd64/AMD64.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.amd64/src/jdk/vm/ci/amd64/AMD64Kind.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/SourceStackTrace.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotCallingConventionType.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotConstantPool.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJVMCIRuntime.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMemoryAccessProviderImpl.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMethodData.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMethodDataAccessor.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMethodUnresolved.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedJavaFieldImpl.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedObjectTypeImpl.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/DeoptimizationAction.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/JavaKind.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/LIRKind.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/MethodHandleAccessProvider.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/PlatformKind.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.sparc/src/jdk/vm/ci/sparc/SPARCKind.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/NameAndSignature.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java Changeset: 56e0e1930e35 Author: roland Date: 2016-01-29 17:18 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/56e0e1930e35 8137049: Code quality: reducing an trivial integer loop does not produce an optimal code Summary: canonicalized if shape not recognized by empty loop detection code Reviewed-by: kvn, shade ! src/share/vm/opto/loopTransform.cpp Changeset: 2c6e7fe05058 Author: enevill Date: 2016-02-03 11:34 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2c6e7fe05058 8148948: aarch64: generate_copy_longs calls align() incorrectly Summary: Fix alignments Reviewed-by: aph ! src/cpu/aarch64/vm/globals_aarch64.hpp ! src/cpu/aarch64/vm/stubGenerator_aarch64.cpp Changeset: f776a0470c2c Author: enevill Date: 2016-02-04 16:24 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f776a0470c2c 8148783: aarch64: SEGV running SpecJBB2013 Summary: Fix calculation of offset for adrp Reviewed-by: aph ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp Changeset: 7737d637e74c Author: enevill Date: 2016-02-08 14:14 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7737d637e74c 8149365: aarch64: memory copy does not prefetch on backwards copy Summary: Implement prefetch on backwards copies Reviewed-by: aph ! src/cpu/aarch64/vm/stubGenerator_aarch64.cpp ! src/cpu/aarch64/vm/vm_version_aarch64.cpp Changeset: f0b94ac4a1c9 Author: hshi Date: 2016-02-06 04:09 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f0b94ac4a1c9 8149100: AArch64: "bad AD file" for LL enconding AryEq Node matching Summary: add byte array equal support for aarch64 Reviewed-by: aph ! src/cpu/aarch64/vm/aarch64.ad ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/aarch64/vm/macroAssembler_aarch64.hpp Changeset: a482af88c594 Author: hshi Date: 2016-02-05 03:55 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a482af88c594 8149080: AArch64: Recognise disjoint array copy in stub code Summary: Detect array copy can use fwd copy by checking (dest-src) above_same (copy_size) Reviewed-by: aph ! src/cpu/aarch64/vm/stubGenerator_aarch64.cpp Changeset: 22d59366f1a1 Author: rschatz Date: 2016-02-08 18:52 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/22d59366f1a1 8148741: compiler/jvmci/code/SimpleDebugInfoTest.java fails in 'frame::sender_for_compiled_frame' Reviewed-by: twisti ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotForeignCallTarget.java ! test/compiler/jvmci/code/CodeInstallationTest.java ! test/compiler/jvmci/code/TestAssembler.java ! test/compiler/jvmci/code/amd64/AMD64TestAssembler.java ! test/compiler/jvmci/code/sparc/SPARCTestAssembler.java Changeset: d4c78501bb92 Author: dnsimon Date: 2016-02-08 18:52 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d4c78501bb92 8148507: [JVMCI] mitigate deadlocks related to JVMCI compiler under -Xbatch Reviewed-by: twisti, dholmes ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/jvmci/jvmciCompiler.cpp ! src/share/vm/jvmci/jvmciCompiler.hpp Changeset: 4130663a3de8 Author: thartmann Date: 2016-02-10 07:54 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4130663a3de8 8148752: Compiled StringBuilder code throws StringIndexOutOfBoundsException Summary: Fixed handling of long/double MH arguments in GraphBuilder::try_method_handle_inline(). Reviewed-by: roland, shade, vlivanov, kvn, twisti ! src/share/vm/opto/callGenerator.cpp + test/compiler/jsr292/LongReferenceCastingTest.java Changeset: 72afb83f5035 Author: cjplummer Date: 2016-01-20 11:58 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/72afb83f5035 8143608: Don't 64-bit align start of InstanceKlass vtable, itable, and nonstatic_oopmap on 32-bit systems Summary: Removed alignment of these fields. Reviewed-by: coleenp, dholmes, mgerdin ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp Changeset: 03c5b02bfe28 Author: coleenp Date: 2016-01-27 03:28 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/03c5b02bfe28 Merge Changeset: b4758f73f7ac Author: dholmes Date: 2016-01-26 21:18 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b4758f73f7ac 8145740: Visual Studio pragmas should be guarded by ifdef _MSC_VER Reviewed-by: simonis, dholmes Contributed-by: Matthias Baesken ! src/share/vm/utilities/growableArray.hpp Changeset: 3aaed66a498c Author: dholmes Date: 2016-01-27 05:59 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3aaed66a498c Merge Changeset: cf4b692a28d7 Author: david Date: 2016-01-26 15:28 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/cf4b692a28d7 8147814: Move verification code out of g1collectedheap Reviewed-by: jwilhelm, tschatzl ! src/share/vm/gc/g1/concurrentMark.cpp ! src/share/vm/gc/g1/g1CollectedHeap.cpp ! src/share/vm/gc/g1/g1CollectedHeap.hpp ! src/share/vm/gc/g1/g1EvacFailure.cpp + src/share/vm/gc/g1/g1HeapVerifier.cpp + src/share/vm/gc/g1/g1HeapVerifier.hpp Changeset: a910db847a63 Author: mlarsson Date: 2016-01-27 09:07 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a910db847a63 8147348: LogTagLevelExpression not properly initialized in configure_stdout Reviewed-by: brutisso, sla ! src/share/vm/logging/log.cpp ! src/share/vm/logging/logTagLevelExpression.cpp ! src/share/vm/logging/logTagLevelExpression.hpp ! src/share/vm/utilities/internalVMTests.cpp Changeset: 7b580bda0da8 Author: mlarsson Date: 2016-01-27 11:41 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7b580bda0da8 Merge Changeset: 6a6a92e96463 Author: akulyakh Date: 2016-01-19 19:19 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6a6a92e96463 8147609: [TESTBUG] Correct the @build statements in the serviceability/dcmd/gc/HeapDumpAllTest.java and HeapDumpTest.java tests Summary: Corrected the @build statements Reviewed-by: jbachorik ! test/serviceability/dcmd/gc/HeapDumpAllTest.java ! test/serviceability/dcmd/gc/HeapDumpTest.java Changeset: 491bd01554f5 Author: ddmitriev Date: 2016-01-27 14:14 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/491bd01554f5 Merge Changeset: 4f4498d76a86 Author: hseigel Date: 2016-01-27 07:14 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4f4498d76a86 8137314: vm crash from test java/security/Policy/SignedJar/SignedJarTest.java Summary: Add additional checks in the verifier for recursive verification Reviewed-by: acorn, gtriantafill ! src/share/vm/classfile/verifier.cpp Changeset: cc777af9f496 Author: hseigel Date: 2016-01-27 16:13 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/cc777af9f496 Merge Changeset: 45c4d55c36f5 Author: rprotacio Date: 2016-01-21 12:11 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/45c4d55c36f5 8146435: [TESTBUG] Logging tests are failing intermittently on windows when executed by JPRT Summary: Improved robustness of UL tests by removing reliance on "java -version" and replacing with explicit code to trigger logging in all environments Reviewed-by: dholmes, iklam, mockner ! test/runtime/logging/ClassB.java ! test/runtime/logging/ClassInitializationTest.java ! test/runtime/logging/ClassResolutionTest.java ! test/runtime/logging/DefaultMethodsTest.java ! test/runtime/logging/ExceptionsTest.java ! test/runtime/logging/ItablesTest.java + test/runtime/logging/ItablesVtableTest.java ! test/runtime/logging/MonitorInflationTest.java ! test/runtime/logging/SafepointTest.java ! test/runtime/logging/VMOperationTest.java ! test/runtime/logging/VtablesTest.java Changeset: 1ac9a5e38143 Author: rprotacio Date: 2016-01-27 11:12 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1ac9a5e38143 8146137: runtime/logging/ExceptionsTest.java fails on embedded and ARM test Summary: Removed part of ExceptionsTest.java looking for exception that is not printed when function is compiled on embedded/ARM Reviewed-by: coleenp, dholmes ! test/runtime/logging/ExceptionsTest.java Changeset: 7de1631fd060 Author: coleenp Date: 2016-01-27 16:34 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7de1631fd060 Merge Changeset: b66022b4b9cd Author: coleenp Date: 2016-01-27 18:31 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b66022b4b9cd Merge Changeset: f71b5a8a78b6 Author: goetz Date: 2016-01-18 10:25 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f71b5a8a78b6 8146395: Add inline qualifier in oop.hpp and fix inlining in gc files Summary: Fix remaining issues after 8146401. Also fix windows VS2010 linkage problem (g1OopClosures.hpp). Reviewed-by: stefank, mgerdin ! src/share/vm/gc/cms/cmsCollectorPolicy.cpp ! src/share/vm/gc/cms/cmsOopClosures.hpp ! src/share/vm/gc/cms/cmsOopClosures.inline.hpp ! src/share/vm/gc/cms/compactibleFreeListSpace.cpp ! src/share/vm/gc/cms/compactibleFreeListSpace.hpp ! src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc/cms/parNewGeneration.cpp ! src/share/vm/gc/cms/promotionInfo.cpp ! src/share/vm/gc/cms/promotionInfo.hpp ! src/share/vm/gc/g1/concurrentMark.hpp ! src/share/vm/gc/g1/concurrentMark.inline.hpp ! src/share/vm/gc/g1/g1CollectedHeap.cpp ! src/share/vm/gc/g1/g1OopClosures.hpp ! src/share/vm/gc/g1/g1OopClosures.inline.hpp ! src/share/vm/gc/g1/g1RemSet.cpp ! src/share/vm/gc/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/gc/g1/g1SATBCardTableModRefBS.hpp + src/share/vm/gc/g1/g1SATBCardTableModRefBS.inline.hpp ! src/share/vm/gc/parallel/asPSYoungGen.cpp ! src/share/vm/gc/parallel/cardTableExtension.cpp ! src/share/vm/gc/parallel/objectStartArray.cpp ! src/share/vm/gc/parallel/objectStartArray.hpp + src/share/vm/gc/parallel/objectStartArray.inline.hpp ! src/share/vm/gc/parallel/parMarkBitMap.cpp ! src/share/vm/gc/parallel/parallelScavengeHeap.cpp ! src/share/vm/gc/parallel/psOldGen.cpp ! src/share/vm/gc/parallel/psParallelCompact.cpp ! src/share/vm/gc/parallel/psParallelCompact.hpp ! src/share/vm/gc/parallel/psParallelCompact.inline.hpp ! src/share/vm/gc/parallel/psScavenge.cpp ! src/share/vm/gc/parallel/psScavenge.hpp ! src/share/vm/gc/serial/defNewGeneration.cpp ! src/share/vm/gc/shared/ageTable.cpp ! src/share/vm/gc/shared/ageTable.hpp + src/share/vm/gc/shared/ageTable.inline.hpp ! src/share/vm/gc/shared/collectedHeap.inline.hpp ! src/share/vm/gc/shared/genOopClosures.hpp ! src/share/vm/gc/shared/genOopClosures.inline.hpp ! src/share/vm/gc/shared/referenceProcessor.cpp ! src/share/vm/gc/shared/referenceProcessor.hpp + src/share/vm/gc/shared/referenceProcessor.inline.hpp ! src/share/vm/gc/shared/space.hpp ! src/share/vm/gc/shared/space.inline.hpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/oops/markOop.inline.hpp ! src/share/vm/oops/objArrayOop.hpp ! src/share/vm/oops/objArrayOop.inline.hpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp Changeset: 22926024a12a Author: stefank Date: 2016-01-27 20:45 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/22926024a12a Merge Changeset: e3145b400086 Author: sangheki Date: 2016-01-27 10:30 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e3145b400086 8145192: 'count' variable can overflow in PSMarkSweep::invoke on 64 bit JVM Summary: Changed MarkSweepAlwaysCompactCount from uintx to uint Reviewed-by: tschatzl, tbenson ! src/share/vm/gc/parallel/psMarkSweep.cpp ! src/share/vm/gc/shared/collectorPolicy.cpp ! src/share/vm/runtime/globals.hpp Changeset: 42af5867a5d3 Author: sangheki Date: 2016-01-27 21:04 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/42af5867a5d3 Merge Changeset: 3151ffce8652 Author: david Date: 2016-01-27 16:12 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3151ffce8652 8147940: Test gc/g1/TestG1TraceEagerReclaimHumongousObjects.java fails Reviewed-by: mgerdin, jwilhelm ! test/gc/g1/TestG1TraceEagerReclaimHumongousObjects.java Changeset: 710920802b06 Author: david Date: 2016-01-28 02:30 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/710920802b06 Merge Changeset: d1e392bce38a Author: jiangli Date: 2016-01-27 22:39 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d1e392bce38a 8147500: The HashtableTextDump::get_num() should check for integer overflow Summary: Add check for integer overflow in HashtableTextDump::get_num() Reviewed-by: dholmes, iklam ! src/share/vm/classfile/compactHashtable.cpp ! src/share/vm/classfile/compactHashtable.hpp Changeset: 64ba9950558b Author: stuefe Date: 2016-01-27 11:51 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/64ba9950558b 8146905: cleanup ostream, staticBufferStream Summary: get rid of staticBufferStream and implement the use-caller-provided-scratch-buffer feature in a simpler way. Reviewed-by: simonis, dholmes ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/ostream.hpp ! src/share/vm/utilities/vmError.cpp Changeset: cca7e3a5c236 Author: dholmes Date: 2016-01-28 07:11 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/cca7e3a5c236 Merge Changeset: 269ee0058c3d Author: mgerdin Date: 2016-01-27 14:50 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/269ee0058c3d 8147461: Use byte offsets for vtable start and vtable length offsets Reviewed-by: cjplummer, coleenp, dnsimon ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/aarch64/vm/vtableStubs_aarch64.cpp ! src/cpu/ppc/vm/macroAssembler_ppc.cpp ! src/cpu/ppc/vm/ppc.ad ! src/cpu/ppc/vm/templateTable_ppc_64.cpp ! src/cpu/ppc/vm/vtableStubs_ppc_64.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/vtableStubs_x86_32.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedJavaMethodImpl.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/jvmci/jvmciCompilerToVM.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klassVtable.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/shark/sharkTopLevelBlock.cpp Changeset: 3222fbebdd06 Author: brutisso Date: 2016-01-28 10:04 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3222fbebdd06 8145180: Add back PrintGC, PrintGCDetails and -Xloggc Reviewed-by: sjohanss, david ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/globals.hpp + test/gc/logging/TestDeprecatedPrintFlags.java Changeset: 9c3642cc96c2 Author: brutisso Date: 2016-01-28 10:18 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9c3642cc96c2 Merge Changeset: 33399d3a06f4 Author: akulyakh Date: 2016-01-28 14:58 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/33399d3a06f4 8147447: serviceability/tmtools/jstack/WaitNotifyThreadTest.java test fails Summary: corrected verification of the jstack object references Reviewed-by: sla ! test/serviceability/tmtools/jstack/WaitNotifyThreadTest.java ! test/serviceability/tmtools/jstack/utils/DefaultFormat.java Changeset: dd70920e6ee9 Author: tschatzl Date: 2016-01-28 14:00 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/dd70920e6ee9 8147087: Race when reusing PerRegionTable bitmaps may result in dropped remembered set entries Summary: Do not make reused PRTs available to other threads before the bitmap of the PRT has been cleared. Reviewed-by: tbenson, mgerdin Contributed-by: Poonam Bajaj , Thomas Schatzl ! src/share/vm/gc/g1/heapRegionRemSet.cpp Changeset: 42e1ea096597 Author: tschatzl Date: 2016-01-28 15:03 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/42e1ea096597 Merge Changeset: 6d650a9f831d Author: tschatzl Date: 2016-01-28 13:30 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6d650a9f831d 8146987: Improve Parallel GC Full GC by caching results of live_words_in_range() Summary: A large part of time in the parallel scavenge collector is spent finding out the amount of live words within memory ranges to find out where to move an object to. Try to incrementally calculate this value. Reviewed-by: tschatzl, mgerdin, jmasa Contributed-by: ray alex ! src/share/vm/gc/parallel/parMarkBitMap.cpp ! src/share/vm/gc/parallel/parMarkBitMap.hpp ! src/share/vm/gc/parallel/psCompactionManager.cpp ! src/share/vm/gc/parallel/psCompactionManager.hpp ! src/share/vm/gc/parallel/psCompactionManager.inline.hpp ! src/share/vm/gc/parallel/psParallelCompact.cpp ! src/share/vm/gc/parallel/psParallelCompact.hpp ! src/share/vm/gc/parallel/psParallelCompact.inline.hpp ! src/share/vm/oops/instanceClassLoaderKlass.hpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceMirrorKlass.hpp ! src/share/vm/oops/instanceRefKlass.hpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/objArrayKlass.hpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/oops/typeArrayKlass.hpp Changeset: 8edce4224ea4 Author: tschatzl Date: 2016-01-28 16:34 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/8edce4224ea4 Merge Changeset: 2de6311c5afc Author: drwhite Date: 2016-01-22 06:13 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2de6311c5afc 8141421: Various test fail with OOME on win x86 Summary: Fix memory overuse in g1CodeCacheRemset Reviewed-by: tschatzl, mgerdin ! src/share/vm/gc/g1/g1CodeCacheRemSet.cpp ! src/share/vm/gc/g1/heapRegionRemSet.cpp Changeset: 83bbe98197fd Author: jwilhelm Date: 2016-01-28 19:30 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/83bbe98197fd Merge ! src/share/vm/gc/g1/heapRegionRemSet.cpp Changeset: 1969378fe111 Author: goetz Date: 2016-01-28 15:13 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1969378fe111 8148470: Metadata print routines should not print to tty Reviewed-by: iklam, mgerdin ! src/share/vm/oops/metadata.hpp Changeset: 74b36c37b80e Author: aharlap Date: 2016-01-28 16:05 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/74b36c37b80e 8147906: G1 use of os::processor_count() Summary: Use os::active_processor_count() instead of os::processor_count() in G1 Reviewed-by: dholmes, jmasa ! src/share/vm/gc/g1/concurrentMark.cpp ! src/share/vm/gc/g1/dirtyCardQueue.cpp Changeset: 14bc3211b17e Author: dholmes Date: 2016-01-29 03:19 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/14bc3211b17e Merge Changeset: c5480d4abfe4 Author: dholmes Date: 2016-01-29 05:32 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c5480d4abfe4 6515172: Runtime.availableProcessors() ignores Linux taskset command Summary: extract processor count from sched_getaffinity mask Reviewed-by: dcubed, stuefe, gthornbr ! src/os/linux/vm/globals_linux.hpp ! src/os/linux/vm/os_linux.cpp ! src/share/vm/logging/logTag.hpp + test/runtime/os/AvailableProcessors.java Changeset: edde9367aaee Author: mchernov Date: 2016-01-27 18:22 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/edde9367aaee 8141278: New tests for PLAB testing Reviewed-by: tschatzl + test/gc/g1/plab/TestPLABPromotion.java + test/gc/g1/plab/TestPLABResize.java + test/gc/g1/plab/lib/AppPLABPromotion.java + test/gc/g1/plab/lib/AppPLABResize.java + test/gc/g1/plab/lib/LogParser.java + test/gc/g1/plab/lib/MemoryConsumer.java + test/gc/g1/plab/lib/PLABUtils.java Changeset: 67905dccad40 Author: iignatyev Date: 2016-01-29 12:30 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/67905dccad40 Merge Changeset: 1ab7bc23c4cb Author: brutisso Date: 2016-01-29 10:44 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1ab7bc23c4cb 8148467: Consistent use of : in the logging Reviewed-by: mgerdin, tbenson ! src/share/vm/gc/g1/g1CollectorPolicy.cpp ! src/share/vm/gc/g1/g1GCPhaseTimes.cpp Changeset: c90e97ffadde Author: brutisso Date: 2016-01-29 14:41 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c90e97ffadde Merge Changeset: cc02ddce162a Author: dsamersoff Date: 2016-01-29 15:26 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/cc02ddce162a 8148104: HSDB could not terminate when launched on CLI Summary: Create frame before initialize SA Reviewed-by: jbachorik, dsamersoff Contributed-by: kubota.yuji at gmail.com ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/HSDB.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/WorkerThread.java Changeset: 7b3006e2e0c3 Author: dsamersoff Date: 2016-01-29 12:37 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7b3006e2e0c3 Merge Changeset: b92f2d6f4608 Author: dsamersoff Date: 2016-01-29 14:59 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b92f2d6f4608 Merge Changeset: af014cb82e42 Author: dfazunen Date: 2016-01-29 16:17 +0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/af014cb82e42 8134963: [Newtest] New stress test for changing the coarseness level of G1 remembered set Reviewed-by: tschatzl, mchernov + test/stress/gc/TestStressRSetCoarsening.java Changeset: 9d0a489178e8 Author: tschatzl Date: 2016-01-29 17:42 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9d0a489178e8 Merge Changeset: f633da349d77 Author: ddmitriev Date: 2016-01-29 16:03 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f633da349d77 8147477: com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java is failing for the jdk9/hs snapshot control job Reviewed-by: gtriantafill, gziemski, dcubed, coleenp ! test/runtime/logging/ExceptionsTest.java + test/runtime/logging/ExceptionsTest_options_file Changeset: 5ccc08672132 Author: ddmitriev Date: 2016-01-29 18:17 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5ccc08672132 Merge Changeset: 5ef5fbf51b0d Author: sangheki Date: 2016-01-29 16:25 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5ef5fbf51b0d 8145190: MinTLABSize can cause overflow problem with CMS GC Summary: Changed max range of MinTLABSize from max_uintx to max_uintx/2 Reviewed-by: jwilhelm, tbenson ! src/share/vm/runtime/globals.hpp Changeset: 7f9a438ed88b Author: kbarrett Date: 2016-01-29 20:57 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7f9a438ed88b 8146793: logStream::write re-formats string Summary: Eliminate re-format, add warning attribute, fix size check, fix va_list usage. Reviewed-by: mlarsson, rprotacio, jrose ! src/share/vm/logging/log.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/ostream.hpp Changeset: 832fc8bf51cb Author: coleenp Date: 2016-01-30 11:02 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/832fc8bf51cb 8145628: hotspot metadata classes shouldn't use HeapWordSize or heap related macros like align_object_size Summary: Use align_metadata_size, align_metadata_offset and is_metadata_aligned for metadata rather than align_object_size, etc. Use wordSize rather than HeapWordSize for metadata. Use align_ptr_up rather than align_pointer_up (all the related functions are ptr). Reviewed-by: hseigel, jmasa, cjplummer ! src/cpu/sparc/vm/copy_sparc.hpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ConstantPoolCache.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Metadata.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/MethodData.java ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/stringTable.cpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/gc/g1/g1Allocator.cpp ! src/share/vm/gc/shared/collectedHeap.inline.hpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/padded.inline.hpp ! src/share/vm/memory/virtualspace.cpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/arrayKlass.hpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/cpCache.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/klassVtable.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/oops/objArrayKlass.hpp ! src/share/vm/oops/symbol.cpp ! src/share/vm/oops/symbol.hpp ! src/share/vm/oops/typeArrayKlass.hpp ! src/share/vm/utilities/globalDefinitions.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: aa28a104f3d8 Author: mgerdin Date: 2015-12-01 10:35 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/aa28a104f3d8 8148047: Move the vtable length field to Klass Reviewed-by: cjplummer, twisti, coleenp, kbarrett ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/aarch64/vm/vtableStubs_aarch64.cpp ! src/cpu/ppc/vm/macroAssembler_ppc.cpp ! src/cpu/ppc/vm/ppc.ad ! src/cpu/ppc/vm/templateTable_ppc_64.cpp ! src/cpu/ppc/vm/vtableStubs_ppc_64.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/vtableStubs_x86_32.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ArrayKlass.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Klass.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedJavaMethodImpl.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedObjectTypeImpl.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/jvmci/jvmciCompilerToVM.cpp ! src/share/vm/jvmci/jvmciCompilerToVM.hpp ! src/share/vm/jvmci/vmStructs_jvmci.cpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/arrayKlass.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/shark/sharkTopLevelBlock.cpp Changeset: 7954a3de5f0c Author: mgerdin Date: 2016-01-19 12:07 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7954a3de5f0c 8148481: Devirtualize Klass::vtable Summary: Move remainder of vtable related methods to Klass Reviewed-by: cjplummer, coleenp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/jvmci/jvmciCompilerToVM.cpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/arrayKlass.hpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/utilities/debug.cpp Changeset: 2b4562a094a8 Author: pliden Date: 2016-02-01 22:11 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2b4562a094a8 8147918: Rename develop_log_is_enabled() to log_develop_is_enabled() Reviewed-by: dholmes, brutisso ! src/share/vm/gc/cms/parNewGeneration.cpp ! src/share/vm/gc/g1/g1CollectedHeap.cpp ! src/share/vm/gc/parallel/psParallelCompact.cpp ! src/share/vm/gc/parallel/psPromotionManager.cpp ! src/share/vm/gc/parallel/psPromotionManager.inline.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/logging/log.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/oops/klassVtable.cpp Changeset: e0f0c06f1f9a Author: dholmes Date: 2016-02-01 20:39 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e0f0c06f1f9a 8148771: os::active_processor_count() returns garbage which causes VM to crash Reviewed-by: kbarrett ! src/share/vm/gc/g1/concurrentMark.cpp ! src/share/vm/gc/g1/dirtyCardQueue.cpp Changeset: a5d77b663c2b Author: stuefe Date: 2016-01-29 09:21 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a5d77b663c2b 8147510: [windows] no text locations shown for register info in hs-err file Reviewed-by: dholmes, iklam ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp Changeset: 913479df6e26 Author: dholmes Date: 2016-02-02 04:48 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/913479df6e26 Merge Changeset: 3f6379335462 Author: brutisso Date: 2016-02-02 09:51 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3f6379335462 8147913: Some runtime/CompressedOops tests fail on ARM64 product builds Reviewed-by: jmasa, kbarrett ! src/share/vm/memory/metaspace.cpp Changeset: c9ac779ff1f6 Author: dholmes Date: 2016-02-02 05:38 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c9ac779ff1f6 8148766: Test AvailableProcessors.java got wrong number of processors Reviewed-by: dsamersoff, tschatzl, mseledtsov ! test/runtime/os/AvailableProcessors.java Changeset: 5456a7af9989 Author: brutisso Date: 2016-02-02 10:50 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5456a7af9989 8148734: G1: Make G1GCPhaseTimes keep track of the start GC time Reviewed-by: sjohanss, tschatzl ! src/share/vm/gc/g1/g1CollectedHeap.cpp ! src/share/vm/gc/g1/g1CollectedHeap.hpp ! src/share/vm/gc/g1/g1CollectorPolicy.cpp ! src/share/vm/gc/g1/g1CollectorPolicy.hpp ! src/share/vm/gc/g1/g1GCPhaseTimes.cpp ! src/share/vm/gc/g1/g1GCPhaseTimes.hpp Changeset: 21f66749857c Author: brutisso Date: 2016-02-02 12:12 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/21f66749857c 8148733: G1: Add log message to print the heap region size Reviewed-by: sjohanss, david ! src/share/vm/gc/g1/heapRegion.cpp ! test/gc/logging/TestDeprecatedPrintFlags.java Changeset: 7852b2b18488 Author: brutisso Date: 2016-02-02 12:13 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7852b2b18488 8148736: Let the G1 heap transition log regions instead of bytes Reviewed-by: sjohanss, david ! src/share/vm/gc/g1/g1CollectedHeap.cpp ! src/share/vm/gc/g1/g1CollectedHeap.hpp ! src/share/vm/gc/g1/g1CollectorPolicy.cpp ! src/share/vm/gc/g1/g1CollectorPolicy.hpp + src/share/vm/gc/g1/g1HeapTransition.cpp + src/share/vm/gc/g1/g1HeapTransition.hpp Changeset: 8d8c1162953e Author: brutisso Date: 2016-02-02 13:06 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/8d8c1162953e Merge Changeset: 8bfb1133d754 Author: hseigel Date: 2016-02-02 08:27 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/8bfb1133d754 8135206: VM permits illegal flags for abstract methods in interfaces, versions 45.3 - 51.0 Summary: Add additional method flag checks Reviewed-by: jiangli, minqi ! src/share/vm/classfile/classFileParser.cpp Changeset: 04a9132aa6e4 Author: hseigel Date: 2016-02-02 14:54 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/04a9132aa6e4 Merge Changeset: 6231dc9a7946 Author: jwilhelm Date: 2016-02-03 01:35 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6231dc9a7946 Merge ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/ppc/vm/macroAssembler_ppc.cpp ! src/cpu/ppc/vm/ppc.ad ! src/cpu/ppc/vm/templateTable_ppc_64.cpp ! src/cpu/ppc/vm/vtableStubs_ppc_64.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedJavaMethodImpl.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedObjectTypeImpl.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/jvmci/jvmciCompilerToVM.cpp ! src/share/vm/jvmci/jvmciCompilerToVM.hpp ! src/share/vm/jvmci/vmStructs_jvmci.cpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/vmError.cpp Changeset: f1c3681c4174 Author: dholmes Date: 2016-02-02 22:12 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f1c3681c4174 8146616: VM exit path throws fatal error: Thread holding lock at safepoint that vm can block on: BeforeExit_lock Reviewed-by: dcubed, gthornbr ! src/share/vm/runtime/java.cpp Changeset: 0ce2cc153eda Author: redestad Date: 2016-02-03 14:15 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0ce2cc153eda 8148755: -XX:+HeapDumpAfterFullGC creates heap dump both before and after Full GC Reviewed-by: mgerdin, brutisso, sangheki ! src/share/vm/gc/shared/collectedHeap.cpp ! src/share/vm/gc/shared/collectedHeap.hpp Changeset: 62c20ff640a0 Author: asmotrak Date: 2016-02-03 09:31 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/62c20ff640a0 8147884: Names of GC threads should be set before the threads start Reviewed-by: mgerdin, david ! src/share/vm/gc/g1/concurrentG1RefineThread.cpp ! src/share/vm/gc/g1/g1YoungRemSetSamplingThread.cpp Changeset: 3637ec3e50c2 Author: mockner Date: 2016-02-03 11:40 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3637ec3e50c2 8079408: Reimplement TraceClassLoading, TraceClassUnloading, and TraceClassLoaderData with Unified Logging. Summary: TraceClassLoading, TraceClassUnloading, and TraceClassLoaderData have been reimplemented using Unified logging. Reviewed-by: iklam, coleenp, dholmes, jiangli, hseigel, rprotacio Contributed-by: max.ockner at oracle.com, ioi.lam at oracle.com ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/logging/logTag.hpp ! src/share/vm/memory/filemap.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/services/classLoadingService.cpp ! src/share/vm/services/classLoadingService.hpp ! test/compiler/jsr292/CallSiteDepContextTest.java + test/runtime/logging/ClassLoadUnloadTest.java + test/runtime/logging/classes/test/Empty.java ! test/runtime/testlibrary/ClassUnloadCommon.java Changeset: 49bb4aa253c3 Author: mockner Date: 2016-02-03 18:16 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/49bb4aa253c3 Merge - make/gensrc/Gensrc-jdk.vm.ci.gmk - src/cpu/x86/vm/macroAssembler_x86_libm.cpp - src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/CompilationResult.java - src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/DataSection.java - src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/InfopointReason.java - src/jdk.vm.ci/share/classes/jdk.vm.ci.service.processor/src/META-INF/services/javax.annotation.processing.Processor - src/jdk.vm.ci/share/classes/jdk.vm.ci.service.processor/src/jdk/vm/ci/service/processor/ServiceProviderProcessor.java - src/jdk.vm.ci/share/classes/jdk.vm.ci.service/.checkstyle_checks.xml - src/jdk.vm.ci/share/classes/jdk.vm.ci.service/src/jdk/vm/ci/service/ServiceProvider.java - src/jdk.vm.ci/share/classes/jdk.vm.ci.service/src/jdk/vm/ci/service/Services.java ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/globals.hpp Changeset: 599bd517eda1 Author: mockner Date: 2016-02-03 19:46 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/599bd517eda1 Merge Changeset: e562322af4d7 Author: coleenp Date: 2016-02-03 17:26 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e562322af4d7 8146984: SIGBUS: bool Method::has_method_vptr(const void*)+0xc Summary: Add address check and use SafeFetchN for Method* vptr access when Method* may be bad pointer. Reviewed-by: dcubed, mgronlun ! src/share/vm/oops/method.cpp Changeset: 9fc51379c2c0 Author: coleenp Date: 2016-02-03 18:48 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9fc51379c2c0 Merge Changeset: beb0e7647de7 Author: ctornqvi Date: 2016-02-03 13:42 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/beb0e7647de7 8148747: [TESTBUG] runtime/Unsafe/AllocateMemory.java fails with OOM during compilation Reviewed-by: coleenp, gtriantafill ! test/runtime/Unsafe/AllocateMemory.java ! test/runtime/Unsafe/Reallocate.java Changeset: 28dcfa2f0275 Author: dfazunen Date: 2016-02-03 20:07 +0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/28dcfa2f0275 8147003: Move BubbleUpRef test into CMS directory Summary: closed test gc/4950157/BubbleUpRef.java moved to gc/cms/TestBubbleUpRef.java Reviewed-by: jwilhelm, brutisso + test/gc/cms/TestBubbleUpRef.java Changeset: cff975a4c46e Author: jwilhelm Date: 2016-02-04 00:53 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/cff975a4c46e Merge Changeset: 3273eec11f6e Author: mlarsson Date: 2016-02-02 11:09 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3273eec11f6e 8148053: Remove unused log tags Reviewed-by: dholmes, mlarsson, sla Contributed-by: robbin.ehn at oracle.com ! src/share/vm/logging/logTag.hpp Changeset: 2a96f7f8beb4 Author: mlarsson Date: 2016-02-04 08:36 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2a96f7f8beb4 8148141: Remove fixed level padding in UL Reviewed-by: sla, mlarsson Contributed-by: robbin.ehn at oracle.com ! src/share/vm/logging/logFileStreamOutput.hpp Changeset: b7d194c17292 Author: mgerdin Date: 2016-02-03 11:33 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b7d194c17292 8148944: CollectorPolicy methods for memory allocations are specific to GenCollectorPolicy Reviewed-by: jwilhelm, kbarrett ! src/share/vm/gc/g1/g1CollectorPolicy.cpp ! src/share/vm/gc/g1/g1CollectorPolicy.hpp ! src/share/vm/gc/shared/collectorPolicy.hpp ! src/share/vm/gc/shared/genCollectedHeap.cpp Changeset: d2f09fe6e255 Author: sgehwolf Date: 2016-02-03 12:19 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d2f09fe6e255 8148945: JDK-8148481: Devirtualize Klass::vtable breaks Zero build Summary: Use Klass::method_at_vtable() instead of InstanceClass::start_of_vtable()[index] Reviewed-by: mgerdin, coleenp ! src/share/vm/interpreter/bytecodeInterpreter.cpp Changeset: c2bc224e0288 Author: brutisso Date: 2016-02-03 18:18 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c2bc224e0288 8148960: Humongous mis-spelled in log output Reviewed-by: huntch, jwilhelm ! src/share/vm/gc/g1/g1RemSetSummary.cpp ! test/gc/g1/TestRemsetLoggingTools.java Changeset: 37edad3f92ef Author: brutisso Date: 2016-02-03 18:21 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/37edad3f92ef 8148951: Remove unused method Generation::performs_in_place_marking() Reviewed-by: david, jwilhelm ! src/share/vm/gc/serial/defNewGeneration.hpp ! src/share/vm/gc/shared/genCollectedHeap.cpp ! src/share/vm/gc/shared/generation.hpp Changeset: bfeb86d783f3 Author: brutisso Date: 2016-02-04 11:38 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/bfeb86d783f3 Merge ! src/share/vm/gc/shared/genCollectedHeap.cpp Changeset: 4dbe4467def1 Author: ehelin Date: 2016-02-04 14:06 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4dbe4467def1 8148844: Update run_unit_test macro for InternalVMTests Reviewed-by: sjohanss, david ! src/share/vm/utilities/internalVMTests.cpp ! src/share/vm/utilities/internalVMTests.hpp Changeset: 173f348dc59a Author: kzhaldyb Date: 2016-02-02 18:06 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/173f348dc59a 8132721: Add tests which check that heap counters work as expected during Humongous allocations Reviewed-by: jmasa, tschatzl, dfazunen + test/gc/g1/humongousObjects/TestHeapCounters.java Changeset: ac36a853b8bb Author: dsimms Date: 2016-02-04 18:28 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ac36a853b8bb 8138562: Event based tracing should cover monitor inflation Reviewed-by: dcubed, egahlin, mgronlun ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/synchronizer.hpp ! src/share/vm/trace/trace.xml ! src/share/vm/trace/traceEventClasses.xsl ! src/share/vm/trace/tracetypes.xml Changeset: 563c2655a1d1 Author: mgronlun Date: 2016-02-04 19:27 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/563c2655a1d1 Merge Changeset: c83c923eb4da Author: asmotrak Date: 2016-02-04 13:42 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c83c923eb4da 8148005: One byte may be corrupted by get_datetime_string() Reviewed-by: dholmes ! src/share/vm/utilities/ostream.cpp Changeset: 331e128af110 Author: coleenp Date: 2016-02-04 18:25 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/331e128af110 8149038: SIGSEGV at frame::is_interpreted_frame_valid -> StubRoutines::SafeFetchN Summary: Backout change for 8146984 but add an alignment check which may have caught original bug. Reviewed-by: mgronlun, dcubed ! src/share/vm/oops/method.cpp Changeset: 4c4a1df979c6 Author: coleenp Date: 2016-02-04 23:39 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4c4a1df979c6 Merge Changeset: 9d41cca130a7 Author: brutisso Date: 2016-02-05 08:59 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9d41cca130a7 8149035: Make the full_gc_dump() calls be recorded as part of the GC Reviewed-by: jmasa, sjohanss ! src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc/parallel/psMarkSweep.cpp ! src/share/vm/gc/parallel/psParallelCompact.cpp ! src/share/vm/gc/serial/tenuredGeneration.cpp ! src/share/vm/gc/shared/collectedHeap.cpp ! src/share/vm/gc/shared/genCollectedHeap.cpp ! src/share/vm/logging/logPrefix.hpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/heapInspection.hpp Changeset: 4b76b87db5fa Author: redestad Date: 2016-02-05 14:00 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4b76b87db5fa 8144916: Decrease PerfDataMemorySize back to 32K Reviewed-by: mlarsson, sla Contributed-by: robbin.ehn at oracle.com ! src/share/vm/runtime/globals.hpp Changeset: 317e69421e35 Author: hseigel Date: 2016-02-05 08:14 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/317e69421e35 8148785: Update class file version to 53 for JDK-9 Summary: Change max supported class file version to 53 Reviewed-by: alanb, coleenp, shade ! src/share/vm/classfile/classFileParser.cpp + test/runtime/classFileParserBug/Class53.jasm Changeset: 43428ecf682b Author: hseigel Date: 2016-02-05 16:19 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/43428ecf682b Merge Changeset: 4fa762a8efa2 Author: ehelin Date: 2016-02-05 16:03 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4fa762a8efa2 8148973: Rename g1/concurrentMark.{hpp,cpp,inline.hpp} to g1/g1ConcurrentMark.{hpp,cpp,inline.hpp} Reviewed-by: tschatzl, mgerdin - src/share/vm/gc/g1/concurrentMark.cpp - src/share/vm/gc/g1/concurrentMark.hpp - src/share/vm/gc/g1/concurrentMark.inline.hpp ! src/share/vm/gc/g1/concurrentMarkThread.cpp ! src/share/vm/gc/g1/concurrentMarkThread.hpp ! src/share/vm/gc/g1/concurrentMarkThread.inline.hpp ! src/share/vm/gc/g1/g1CollectedHeap.cpp ! src/share/vm/gc/g1/g1CollectedHeap.hpp ! src/share/vm/gc/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc/g1/g1CollectorPolicy.cpp + src/share/vm/gc/g1/g1ConcurrentMark.cpp + src/share/vm/gc/g1/g1ConcurrentMark.hpp + src/share/vm/gc/g1/g1ConcurrentMark.inline.hpp ! src/share/vm/gc/g1/g1EvacFailure.cpp ! src/share/vm/gc/g1/g1EvacFailure.hpp ! src/share/vm/gc/g1/g1HeapVerifier.cpp ! src/share/vm/gc/g1/g1HeapVerifier.hpp ! src/share/vm/gc/g1/g1OopClosures.hpp ! src/share/vm/gc/g1/g1OopClosures.inline.hpp ! src/share/vm/prims/whitebox.cpp Changeset: 3472ec7733c2 Author: ehelin Date: 2016-02-05 18:37 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3472ec7733c2 Merge - src/share/vm/gc/g1/concurrentMark.cpp - src/share/vm/gc/g1/concurrentMark.hpp - src/share/vm/gc/g1/concurrentMark.inline.hpp Changeset: 78f06e5daedf Author: akulyakh Date: 2016-02-08 14:50 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/78f06e5daedf 8147847: [TESTBUG] serviceability/tmtools/jstat test ported to JTREG are failing with -XX:+ExplicitGCInvokesConcurrent Summary: Fixed the test scenarios to eliminate false failures Reviewed-by: jbachorik ! test/serviceability/tmtools/jstat/GcCapacityTest.java ! test/serviceability/tmtools/jstat/GcCauseTest01.java ! test/serviceability/tmtools/jstat/GcTest01.java ! test/serviceability/tmtools/jstat/utils/GcProvokerImpl.java ! test/serviceability/tmtools/jstat/utils/JstatGcCapacityResults.java Changeset: e667306e9c8e Author: kzhaldyb Date: 2016-02-08 18:01 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e667306e9c8e 8149364: Quarantine TestSelectDefaultGC.java test Reviewed-by: dfazunen, jwilhelm ! test/gc/arguments/TestSelectDefaultGC.java Changeset: 33124861e457 Author: mchernov Date: 2016-02-08 18:54 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/33124861e457 8148745: [testbug] Test gc/g1/plab/TestPLABPromotion.java fails in nightly Reviewed-by: tschatzl, dfazunen ! test/gc/g1/plab/TestPLABPromotion.java ! test/gc/g1/plab/TestPLABResize.java ! test/gc/g1/plab/lib/PLABUtils.java Changeset: 3d001eab27e3 Author: iignatyev Date: 2015-12-17 16:12 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3d001eab27e3 8144695: --disable-warnings-as-errors does not work for HotSpot build Reviewed-by: kbarrett, ihse ! make/bsd/makefiles/gcc.make ! make/linux/makefiles/gcc.make ! make/solaris/makefiles/adlc.make ! make/solaris/makefiles/gcc.make ! make/solaris/makefiles/sparcWorks.make Changeset: 2a8e87190908 Author: kzhaldyb Date: 2016-02-08 18:26 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2a8e87190908 8149184: os::is_server_class_machine() could return incorrect result if a host's cpu have a few logical cores Reviewed-by: dsamersoff, dholmes ! src/share/vm/runtime/os.cpp Changeset: 535178906f68 Author: mlarsson Date: 2016-02-09 12:19 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/535178906f68 8149112: configure_stdout test depends on VM arguments Reviewed-by: ehelin, jbachorik ! src/share/vm/logging/log.cpp Changeset: fe043f3261cc Author: jwilhelm Date: 2016-02-11 21:07 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/fe043f3261cc Merge ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedObjectTypeImpl.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java ! src/share/vm/code/nmethod.cpp ! src/share/vm/runtime/globals.hpp Changeset: 8e7e7926b403 Author: amurillo Date: 2016-02-11 13:58 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/8e7e7926b403 Merge - src/share/vm/gc/g1/concurrentMark.cpp - src/share/vm/gc/g1/concurrentMark.hpp - src/share/vm/gc/g1/concurrentMark.inline.hpp Changeset: e37297fef203 Author: amurillo Date: 2016-02-15 09:44 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e37297fef203 Merge Changeset: 13e9201c31e4 Author: rriggs Date: 2016-02-18 14:45 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/13e9201c31e4 8149750: Decouple sun.misc.Signal from the base module Reviewed-by: dholmes, chegar ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/os.cpp Changeset: c5146d4da417 Author: lana Date: 2016-02-18 13:42 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c5146d4da417 Merge - src/share/vm/gc/g1/concurrentMark.cpp - src/share/vm/gc/g1/concurrentMark.hpp - src/share/vm/gc/g1/concurrentMark.inline.hpp Changeset: 0e6f2f47479c Author: lana Date: 2016-02-25 09:41 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0e6f2f47479c Added tag jdk-9+107 for changeset c5146d4da417 ! .hgtags Changeset: 64d8659d343f Author: henryjen Date: 2016-03-01 13:08 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/64d8659d343f Merge ! .hgtags ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/HSDB.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ArrayKlass.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ConstantPoolCache.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Klass.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Metadata.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/MethodData.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/WorkerThread.java ! src/os/linux/vm/os_linux.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/modules.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/vmSymbols.hpp - src/share/vm/gc/g1/concurrentMark.cpp - src/share/vm/gc/g1/concurrentMark.hpp - src/share/vm/gc/g1/concurrentMark.inline.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/logging/logTag.hpp ! src/share/vm/memory/filemap.cpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/arrayKlass.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/trace/tracetypes.xml ! src/share/vm/utilities/ostream.cpp ! test/compiler/jsr292/CallSiteDepContextTest.java ! test/compiler/jvmci/JVM_GetJVMCIRuntimeTest.java ! test/compiler/jvmci/errors/TestInvalidCompilationResult.java ! test/compiler/jvmci/errors/TestInvalidDebugInfo.java ! test/compiler/jvmci/errors/TestInvalidOopMap.java ! test/compiler/jvmci/events/JvmciNotifyInstallEventTest.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java ! test/runtime/Unsafe/AllocateMemory.java ! test/runtime/Unsafe/Reallocate.java ! test/serviceability/dcmd/gc/HeapDumpAllTest.java ! test/serviceability/dcmd/gc/HeapDumpTest.java ! test/testlibrary_tests/whitebox/vm_flags/IntxTest.java From mandy.chung at oracle.com Tue Mar 1 22:02:09 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 01 Mar 2016 22:02:09 +0000 Subject: hg: jigsaw/jake/jaxp: 4 new changesets Message-ID: <201603012202.u21M29Ox025973@aojmv0008.oracle.com> Changeset: 4786b4c1ba69 Author: joehw Date: 2016-02-17 16:32 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/4786b4c1ba69 8146237: PREFER from Features API taking precedence over catalog file Reviewed-by: lancea ! src/java.xml/share/classes/javax/xml/catalog/CatalogReader.java ! test/javax/xml/jaxp/unittest/catalog/CatalogTest.java + test/javax/xml/jaxp/unittest/catalog/JDK8146237_catalog.xml Changeset: 781b83dadcae Author: lana Date: 2016-02-18 13:40 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/781b83dadcae Merge Changeset: d4c0e3bcc5ae Author: lana Date: 2016-02-25 09:41 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/d4c0e3bcc5ae Added tag jdk-9+107 for changeset 781b83dadcae ! .hgtags Changeset: ae011e8a01e6 Author: henryjen Date: 2016-03-01 13:08 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/ae011e8a01e6 Merge From mandy.chung at oracle.com Tue Mar 1 22:02:13 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 01 Mar 2016 22:02:13 +0000 Subject: hg: jigsaw/jake/jaxws: 4 new changesets Message-ID: <201603012202.u21M2DUg026022@aojmv0008.oracle.com> Changeset: 68e3599c33c1 Author: mkos Date: 2016-02-18 10:20 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/68e3599c33c1 8149923: invalid javadoc in javax.xml.bind.JAXBContext (introduced by 8138699) Reviewed-by: lancea ! src/java.xml.bind/share/classes/javax/xml/bind/JAXBContext.java Changeset: fafd694e801f Author: lana Date: 2016-02-18 13:41 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/fafd694e801f Merge Changeset: 513eb2e432f6 Author: lana Date: 2016-02-25 09:41 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/513eb2e432f6 Added tag jdk-9+107 for changeset fafd694e801f ! .hgtags Changeset: 7d99205d52d1 Author: henryjen Date: 2016-03-01 13:08 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/7d99205d52d1 Merge From mandy.chung at oracle.com Tue Mar 1 22:02:26 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 01 Mar 2016 22:02:26 +0000 Subject: hg: jigsaw/jake/jdk: 61 new changesets Message-ID: <201603012202.u21M2SZe026159@aojmv0008.oracle.com> Changeset: 689c1a6f8768 Author: vinnie Date: 2016-02-15 15:57 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/689c1a6f8768 8149411: PKCS12KeyStore cannot extract AES Secret Keys Reviewed-by: xuelei ! src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java + test/sun/security/pkcs12/P12SecretKey.java Changeset: a8e8864441ba Author: sherman Date: 2016-02-15 10:27 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a8e8864441ba 8148624: Test failure of ConstructInflaterOutput.java Reviewed-by: darcy ! test/java/util/zip/ConstructDeflaterInput.java ! test/java/util/zip/ConstructInflaterOutput.java Changeset: 48719c6d683e Author: mockner Date: 2016-02-02 17:14 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/48719c6d683e 8079408: Reimplement TraceClassLoading, TraceClassUnloading, and TraceClassLoaderData with Unified Logging. Summary: TraceClassLoading, TraceClassUnloading, and TraceClassLoaderData have been reimplemented using Unified logging. Reviewed-by: iklam, coleenp, dholmes, jiangli, hseigel, rprotacio ! test/java/lang/ClassLoader/deadlock/TestCrossDelegate.sh ! test/java/lang/ClassLoader/deadlock/TestOneWayDelegate.sh ! test/java/lang/instrument/appendToClassLoaderSearch/ClassUnloadTest.sh Changeset: 8d39edf65773 Author: mockner Date: 2016-02-03 18:16 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8d39edf65773 Merge - test/java/net/SocketPermission/policy Changeset: 64396eb116b5 Author: dsimms Date: 2016-02-04 18:33 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/64396eb116b5 8149025: JFR - Event based tracing should cover monitor inflation Reviewed-by: dcubed, egahlin, mgronlun + com/oracle/jfr/runtime/TestJavaMonitorInflateEvent.java Changeset: fafd55278ea0 Author: mgronlun Date: 2016-02-04 23:30 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fafd55278ea0 8149062: Remove misplaced integration of test code after 8149025 Reviewed-by: coleenp - com/oracle/jfr/runtime/TestJavaMonitorInflateEvent.java Changeset: 0a8ae84bf66c Author: redestad Date: 2016-02-05 14:03 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0a8ae84bf66c 8144916: Decrease PerfDataMemorySize back to 32K Reviewed-by: mlarsson, sla Contributed-by: robbin.ehn at oracle.com ! test/sun/jvmstat/perfdata/PrologSanity/PrologSizeSanityCheck.java Changeset: fa700a06bb3d Author: hseigel Date: 2016-02-05 08:12 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fa700a06bb3d 8148785: Update class file version to 53 for JDK-9 Summary: Change max support class file veriosn to 53 Reviewed-by: alanb, coleenp, shade ! src/java.base/share/native/libjava/System.c Changeset: edda8adca82b Author: hseigel Date: 2016-02-05 16:19 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/edda8adca82b Merge Changeset: fb55d8342279 Author: dsamersoff Date: 2016-02-05 17:49 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fb55d8342279 8149099: jcmd -help mention non-existent option Summary: Fix typo -p to -l Reviewed-by: dsamersoff, jbachorik Contributed-by: kubota.yuji at gmail.com ! src/jdk.jcmd/share/classes/sun/tools/jcmd/Arguments.java Changeset: 432c74ac67dd Author: dsamersoff Date: 2016-02-05 16:32 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/432c74ac67dd Merge Changeset: 32811d696f33 Author: dsamersoff Date: 2016-02-05 19:13 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/32811d696f33 Merge Changeset: 92f9b82fb790 Author: dsamersoff Date: 2016-02-06 14:22 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/92f9b82fb790 8149174: [TESTBUG] TestJcmdDefaults.java: ouput should contain all content of jcmd/usage.out Summary: fixed typoeo in expected output Reviewed-by: sspitsyn ! test/sun/tools/jcmd/usage.out Changeset: 922c2d9d2ba7 Author: kbarrett Date: 2016-02-09 18:42 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/922c2d9d2ba7 8072777: java/lang/ref/ReferenceEnqueuePending.java: some references aren't queued Summary: Wait for enqueuing. Reviewed-by: plevart, mchung ! test/java/lang/ref/ReferenceEnqueuePending.java Changeset: 0df3ff4aafdf Author: jwilhelm Date: 2016-02-11 21:07 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0df3ff4aafdf Merge - src/java.base/share/classes/sun/misc/Cleaner.java - src/java.desktop/share/classes/sun/awt/DefaultMouseInfoPeer.java - test/jdk/internal/misc/JavaLangAccess/FormatUnsigned.java - test/sun/misc/Cleaner/ExitOnThrow.java - test/sun/misc/Cleaner/exitOnThrow.sh Changeset: b423ea4d0fae Author: amurillo Date: 2016-02-11 13:58 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b423ea4d0fae Merge Changeset: 1f47d1389a67 Author: amurillo Date: 2016-02-15 09:44 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1f47d1389a67 Merge - src/java.base/share/classes/sun/misc/InnocuousThread.java - src/java.base/share/classes/sun/misc/LRUCache.java Changeset: b3ff4bce9d63 Author: amurillo Date: 2016-02-15 13:37 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b3ff4bce9d63 Merge Changeset: 10e298cb4ef1 Author: sherman Date: 2016-02-15 18:41 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/10e298cb4ef1 8135108: java/util/zip/TestLocalTime.java fails intermittently with Invalid value for NanoOfSecond Reviewed-by: darcy ! src/java.base/share/classes/java/util/zip/ZipEntry.java ! test/java/util/zip/TestLocalTime.java Changeset: a0317b3da929 Author: iignatyev Date: 2016-02-16 07:06 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a0317b3da929 8149700: Remove jdk_svc test group from tier * groups Reviewed-by: darcy ! test/TEST.groups Changeset: 1e63e8beb44f Author: rriggs Date: 2016-02-16 11:36 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1e63e8beb44f 8148775: Spec for j.l.ProcessBuilder.Redirect.DISCARD need to be improved Reviewed-by: martin ! src/java.base/share/classes/java/lang/ProcessBuilder.java Changeset: d01cd46ec6c1 Author: darcy Date: 2016-02-16 09:09 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d01cd46ec6c1 8149896: Remove unnecessary values in FloatConsts and DoubleConsts Reviewed-by: shade, psandoz, lbourges, mduigou ! src/java.base/share/classes/java/lang/Double.java ! src/java.base/share/classes/java/lang/Float.java ! src/java.base/share/classes/java/lang/Math.java ! src/java.base/share/classes/java/util/Formatter.java ! src/java.base/share/classes/jdk/internal/math/DoubleConsts.java ! src/java.base/share/classes/jdk/internal/math/FloatConsts.java ! src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java ! src/java.desktop/share/classes/sun/java2d/marlin/FloatMath.java ! src/java.desktop/share/classes/sun/java2d/marlin/Renderer.java Changeset: 94e2be8fe284 Author: dl Date: 2016-02-16 09:49 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/94e2be8fe284 8139927: Improve documentation for CompletableFuture composition 8143089: CompletableFuture.whenComplete should use addSuppressed Reviewed-by: martin, psandoz, chegar, plevart ! src/java.base/share/classes/java/util/concurrent/CompletableFuture.java ! src/java.base/share/classes/java/util/concurrent/CompletionStage.java ! test/java/util/concurrent/tck/CompletableFutureTest.java Changeset: 2e8ae386b506 Author: dl Date: 2016-02-16 09:52 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2e8ae386b506 8145485: Miscellaneous changes imported from jsr166 CVS 2016-02 Reviewed-by: martin, psandoz, chegar ! src/java.base/share/classes/java/util/SplittableRandom.java ! src/java.base/share/classes/java/util/concurrent/Exchanger.java ! src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java ! src/java.base/share/classes/java/util/concurrent/ForkJoinTask.java ! src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java ! src/java.base/share/classes/java/util/concurrent/atomic/Striped64.java ! test/java/util/concurrent/ConcurrentQueues/RemovePollRace.java ! test/java/util/concurrent/ExecutorCompletionService/ExecutorCompletionServiceLoops.java Changeset: 3cef15298cd1 Author: psadhukhan Date: 2016-01-27 14:12 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3cef15298cd1 8147077: IllegalArgumentException thrown by api/java_awt/Component/FlipBufferStrategy/indexTGF_General Reviewed-by: flar, arapte ! src/java.desktop/unix/classes/sun/awt/X11GraphicsConfig.java Changeset: 036a79401943 Author: psadhukhan Date: 2016-01-27 14:13 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/036a79401943 8148127: IllegalArgumentException thrown by JCK test api/java_awt/Component/FlipBufferStrategy/indexTGF_General in opengl pipeline Reviewed-by: flar, arapte ! src/java.desktop/windows/classes/sun/java2d/opengl/WGLGraphicsConfig.java Changeset: c07d26adffbb Author: mhalder Date: 2016-01-29 15:21 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c07d26adffbb 8075964: Test java/awt/Mouse/TitleBarDoubleClick/TitleBarDoubleClick.html fails intermittently with timeout error Reviewed-by: arapte, ssadetsky ! test/java/awt/Mouse/TitleBarDoubleClick/TitleBarDoubleClick.java Changeset: c047d37dd495 Author: jdv Date: 2016-02-01 15:39 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c047d37dd495 8022640: ServiceRegistry (used by ImageIO) lack synchronization Reviewed-by: prr, psadhukhan ! src/java.desktop/share/classes/javax/imageio/spi/ServiceRegistry.java + test/javax/imageio/spi/ServiceRegistrySyncTest.java Changeset: a410a39a544c Author: jdv Date: 2016-02-02 11:50 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a410a39a544c 8147413: api/java_awt/Image/MultiResolutionImage/index.html\#MultiResolutionRenderingHints[test_VALUE_RESOLUTION_VARIANT_BASE] started to fail Reviewed-by: alexsch, flar ! src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java Changeset: b9f91de8ae43 Author: arapte Date: 2016-02-02 14:19 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b9f91de8ae43 6180449: PIT: Text in TextArea scrolls to its left one char when selecting the text from the end Reviewed-by: ssadetsky, psadhukhan ! src/java.desktop/windows/native/libawt/windows/awt_TextArea.cpp + test/java/awt/TextArea/TextAreaScrolling/TextAreaScrolling.java Changeset: 1198be168916 Author: psadhukhan Date: 2016-02-02 15:57 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1198be168916 8005918: [TESTBUG] There are no 'Frame Enter' messages for both frames, only 'Button Enter' message. Reviewed-by: arapte, alexsch Contributed-by: ajit.ghaisas at oracle.com + test/java/awt/LightweightComponent/LightweightEventTest/LightweightEventTest.java Changeset: 55a81cfbe8be Author: alitvinov Date: 2016-02-02 16:33 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/55a81cfbe8be 8139581: AWT components are not drawn after removal and addition to a container Reviewed-by: ssadetsky, alexsch ! src/java.desktop/unix/classes/sun/awt/X11/XBaseWindow.java + test/java/awt/Paint/ComponentIsNotDrawnAfterRemoveAddTest/ComponentIsNotDrawnAfterRemoveAddTest.java Changeset: b9a92b2a8b37 Author: ddehaven Date: 2016-02-02 12:12 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b9a92b2a8b37 Merge - src/java.base/share/classes/sun/misc/Cleaner.java - test/java/net/SocketPermission/policy - test/sun/misc/Cleaner/ExitOnThrow.java - test/sun/misc/Cleaner/exitOnThrow.sh Changeset: d74d0c07410f Author: psadhukhan Date: 2016-02-04 11:16 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d74d0c07410f 8062946: Transparent JDialog will lose transparency upon iconify/deiconify sequence. Reviewed-by: arapte, alexsch Contributed-by: prem.balakrishnan at oracle.com ! src/java.desktop/windows/native/libawt/windows/awt_Window.cpp + test/javax/swing/JDialog/Transparency/TransparencyTest.java Changeset: 330cfe5a282e Author: avstepan Date: 2016-02-04 14:27 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/330cfe5a282e 8145780: create a simple test for TIFF tag sets Reviewed-by: bpb, yan + test/javax/imageio/plugins/tiff/TIFFTagSetTest.java Changeset: d26d76e02704 Author: alexsch Date: 2016-02-06 09:25 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d26d76e02704 8149151: Use local GraphicsEnvironment to get screen size in WToolkit Reviewed-by: prr, serb ! src/java.desktop/windows/classes/sun/awt/windows/WToolkit.java ! src/java.desktop/windows/native/libawt/windows/awt_Toolkit.cpp ! test/java/awt/Toolkit/GetSizeTest/GetScreenSizeTest.java Changeset: 7d15f9688d56 Author: avstepan Date: 2016-02-08 11:43 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7d15f9688d56 8142861: [TEST] MultiResolution image: add a manual test for two-display configuration (HiDPI + non-HiDPI) Reviewed-by: alexsch + test/java/awt/image/multiresolution/MultiDisplayTest/MultiDisplayTest.html + test/java/awt/image/multiresolution/MultiDisplayTest/MultiDisplayTest.java Changeset: 73de275f4541 Author: prr Date: 2016-02-08 09:41 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/73de275f4541 Merge - test/jdk/internal/misc/JavaLangAccess/FormatUnsigned.java Changeset: b12d3cf3b605 Author: prr Date: 2016-02-16 09:30 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b12d3cf3b605 Merge - src/java.base/share/classes/sun/misc/InnocuousThread.java - src/java.base/share/classes/sun/misc/LRUCache.java Changeset: b766cd93e8a6 Author: prr Date: 2016-02-16 10:54 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b766cd93e8a6 Merge Changeset: ded40e079410 Author: darcy Date: 2016-02-16 11:06 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ded40e079410 8149981: java/util/Formatter/Basic.java fails after JDK-8149896 Reviewed-by: rriggs, bpb ! test/java/util/Formatter/Basic-X.java.template ! test/java/util/Formatter/Basic.java ! test/java/util/Formatter/BasicBigDecimal.java ! test/java/util/Formatter/BasicBigInteger.java ! test/java/util/Formatter/BasicBoolean.java ! test/java/util/Formatter/BasicBooleanObject.java ! test/java/util/Formatter/BasicByte.java ! test/java/util/Formatter/BasicByteObject.java ! test/java/util/Formatter/BasicChar.java ! test/java/util/Formatter/BasicCharObject.java ! test/java/util/Formatter/BasicDateTime.java ! test/java/util/Formatter/BasicDouble.java ! test/java/util/Formatter/BasicDoubleObject.java ! test/java/util/Formatter/BasicFloat.java ! test/java/util/Formatter/BasicFloatObject.java ! test/java/util/Formatter/BasicInt.java ! test/java/util/Formatter/BasicIntObject.java ! test/java/util/Formatter/BasicLong.java ! test/java/util/Formatter/BasicLongObject.java ! test/java/util/Formatter/BasicShort.java ! test/java/util/Formatter/BasicShortObject.java Changeset: 7bcaf8487c69 Author: weijun Date: 2016-02-17 11:23 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7bcaf8487c69 8147772: Update KerberosTicket to describe behavior if it has been destroyed and fix NullPointerExceptions Reviewed-by: mullan ! src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosTicket.java ! test/javax/security/auth/kerberos/KerberosTixDateTest.java Changeset: cd3e468e8b51 Author: chegar Date: 2016-02-17 11:45 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/cd3e468e8b51 8068686: Remove meta-index support Reviewed-by: alanb, erikj, mchung ! make/Tools.gmk - make/src/classes/build/tools/buildmetaindex/BuildMetaIndex.java ! src/java.base/share/classes/sun/misc/JarIndex.java ! src/java.base/share/classes/sun/misc/Launcher.java - src/java.base/share/classes/sun/misc/MetaIndex.java ! src/java.base/share/classes/sun/misc/URLClassPath.java Changeset: b9e8b0ca1256 Author: shade Date: 2016-02-17 19:29 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b9e8b0ca1256 8149835: StringConcatFactory should emit classes with the same package as the host class Reviewed-by: psandoz, alanb, mchung ! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java Changeset: 3973fe856db2 Author: darcy Date: 2016-02-17 12:47 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3973fe856db2 8148914: BitDepth.java test fails Reviewed-by: bpb, prr ! test/javax/imageio/plugins/shared/BitDepth.java Changeset: 2291d589ccc0 Author: amlu Date: 2016-02-18 09:46 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2291d589ccc0 8149922: Remove intermittent key from security tests 8150047: Remove SSLSession/SessionCacheSizeTests from ProblemList Reviewed-by: xuelei ! test/ProblemList.txt ! test/javax/net/ssl/SSLSession/SessionCacheSizeTests.java ! test/sun/security/mscapi/ShortRSAKey1024.sh ! test/sun/security/mscapi/SignUsingSHA2withRSA.sh Changeset: 4ffa549a798f Author: amlu Date: 2016-02-18 09:50 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4ffa549a798f 8149920: Remove intermittent key from jdk_core tests Reviewed-by: darcy ! test/com/sun/jndi/ldap/LdapTimeoutTest.java ! test/java/lang/ProcessHandle/InfoTest.java ! test/java/net/Inet6Address/serialize/Inet6AddressSerializationTest.java ! test/java/net/SocketPermission/SocketPermissionTest.java ! test/java/util/concurrent/Phaser/Basic.java ! test/sun/nio/cs/FindDecoderBugs.java ! test/sun/nio/cs/FindEncoderBugs.java Changeset: 1a2957d53460 Author: mchung Date: 2016-02-17 17:45 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1a2957d53460 8074069: Move com.oracle.net and com.oracle.nio APIs to jdk.net module Reviewed-by: alanb ! make/src/classes/build/tools/module/boot.modules Changeset: 916ff9b5344f Author: mchung Date: 2016-02-17 17:47 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/916ff9b5344f Merge Changeset: ee0479fc6af7 Author: xuelei Date: 2016-02-18 02:36 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ee0479fc6af7 8139565: Restrict certificates with DSA keys less than 1024 bits Reviewed-by: mullan ! src/java.base/share/classes/sun/security/util/KeyUtil.java ! src/java.base/share/conf/security/java.security + test/javax/net/ssl/TLSv12/DisabledShortDSAKeys.java Changeset: 8a863dbcfe3c Author: xuelei Date: 2016-02-18 02:49 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8a863dbcfe3c 8148500: [Spec] Enabled SSL Protocols may not be used Reviewed-by: mullan, jnimeh ! src/java.base/share/classes/javax/net/ssl/SSLEngine.java ! src/java.base/share/classes/javax/net/ssl/SSLServerSocket.java ! src/java.base/share/classes/javax/net/ssl/SSLSocket.java Changeset: 95a151d4f235 Author: rriggs Date: 2016-02-18 14:44 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/95a151d4f235 8149750: Decouple sun.misc.Signal from the base module Reviewed-by: chegar, dholmes ! make/mapfiles/libjava/mapfile-vers ! make/mapfiles/libjava/reorder-sparc ! make/mapfiles/libjava/reorder-sparcv9 ! make/mapfiles/libjava/reorder-x86 + src/java.base/share/classes/jdk/internal/misc/Signal.java - src/java.base/share/classes/sun/misc/NativeSignalHandler.java ! src/java.base/share/classes/sun/misc/Signal.java ! src/java.base/share/classes/sun/misc/SignalHandler.java - src/java.base/share/native/libjava/NativeSignalHandler.c ! src/java.base/share/native/libjava/Signal.c ! src/java.base/unix/classes/java/lang/Terminator.java ! src/java.base/windows/classes/java/lang/Terminator.java + test/sun/misc/SunMiscSignalTest.java Changeset: 48699da559b8 Author: lana Date: 2016-02-18 13:41 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/48699da559b8 Merge - make/src/classes/build/tools/buildmetaindex/BuildMetaIndex.java - src/java.base/share/classes/sun/misc/MetaIndex.java - src/java.base/share/classes/sun/misc/NativeSignalHandler.java - src/java.base/share/native/libjava/NativeSignalHandler.c Changeset: 931cd3a9299c Author: chegar Date: 2016-02-19 07:55 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/931cd3a9299c 8150168: jconsole AboutDialog should use the JDK specific Version API Reviewed-by: alanb, iris ! src/jdk.jconsole/share/classes/sun/tools/jconsole/AboutDialog.java Changeset: 6883aaee7364 Author: chegar Date: 2016-02-19 07:56 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6883aaee7364 8150163: JarFileSystem support for MRJARs should use the JDK specific Version API Reviewed-by: alanb, iris, sherman ! src/jdk.zipfs/share/classes/jdk/nio/zipfs/JarFileSystem.java ! test/jdk/nio/zipfs/MultiReleaseJarTest.java Changeset: 0ca3d19886e2 Author: jbachorik Date: 2015-12-28 12:16 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0ca3d19886e2 8145919: sun/management/jmxremote/bootstrap/RmiSslBootstrapTest failed with Connection failed for no credentials Reviewed-by: dfuchs ! test/ProblemList.txt ! test/sun/management/jmxremote/bootstrap/management_ssltest07_ok.properties.in + test/sun/management/jmxremote/bootstrap/ssl/Readme.txt ! test/sun/management/jmxremote/bootstrap/ssl/keystore ! test/sun/management/jmxremote/bootstrap/ssl/truststore Changeset: 16b6642062ee Author: naoto Date: 2016-02-19 09:55 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/16b6642062ee 8148346: Reduce number of packages in jdk.localedata module Reviewed-by: okutsu, alanb ! make/gendata/GendataBreakIterator.gmk ! make/src/classes/build/tools/cldrconverter/CLDRConverter.java ! make/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java - make/src/classes/build/tools/generatebreakiteratordata/BreakIteratorRBControl.java ! make/src/classes/build/tools/generatebreakiteratordata/GenerateBreakIteratorData.java + src/java.base/share/classes/sun/text/resources/FormatData_en.java + src/java.base/share/classes/sun/text/resources/FormatData_en_US.java + src/java.base/share/classes/sun/text/resources/JavaTimeSupplementary_en.java - src/java.base/share/classes/sun/text/resources/en/FormatData_en.java - src/java.base/share/classes/sun/text/resources/en/JavaTimeSupplementary_en.java - src/java.base/share/classes/sun/text/resources/en/US/FormatData_en_US.java + src/java.base/share/classes/sun/util/resources/CalendarData_en.properties + src/java.base/share/classes/sun/util/resources/CurrencyNames_en_US.properties ! src/java.base/share/classes/sun/util/resources/LocaleData.java + src/java.base/share/classes/sun/util/resources/LocaleNames_en.properties + src/java.base/share/classes/sun/util/resources/TimeZoneNames_en.java - src/java.base/share/classes/sun/util/resources/en/CalendarData_en.properties - src/java.base/share/classes/sun/util/resources/en/LocaleNames_en.properties - src/java.base/share/classes/sun/util/resources/en/TimeZoneNames_en.java - src/java.base/share/classes/sun/util/resources/en/US/CurrencyNames_en_US.properties - src/jdk.localedata/share/classes/sun/text/resources/ar/CollationData_ar.java - src/jdk.localedata/share/classes/sun/text/resources/ar/FormatData_ar.java - src/jdk.localedata/share/classes/sun/text/resources/ar/JO/FormatData_ar_JO.java - src/jdk.localedata/share/classes/sun/text/resources/ar/JO/JavaTimeSupplementary_ar_JO.java - src/jdk.localedata/share/classes/sun/text/resources/ar/JavaTimeSupplementary_ar.java - src/jdk.localedata/share/classes/sun/text/resources/ar/LB/FormatData_ar_LB.java - src/jdk.localedata/share/classes/sun/text/resources/ar/LB/JavaTimeSupplementary_ar_LB.java - src/jdk.localedata/share/classes/sun/text/resources/ar/SY/FormatData_ar_SY.java - src/jdk.localedata/share/classes/sun/text/resources/ar/SY/JavaTimeSupplementary_ar_SY.java - src/jdk.localedata/share/classes/sun/text/resources/be/BY/FormatData_be_BY.java - src/jdk.localedata/share/classes/sun/text/resources/be/CollationData_be.java - src/jdk.localedata/share/classes/sun/text/resources/be/FormatData_be.java - src/jdk.localedata/share/classes/sun/text/resources/be/JavaTimeSupplementary_be.java - src/jdk.localedata/share/classes/sun/text/resources/bg/BG/FormatData_bg_BG.java - src/jdk.localedata/share/classes/sun/text/resources/bg/CollationData_bg.java - src/jdk.localedata/share/classes/sun/text/resources/bg/FormatData_bg.java - src/jdk.localedata/share/classes/sun/text/resources/bg/JavaTimeSupplementary_bg.java - src/jdk.localedata/share/classes/sun/text/resources/ca/CollationData_ca.java - src/jdk.localedata/share/classes/sun/text/resources/ca/ES/FormatData_ca_ES.java - src/jdk.localedata/share/classes/sun/text/resources/ca/FormatData_ca.java - src/jdk.localedata/share/classes/sun/text/resources/ca/JavaTimeSupplementary_ca.java - src/jdk.localedata/share/classes/sun/text/resources/cs/CZ/FormatData_cs_CZ.java - src/jdk.localedata/share/classes/sun/text/resources/cs/CollationData_cs.java - src/jdk.localedata/share/classes/sun/text/resources/cs/FormatData_cs.java - src/jdk.localedata/share/classes/sun/text/resources/cs/JavaTimeSupplementary_cs.java - src/jdk.localedata/share/classes/sun/text/resources/da/CollationData_da.java - src/jdk.localedata/share/classes/sun/text/resources/da/DK/FormatData_da_DK.java - src/jdk.localedata/share/classes/sun/text/resources/da/FormatData_da.java - src/jdk.localedata/share/classes/sun/text/resources/da/JavaTimeSupplementary_da.java - src/jdk.localedata/share/classes/sun/text/resources/de/AT/FormatData_de_AT.java - src/jdk.localedata/share/classes/sun/text/resources/de/AT/JavaTimeSupplementary_de_AT.java - src/jdk.localedata/share/classes/sun/text/resources/de/CH/FormatData_de_CH.java - src/jdk.localedata/share/classes/sun/text/resources/de/DE/FormatData_de_DE.java - src/jdk.localedata/share/classes/sun/text/resources/de/FormatData_de.java - src/jdk.localedata/share/classes/sun/text/resources/de/JavaTimeSupplementary_de.java - src/jdk.localedata/share/classes/sun/text/resources/de/LU/FormatData_de_LU.java - src/jdk.localedata/share/classes/sun/text/resources/el/CY/FormatData_el_CY.java - src/jdk.localedata/share/classes/sun/text/resources/el/CollationData_el.java - src/jdk.localedata/share/classes/sun/text/resources/el/FormatData_el.java - src/jdk.localedata/share/classes/sun/text/resources/el/GR/FormatData_el_GR.java - src/jdk.localedata/share/classes/sun/text/resources/el/JavaTimeSupplementary_el.java - src/jdk.localedata/share/classes/sun/text/resources/en/AU/FormatData_en_AU.java - src/jdk.localedata/share/classes/sun/text/resources/en/AU/JavaTimeSupplementary_en_AU.java - src/jdk.localedata/share/classes/sun/text/resources/en/CA/FormatData_en_CA.java - src/jdk.localedata/share/classes/sun/text/resources/en/CA/JavaTimeSupplementary_en_CA.java - src/jdk.localedata/share/classes/sun/text/resources/en/GB/FormatData_en_GB.java - src/jdk.localedata/share/classes/sun/text/resources/en/GB/JavaTimeSupplementary_en_GB.java - src/jdk.localedata/share/classes/sun/text/resources/en/IE/FormatData_en_IE.java - src/jdk.localedata/share/classes/sun/text/resources/en/IE/JavaTimeSupplementary_en_IE.java - src/jdk.localedata/share/classes/sun/text/resources/en/IN/FormatData_en_IN.java - src/jdk.localedata/share/classes/sun/text/resources/en/IN/JavaTimeSupplementary_en_IN.java - src/jdk.localedata/share/classes/sun/text/resources/en/MT/FormatData_en_MT.java - src/jdk.localedata/share/classes/sun/text/resources/en/MT/JavaTimeSupplementary_en_MT.java - src/jdk.localedata/share/classes/sun/text/resources/en/NZ/FormatData_en_NZ.java - src/jdk.localedata/share/classes/sun/text/resources/en/NZ/JavaTimeSupplementary_en_NZ.java - src/jdk.localedata/share/classes/sun/text/resources/en/PH/FormatData_en_PH.java - src/jdk.localedata/share/classes/sun/text/resources/en/SG/FormatData_en_SG.java - src/jdk.localedata/share/classes/sun/text/resources/en/SG/JavaTimeSupplementary_en_SG.java - src/jdk.localedata/share/classes/sun/text/resources/en/ZA/FormatData_en_ZA.java - src/jdk.localedata/share/classes/sun/text/resources/en/ZA/JavaTimeSupplementary_en_ZA.java - src/jdk.localedata/share/classes/sun/text/resources/es/AR/FormatData_es_AR.java - src/jdk.localedata/share/classes/sun/text/resources/es/BO/FormatData_es_BO.java - src/jdk.localedata/share/classes/sun/text/resources/es/CL/FormatData_es_CL.java - src/jdk.localedata/share/classes/sun/text/resources/es/CL/JavaTimeSupplementary_es_CL.java - src/jdk.localedata/share/classes/sun/text/resources/es/CO/FormatData_es_CO.java - src/jdk.localedata/share/classes/sun/text/resources/es/CO/JavaTimeSupplementary_es_CO.java - src/jdk.localedata/share/classes/sun/text/resources/es/CR/FormatData_es_CR.java - src/jdk.localedata/share/classes/sun/text/resources/es/CollationData_es.java - src/jdk.localedata/share/classes/sun/text/resources/es/DO/FormatData_es_DO.java - src/jdk.localedata/share/classes/sun/text/resources/es/EC/FormatData_es_EC.java - src/jdk.localedata/share/classes/sun/text/resources/es/ES/FormatData_es_ES.java - src/jdk.localedata/share/classes/sun/text/resources/es/FormatData_es.java - src/jdk.localedata/share/classes/sun/text/resources/es/GT/FormatData_es_GT.java - src/jdk.localedata/share/classes/sun/text/resources/es/GT/JavaTimeSupplementary_es_GT.java - src/jdk.localedata/share/classes/sun/text/resources/es/HN/FormatData_es_HN.java - src/jdk.localedata/share/classes/sun/text/resources/es/HN/JavaTimeSupplementary_es_HN.java - src/jdk.localedata/share/classes/sun/text/resources/es/JavaTimeSupplementary_es.java - src/jdk.localedata/share/classes/sun/text/resources/es/MX/FormatData_es_MX.java - src/jdk.localedata/share/classes/sun/text/resources/es/MX/JavaTimeSupplementary_es_MX.java - src/jdk.localedata/share/classes/sun/text/resources/es/NI/FormatData_es_NI.java - src/jdk.localedata/share/classes/sun/text/resources/es/PA/FormatData_es_PA.java - src/jdk.localedata/share/classes/sun/text/resources/es/PA/JavaTimeSupplementary_es_PA.java - src/jdk.localedata/share/classes/sun/text/resources/es/PE/FormatData_es_PE.java - src/jdk.localedata/share/classes/sun/text/resources/es/PE/JavaTimeSupplementary_es_PE.java - src/jdk.localedata/share/classes/sun/text/resources/es/PR/FormatData_es_PR.java - src/jdk.localedata/share/classes/sun/text/resources/es/PR/JavaTimeSupplementary_es_PR.java - src/jdk.localedata/share/classes/sun/text/resources/es/PY/FormatData_es_PY.java - src/jdk.localedata/share/classes/sun/text/resources/es/SV/FormatData_es_SV.java - src/jdk.localedata/share/classes/sun/text/resources/es/US/FormatData_es_US.java - src/jdk.localedata/share/classes/sun/text/resources/es/UY/FormatData_es_UY.java - src/jdk.localedata/share/classes/sun/text/resources/es/UY/JavaTimeSupplementary_es_UY.java - src/jdk.localedata/share/classes/sun/text/resources/es/VE/FormatData_es_VE.java - src/jdk.localedata/share/classes/sun/text/resources/et/CollationData_et.java - src/jdk.localedata/share/classes/sun/text/resources/et/EE/FormatData_et_EE.java - src/jdk.localedata/share/classes/sun/text/resources/et/FormatData_et.java - src/jdk.localedata/share/classes/sun/text/resources/et/JavaTimeSupplementary_et.java + src/jdk.localedata/share/classes/sun/text/resources/ext/BreakIteratorInfo_th.java + src/jdk.localedata/share/classes/sun/text/resources/ext/BreakIteratorRules_th.java + src/jdk.localedata/share/classes/sun/text/resources/ext/CollationData_ar.java + src/jdk.localedata/share/classes/sun/text/resources/ext/CollationData_be.java + src/jdk.localedata/share/classes/sun/text/resources/ext/CollationData_bg.java + src/jdk.localedata/share/classes/sun/text/resources/ext/CollationData_ca.java + src/jdk.localedata/share/classes/sun/text/resources/ext/CollationData_cs.java + src/jdk.localedata/share/classes/sun/text/resources/ext/CollationData_da.java + src/jdk.localedata/share/classes/sun/text/resources/ext/CollationData_el.java + src/jdk.localedata/share/classes/sun/text/resources/ext/CollationData_es.java + src/jdk.localedata/share/classes/sun/text/resources/ext/CollationData_et.java + src/jdk.localedata/share/classes/sun/text/resources/ext/CollationData_fi.java + src/jdk.localedata/share/classes/sun/text/resources/ext/CollationData_fr.java + src/jdk.localedata/share/classes/sun/text/resources/ext/CollationData_hi.java + src/jdk.localedata/share/classes/sun/text/resources/ext/CollationData_hr.java + src/jdk.localedata/share/classes/sun/text/resources/ext/CollationData_hu.java + src/jdk.localedata/share/classes/sun/text/resources/ext/CollationData_is.java + src/jdk.localedata/share/classes/sun/text/resources/ext/CollationData_iw.java + src/jdk.localedata/share/classes/sun/text/resources/ext/CollationData_ja.java + src/jdk.localedata/share/classes/sun/text/resources/ext/CollationData_ko.java + src/jdk.localedata/share/classes/sun/text/resources/ext/CollationData_lt.java + src/jdk.localedata/share/classes/sun/text/resources/ext/CollationData_lv.java + src/jdk.localedata/share/classes/sun/text/resources/ext/CollationData_mk.java + src/jdk.localedata/share/classes/sun/text/resources/ext/CollationData_no.java + src/jdk.localedata/share/classes/sun/text/resources/ext/CollationData_pl.java + src/jdk.localedata/share/classes/sun/text/resources/ext/CollationData_ro.java + src/jdk.localedata/share/classes/sun/text/resources/ext/CollationData_ru.java + src/jdk.localedata/share/classes/sun/text/resources/ext/CollationData_sk.java + src/jdk.localedata/share/classes/sun/text/resources/ext/CollationData_sl.java + src/jdk.localedata/share/classes/sun/text/resources/ext/CollationData_sq.java + src/jdk.localedata/share/classes/sun/text/resources/ext/CollationData_sr.java + src/jdk.localedata/share/classes/sun/text/resources/ext/CollationData_sr_Latn.java + src/jdk.localedata/share/classes/sun/text/resources/ext/CollationData_sv.java + src/jdk.localedata/share/classes/sun/text/resources/ext/CollationData_th.java + src/jdk.localedata/share/classes/sun/text/resources/ext/CollationData_tr.java + src/jdk.localedata/share/classes/sun/text/resources/ext/CollationData_uk.java + src/jdk.localedata/share/classes/sun/text/resources/ext/CollationData_vi.java + src/jdk.localedata/share/classes/sun/text/resources/ext/CollationData_zh.java + src/jdk.localedata/share/classes/sun/text/resources/ext/CollationData_zh_HK.java + src/jdk.localedata/share/classes/sun/text/resources/ext/CollationData_zh_TW.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_ar.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_ar_JO.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_ar_LB.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_ar_SY.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_be.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_be_BY.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_bg.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_bg_BG.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_ca.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_ca_ES.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_cs.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_cs_CZ.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_da.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_da_DK.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_de.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_de_AT.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_de_CH.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_de_DE.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_de_LU.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_el.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_el_CY.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_el_GR.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_en_AU.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_en_CA.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_en_GB.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_en_IE.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_en_IN.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_en_MT.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_en_NZ.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_en_PH.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_en_SG.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_en_ZA.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_es.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_es_AR.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_es_BO.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_es_CL.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_es_CO.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_es_CR.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_es_DO.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_es_EC.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_es_ES.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_es_GT.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_es_HN.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_es_MX.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_es_NI.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_es_PA.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_es_PE.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_es_PR.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_es_PY.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_es_SV.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_es_US.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_es_UY.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_es_VE.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_et.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_et_EE.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_fi.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_fi_FI.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_fr.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_fr_BE.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_fr_CA.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_fr_CH.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_fr_FR.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_ga.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_ga_IE.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_hi_IN.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_hr.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_hr_HR.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_hu.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_hu_HU.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_in.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_in_ID.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_is.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_is_IS.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_it.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_it_CH.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_it_IT.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_iw.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_iw_IL.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_ja.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_ja_JP.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_ko.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_ko_KR.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_lt.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_lt_LT.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_lv.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_lv_LV.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_mk.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_mk_MK.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_ms.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_ms_MY.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_mt.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_mt_MT.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_nl.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_nl_BE.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_nl_NL.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_no.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_no_NO.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_no_NO_NY.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_pl.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_pl_PL.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_pt.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_pt_BR.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_pt_PT.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_ro.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_ro_RO.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_ru.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_ru_RU.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_sk.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_sk_SK.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_sl.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_sl_SI.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_sq.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_sq_AL.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_sr.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_sr_BA.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_sr_CS.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_sr_Latn.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_sr_Latn_ME.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_sr_ME.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_sr_RS.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_sv.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_sv_SE.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_th.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_th_TH.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_tr.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_tr_TR.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_uk.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_uk_UA.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_vi.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_vi_VN.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_zh.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_zh_CN.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_zh_HK.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_zh_SG.java + src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_zh_TW.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_ar.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_ar_JO.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_ar_LB.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_ar_SY.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_be.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_bg.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_ca.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_cs.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_da.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_de.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_de_AT.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_el.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_en_AU.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_en_CA.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_en_GB.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_en_IE.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_en_IN.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_en_MT.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_en_NZ.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_en_SG.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_en_ZA.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_es.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_es_CL.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_es_CO.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_es_GT.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_es_HN.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_es_MX.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_es_PA.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_es_PE.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_es_PR.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_es_UY.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_et.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_fi.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_fr.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_fr_BE.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_fr_CA.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_fr_CH.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_ga.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_hi_IN.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_hr.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_hu.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_is.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_it.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_it_CH.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_iw.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_iw_IL.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_ja.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_ko.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_lt.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_lv.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_mk.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_ms.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_mt.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_nl.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_nl_BE.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_no.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_pl.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_pt.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_pt_PT.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_ro.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_ru.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_sk.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_sl.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_sq.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_sr.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_sr_Latn.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_sv.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_th.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_tr.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_uk.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_vi.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_zh.java + src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_zh_TW.java - src/jdk.localedata/share/classes/sun/text/resources/fi/CollationData_fi.java - src/jdk.localedata/share/classes/sun/text/resources/fi/FI/FormatData_fi_FI.java - src/jdk.localedata/share/classes/sun/text/resources/fi/FormatData_fi.java - src/jdk.localedata/share/classes/sun/text/resources/fi/JavaTimeSupplementary_fi.java - src/jdk.localedata/share/classes/sun/text/resources/fr/BE/FormatData_fr_BE.java - src/jdk.localedata/share/classes/sun/text/resources/fr/BE/JavaTimeSupplementary_fr_BE.java - src/jdk.localedata/share/classes/sun/text/resources/fr/CA/FormatData_fr_CA.java - src/jdk.localedata/share/classes/sun/text/resources/fr/CA/JavaTimeSupplementary_fr_CA.java - src/jdk.localedata/share/classes/sun/text/resources/fr/CH/FormatData_fr_CH.java - src/jdk.localedata/share/classes/sun/text/resources/fr/CH/JavaTimeSupplementary_fr_CH.java - src/jdk.localedata/share/classes/sun/text/resources/fr/CollationData_fr.java - src/jdk.localedata/share/classes/sun/text/resources/fr/FR/FormatData_fr_FR.java - src/jdk.localedata/share/classes/sun/text/resources/fr/FormatData_fr.java - src/jdk.localedata/share/classes/sun/text/resources/fr/JavaTimeSupplementary_fr.java - src/jdk.localedata/share/classes/sun/text/resources/ga/FormatData_ga.java - src/jdk.localedata/share/classes/sun/text/resources/ga/IE/FormatData_ga_IE.java - src/jdk.localedata/share/classes/sun/text/resources/ga/JavaTimeSupplementary_ga.java - src/jdk.localedata/share/classes/sun/text/resources/hi/CollationData_hi.java - src/jdk.localedata/share/classes/sun/text/resources/hi/IN/FormatData_hi_IN.java - src/jdk.localedata/share/classes/sun/text/resources/hi/IN/JavaTimeSupplementary_hi_IN.java - src/jdk.localedata/share/classes/sun/text/resources/hr/CollationData_hr.java - src/jdk.localedata/share/classes/sun/text/resources/hr/FormatData_hr.java - src/jdk.localedata/share/classes/sun/text/resources/hr/HR/FormatData_hr_HR.java - src/jdk.localedata/share/classes/sun/text/resources/hr/JavaTimeSupplementary_hr.java - src/jdk.localedata/share/classes/sun/text/resources/hu/CollationData_hu.java - src/jdk.localedata/share/classes/sun/text/resources/hu/FormatData_hu.java - src/jdk.localedata/share/classes/sun/text/resources/hu/HU/FormatData_hu_HU.java - src/jdk.localedata/share/classes/sun/text/resources/hu/JavaTimeSupplementary_hu.java - src/jdk.localedata/share/classes/sun/text/resources/in/FormatData_in.java - src/jdk.localedata/share/classes/sun/text/resources/in/ID/FormatData_in_ID.java - src/jdk.localedata/share/classes/sun/text/resources/is/CollationData_is.java - src/jdk.localedata/share/classes/sun/text/resources/is/FormatData_is.java - src/jdk.localedata/share/classes/sun/text/resources/is/IS/FormatData_is_IS.java - src/jdk.localedata/share/classes/sun/text/resources/is/JavaTimeSupplementary_is.java - src/jdk.localedata/share/classes/sun/text/resources/it/CH/FormatData_it_CH.java - src/jdk.localedata/share/classes/sun/text/resources/it/CH/JavaTimeSupplementary_it_CH.java - src/jdk.localedata/share/classes/sun/text/resources/it/FormatData_it.java - src/jdk.localedata/share/classes/sun/text/resources/it/IT/FormatData_it_IT.java - src/jdk.localedata/share/classes/sun/text/resources/it/JavaTimeSupplementary_it.java - src/jdk.localedata/share/classes/sun/text/resources/iw/CollationData_iw.java - src/jdk.localedata/share/classes/sun/text/resources/iw/FormatData_iw.java - src/jdk.localedata/share/classes/sun/text/resources/iw/IL/FormatData_iw_IL.java - src/jdk.localedata/share/classes/sun/text/resources/iw/IL/JavaTimeSupplementary_iw_IL.java - src/jdk.localedata/share/classes/sun/text/resources/iw/JavaTimeSupplementary_iw.java - src/jdk.localedata/share/classes/sun/text/resources/ja/CollationData_ja.java - src/jdk.localedata/share/classes/sun/text/resources/ja/FormatData_ja.java - src/jdk.localedata/share/classes/sun/text/resources/ja/JP/FormatData_ja_JP.java - src/jdk.localedata/share/classes/sun/text/resources/ja/JavaTimeSupplementary_ja.java - src/jdk.localedata/share/classes/sun/text/resources/ko/CollationData_ko.java - src/jdk.localedata/share/classes/sun/text/resources/ko/FormatData_ko.java - src/jdk.localedata/share/classes/sun/text/resources/ko/JavaTimeSupplementary_ko.java - src/jdk.localedata/share/classes/sun/text/resources/ko/KR/FormatData_ko_KR.java - src/jdk.localedata/share/classes/sun/text/resources/lt/CollationData_lt.java - src/jdk.localedata/share/classes/sun/text/resources/lt/FormatData_lt.java - src/jdk.localedata/share/classes/sun/text/resources/lt/JavaTimeSupplementary_lt.java - src/jdk.localedata/share/classes/sun/text/resources/lt/LT/FormatData_lt_LT.java - src/jdk.localedata/share/classes/sun/text/resources/lv/CollationData_lv.java - src/jdk.localedata/share/classes/sun/text/resources/lv/FormatData_lv.java - src/jdk.localedata/share/classes/sun/text/resources/lv/JavaTimeSupplementary_lv.java - src/jdk.localedata/share/classes/sun/text/resources/lv/LV/FormatData_lv_LV.java - src/jdk.localedata/share/classes/sun/text/resources/mk/CollationData_mk.java - src/jdk.localedata/share/classes/sun/text/resources/mk/FormatData_mk.java - src/jdk.localedata/share/classes/sun/text/resources/mk/JavaTimeSupplementary_mk.java - src/jdk.localedata/share/classes/sun/text/resources/mk/MK/FormatData_mk_MK.java - src/jdk.localedata/share/classes/sun/text/resources/ms/FormatData_ms.java - src/jdk.localedata/share/classes/sun/text/resources/ms/JavaTimeSupplementary_ms.java - src/jdk.localedata/share/classes/sun/text/resources/ms/MY/FormatData_ms_MY.java - src/jdk.localedata/share/classes/sun/text/resources/mt/FormatData_mt.java - src/jdk.localedata/share/classes/sun/text/resources/mt/JavaTimeSupplementary_mt.java - src/jdk.localedata/share/classes/sun/text/resources/mt/MT/FormatData_mt_MT.java - src/jdk.localedata/share/classes/sun/text/resources/nl/BE/FormatData_nl_BE.java - src/jdk.localedata/share/classes/sun/text/resources/nl/BE/JavaTimeSupplementary_nl_BE.java - src/jdk.localedata/share/classes/sun/text/resources/nl/FormatData_nl.java - src/jdk.localedata/share/classes/sun/text/resources/nl/JavaTimeSupplementary_nl.java - src/jdk.localedata/share/classes/sun/text/resources/nl/NL/FormatData_nl_NL.java - src/jdk.localedata/share/classes/sun/text/resources/no/CollationData_no.java - src/jdk.localedata/share/classes/sun/text/resources/no/FormatData_no.java - src/jdk.localedata/share/classes/sun/text/resources/no/JavaTimeSupplementary_no.java - src/jdk.localedata/share/classes/sun/text/resources/no/NO/FormatData_no_NO.java - src/jdk.localedata/share/classes/sun/text/resources/no/NO/FormatData_no_NO_NY.java - src/jdk.localedata/share/classes/sun/text/resources/pl/CollationData_pl.java - src/jdk.localedata/share/classes/sun/text/resources/pl/FormatData_pl.java - src/jdk.localedata/share/classes/sun/text/resources/pl/JavaTimeSupplementary_pl.java - src/jdk.localedata/share/classes/sun/text/resources/pl/PL/FormatData_pl_PL.java - src/jdk.localedata/share/classes/sun/text/resources/pt/BR/FormatData_pt_BR.java - src/jdk.localedata/share/classes/sun/text/resources/pt/FormatData_pt.java - src/jdk.localedata/share/classes/sun/text/resources/pt/JavaTimeSupplementary_pt.java - src/jdk.localedata/share/classes/sun/text/resources/pt/PT/FormatData_pt_PT.java - src/jdk.localedata/share/classes/sun/text/resources/pt/PT/JavaTimeSupplementary_pt_PT.java - src/jdk.localedata/share/classes/sun/text/resources/ro/CollationData_ro.java - src/jdk.localedata/share/classes/sun/text/resources/ro/FormatData_ro.java - src/jdk.localedata/share/classes/sun/text/resources/ro/JavaTimeSupplementary_ro.java - src/jdk.localedata/share/classes/sun/text/resources/ro/RO/FormatData_ro_RO.java - src/jdk.localedata/share/classes/sun/text/resources/ru/CollationData_ru.java - src/jdk.localedata/share/classes/sun/text/resources/ru/FormatData_ru.java - src/jdk.localedata/share/classes/sun/text/resources/ru/JavaTimeSupplementary_ru.java - src/jdk.localedata/share/classes/sun/text/resources/ru/RU/FormatData_ru_RU.java - src/jdk.localedata/share/classes/sun/text/resources/sk/CollationData_sk.java - src/jdk.localedata/share/classes/sun/text/resources/sk/FormatData_sk.java - src/jdk.localedata/share/classes/sun/text/resources/sk/JavaTimeSupplementary_sk.java - src/jdk.localedata/share/classes/sun/text/resources/sk/SK/FormatData_sk_SK.java - src/jdk.localedata/share/classes/sun/text/resources/sl/CollationData_sl.java - src/jdk.localedata/share/classes/sun/text/resources/sl/FormatData_sl.java - src/jdk.localedata/share/classes/sun/text/resources/sl/JavaTimeSupplementary_sl.java - src/jdk.localedata/share/classes/sun/text/resources/sl/SI/FormatData_sl_SI.java - src/jdk.localedata/share/classes/sun/text/resources/sq/AL/FormatData_sq_AL.java - src/jdk.localedata/share/classes/sun/text/resources/sq/CollationData_sq.java - src/jdk.localedata/share/classes/sun/text/resources/sq/FormatData_sq.java - src/jdk.localedata/share/classes/sun/text/resources/sq/JavaTimeSupplementary_sq.java - src/jdk.localedata/share/classes/sun/text/resources/sr/BA/FormatData_sr_BA.java - src/jdk.localedata/share/classes/sun/text/resources/sr/CS/FormatData_sr_CS.java - src/jdk.localedata/share/classes/sun/text/resources/sr/CollationData_sr.java - src/jdk.localedata/share/classes/sun/text/resources/sr/CollationData_sr_Latn.java - src/jdk.localedata/share/classes/sun/text/resources/sr/FormatData_sr.java - src/jdk.localedata/share/classes/sun/text/resources/sr/FormatData_sr_Latn.java - src/jdk.localedata/share/classes/sun/text/resources/sr/JavaTimeSupplementary_sr.java - src/jdk.localedata/share/classes/sun/text/resources/sr/JavaTimeSupplementary_sr_Latn.java - src/jdk.localedata/share/classes/sun/text/resources/sr/ME/FormatData_sr_Latn_ME.java - src/jdk.localedata/share/classes/sun/text/resources/sr/ME/FormatData_sr_ME.java - src/jdk.localedata/share/classes/sun/text/resources/sr/RS/FormatData_sr_RS.java - src/jdk.localedata/share/classes/sun/text/resources/sv/CollationData_sv.java - src/jdk.localedata/share/classes/sun/text/resources/sv/FormatData_sv.java - src/jdk.localedata/share/classes/sun/text/resources/sv/JavaTimeSupplementary_sv.java - src/jdk.localedata/share/classes/sun/text/resources/sv/SE/FormatData_sv_SE.java - src/jdk.localedata/share/classes/sun/text/resources/th/BreakIteratorInfo_th.java - src/jdk.localedata/share/classes/sun/text/resources/th/BreakIteratorRules_th.java - src/jdk.localedata/share/classes/sun/text/resources/th/CollationData_th.java - src/jdk.localedata/share/classes/sun/text/resources/th/FormatData_th.java - src/jdk.localedata/share/classes/sun/text/resources/th/JavaTimeSupplementary_th.java - src/jdk.localedata/share/classes/sun/text/resources/th/TH/FormatData_th_TH.java - src/jdk.localedata/share/classes/sun/text/resources/th/thai_dict + src/jdk.localedata/share/classes/sun/text/resources/thai_dict - src/jdk.localedata/share/classes/sun/text/resources/tr/CollationData_tr.java - src/jdk.localedata/share/classes/sun/text/resources/tr/FormatData_tr.java - src/jdk.localedata/share/classes/sun/text/resources/tr/JavaTimeSupplementary_tr.java - src/jdk.localedata/share/classes/sun/text/resources/tr/TR/FormatData_tr_TR.java - src/jdk.localedata/share/classes/sun/text/resources/uk/CollationData_uk.java - src/jdk.localedata/share/classes/sun/text/resources/uk/FormatData_uk.java - src/jdk.localedata/share/classes/sun/text/resources/uk/JavaTimeSupplementary_uk.java - src/jdk.localedata/share/classes/sun/text/resources/uk/UA/FormatData_uk_UA.java - src/jdk.localedata/share/classes/sun/text/resources/vi/CollationData_vi.java - src/jdk.localedata/share/classes/sun/text/resources/vi/FormatData_vi.java - src/jdk.localedata/share/classes/sun/text/resources/vi/JavaTimeSupplementary_vi.java - src/jdk.localedata/share/classes/sun/text/resources/vi/VN/FormatData_vi_VN.java - src/jdk.localedata/share/classes/sun/text/resources/zh/CN/FormatData_zh_CN.java - src/jdk.localedata/share/classes/sun/text/resources/zh/CollationData_zh.java - src/jdk.localedata/share/classes/sun/text/resources/zh/FormatData_zh.java - src/jdk.localedata/share/classes/sun/text/resources/zh/HK/CollationData_zh_HK.java - src/jdk.localedata/share/classes/sun/text/resources/zh/HK/FormatData_zh_HK.java - src/jdk.localedata/share/classes/sun/text/resources/zh/JavaTimeSupplementary_zh.java - src/jdk.localedata/share/classes/sun/text/resources/zh/SG/FormatData_zh_SG.java - src/jdk.localedata/share/classes/sun/text/resources/zh/TW/CollationData_zh_TW.java - src/jdk.localedata/share/classes/sun/text/resources/zh/TW/FormatData_zh_TW.java - src/jdk.localedata/share/classes/sun/text/resources/zh/TW/JavaTimeSupplementary_zh_TW.java - src/jdk.localedata/share/classes/sun/util/resources/ar/AE/CurrencyNames_ar_AE.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/BH/CurrencyNames_ar_BH.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/CalendarData_ar.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/DZ/CurrencyNames_ar_DZ.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/EG/CurrencyNames_ar_EG.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/IQ/CurrencyNames_ar_IQ.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/JO/CurrencyNames_ar_JO.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/KW/CurrencyNames_ar_KW.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/LB/CurrencyNames_ar_LB.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/LY/CurrencyNames_ar_LY.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/LocaleNames_ar.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/MA/CurrencyNames_ar_MA.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/OM/CurrencyNames_ar_OM.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/QA/CurrencyNames_ar_QA.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/SA/CurrencyNames_ar_SA.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/SD/CurrencyNames_ar_SD.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/SY/CurrencyNames_ar_SY.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/TN/CurrencyNames_ar_TN.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/YE/CurrencyNames_ar_YE.properties - src/jdk.localedata/share/classes/sun/util/resources/be/BY/CurrencyNames_be_BY.properties - src/jdk.localedata/share/classes/sun/util/resources/be/CalendarData_be.properties - src/jdk.localedata/share/classes/sun/util/resources/be/LocaleNames_be.properties - src/jdk.localedata/share/classes/sun/util/resources/bg/BG/CurrencyNames_bg_BG.properties - src/jdk.localedata/share/classes/sun/util/resources/bg/CalendarData_bg.properties - src/jdk.localedata/share/classes/sun/util/resources/bg/LocaleNames_bg.properties - src/jdk.localedata/share/classes/sun/util/resources/ca/CalendarData_ca.properties - src/jdk.localedata/share/classes/sun/util/resources/ca/ES/CurrencyNames_ca_ES.properties - src/jdk.localedata/share/classes/sun/util/resources/ca/LocaleNames_ca.properties - src/jdk.localedata/share/classes/sun/util/resources/cs/CZ/CurrencyNames_cs_CZ.properties - src/jdk.localedata/share/classes/sun/util/resources/cs/CalendarData_cs.properties - src/jdk.localedata/share/classes/sun/util/resources/cs/LocaleNames_cs.properties - src/jdk.localedata/share/classes/sun/util/resources/da/CalendarData_da.properties - src/jdk.localedata/share/classes/sun/util/resources/da/DK/CurrencyNames_da_DK.properties - src/jdk.localedata/share/classes/sun/util/resources/da/LocaleNames_da.properties - src/jdk.localedata/share/classes/sun/util/resources/de/AT/CurrencyNames_de_AT.properties - src/jdk.localedata/share/classes/sun/util/resources/de/CH/CurrencyNames_de_CH.properties - src/jdk.localedata/share/classes/sun/util/resources/de/CalendarData_de.properties - src/jdk.localedata/share/classes/sun/util/resources/de/CurrencyNames_de.properties - src/jdk.localedata/share/classes/sun/util/resources/de/DE/CurrencyNames_de_DE.properties - src/jdk.localedata/share/classes/sun/util/resources/de/GR/CurrencyNames_de_GR.properties - src/jdk.localedata/share/classes/sun/util/resources/de/LU/CurrencyNames_de_LU.properties - src/jdk.localedata/share/classes/sun/util/resources/de/LocaleNames_de.properties - src/jdk.localedata/share/classes/sun/util/resources/de/TimeZoneNames_de.java - src/jdk.localedata/share/classes/sun/util/resources/el/CY/CalendarData_el_CY.properties - src/jdk.localedata/share/classes/sun/util/resources/el/CY/CurrencyNames_el_CY.properties - src/jdk.localedata/share/classes/sun/util/resources/el/CY/LocaleNames_el_CY.properties - src/jdk.localedata/share/classes/sun/util/resources/el/CalendarData_el.properties - src/jdk.localedata/share/classes/sun/util/resources/el/GR/CurrencyNames_el_GR.properties - src/jdk.localedata/share/classes/sun/util/resources/el/LocaleNames_el.properties - src/jdk.localedata/share/classes/sun/util/resources/en/AU/CurrencyNames_en_AU.properties - src/jdk.localedata/share/classes/sun/util/resources/en/CA/CurrencyNames_en_CA.properties - src/jdk.localedata/share/classes/sun/util/resources/en/CA/TimeZoneNames_en_CA.java - src/jdk.localedata/share/classes/sun/util/resources/en/GB/CalendarData_en_GB.properties - src/jdk.localedata/share/classes/sun/util/resources/en/GB/CurrencyNames_en_GB.properties - src/jdk.localedata/share/classes/sun/util/resources/en/GB/TimeZoneNames_en_GB.java - src/jdk.localedata/share/classes/sun/util/resources/en/IE/CalendarData_en_IE.properties - src/jdk.localedata/share/classes/sun/util/resources/en/IE/CurrencyNames_en_IE.properties - src/jdk.localedata/share/classes/sun/util/resources/en/IE/TimeZoneNames_en_IE.java - src/jdk.localedata/share/classes/sun/util/resources/en/IN/CurrencyNames_en_IN.properties - src/jdk.localedata/share/classes/sun/util/resources/en/MT/CalendarData_en_MT.properties - src/jdk.localedata/share/classes/sun/util/resources/en/MT/CurrencyNames_en_MT.properties - src/jdk.localedata/share/classes/sun/util/resources/en/MT/LocaleNames_en_MT.properties - src/jdk.localedata/share/classes/sun/util/resources/en/NZ/CurrencyNames_en_NZ.properties - src/jdk.localedata/share/classes/sun/util/resources/en/PH/CurrencyNames_en_PH.properties - src/jdk.localedata/share/classes/sun/util/resources/en/PH/LocaleNames_en_PH.properties - src/jdk.localedata/share/classes/sun/util/resources/en/SG/CurrencyNames_en_SG.properties - src/jdk.localedata/share/classes/sun/util/resources/en/SG/LocaleNames_en_SG.properties - src/jdk.localedata/share/classes/sun/util/resources/en/ZA/CurrencyNames_en_ZA.properties - src/jdk.localedata/share/classes/sun/util/resources/es/AR/CurrencyNames_es_AR.properties - src/jdk.localedata/share/classes/sun/util/resources/es/BO/CurrencyNames_es_BO.properties - src/jdk.localedata/share/classes/sun/util/resources/es/CL/CurrencyNames_es_CL.properties - src/jdk.localedata/share/classes/sun/util/resources/es/CO/CurrencyNames_es_CO.properties - src/jdk.localedata/share/classes/sun/util/resources/es/CR/CurrencyNames_es_CR.properties - src/jdk.localedata/share/classes/sun/util/resources/es/CU/CurrencyNames_es_CU.properties - src/jdk.localedata/share/classes/sun/util/resources/es/CalendarData_es.properties - src/jdk.localedata/share/classes/sun/util/resources/es/CurrencyNames_es.properties - src/jdk.localedata/share/classes/sun/util/resources/es/DO/CurrencyNames_es_DO.properties - src/jdk.localedata/share/classes/sun/util/resources/es/EC/CurrencyNames_es_EC.properties - src/jdk.localedata/share/classes/sun/util/resources/es/ES/CalendarData_es_ES.properties - src/jdk.localedata/share/classes/sun/util/resources/es/ES/CurrencyNames_es_ES.properties - src/jdk.localedata/share/classes/sun/util/resources/es/GT/CurrencyNames_es_GT.properties - src/jdk.localedata/share/classes/sun/util/resources/es/HN/CurrencyNames_es_HN.properties - src/jdk.localedata/share/classes/sun/util/resources/es/LocaleNames_es.properties - src/jdk.localedata/share/classes/sun/util/resources/es/MX/CurrencyNames_es_MX.properties - src/jdk.localedata/share/classes/sun/util/resources/es/NI/CurrencyNames_es_NI.properties - src/jdk.localedata/share/classes/sun/util/resources/es/PA/CurrencyNames_es_PA.properties - src/jdk.localedata/share/classes/sun/util/resources/es/PE/CurrencyNames_es_PE.properties - src/jdk.localedata/share/classes/sun/util/resources/es/PR/CurrencyNames_es_PR.properties - src/jdk.localedata/share/classes/sun/util/resources/es/PY/CurrencyNames_es_PY.properties - src/jdk.localedata/share/classes/sun/util/resources/es/SV/CurrencyNames_es_SV.properties - src/jdk.localedata/share/classes/sun/util/resources/es/TimeZoneNames_es.java - src/jdk.localedata/share/classes/sun/util/resources/es/US/CalendarData_es_US.properties - src/jdk.localedata/share/classes/sun/util/resources/es/US/CurrencyNames_es_US.properties - src/jdk.localedata/share/classes/sun/util/resources/es/US/LocaleNames_es_US.properties - src/jdk.localedata/share/classes/sun/util/resources/es/UY/CurrencyNames_es_UY.properties - src/jdk.localedata/share/classes/sun/util/resources/es/VE/CurrencyNames_es_VE.properties - src/jdk.localedata/share/classes/sun/util/resources/et/CalendarData_et.properties - src/jdk.localedata/share/classes/sun/util/resources/et/EE/CurrencyNames_et_EE.properties - src/jdk.localedata/share/classes/sun/util/resources/et/LocaleNames_et.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_ar.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_be.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_bg.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_ca.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_cs.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_da.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_de.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_el.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_el_CY.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_en_GB.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_en_IE.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_en_MT.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_es.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_es_ES.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_es_US.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_et.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_fi.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_fr.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_fr_CA.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_hi.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_hr.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_hu.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_in_ID.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_is.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_it.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_iw.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_ja.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_ko.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_lt.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_lv.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_mk.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_ms_MY.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_mt.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_mt_MT.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_nl.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_no.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_pl.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_pt.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_pt_BR.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_pt_PT.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_ro.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_ru.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_sk.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_sl.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_sq.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_sr.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_sr_Latn_BA.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_sr_Latn_ME.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_sr_Latn_RS.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_sv.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_th.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_tr.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_uk.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_vi.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_zh.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_AE.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_BH.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_DZ.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_EG.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_IQ.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_JO.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_KW.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_LB.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_LY.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_MA.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_OM.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_QA.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_SA.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_SD.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_SY.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_TN.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_YE.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_be_BY.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_bg_BG.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ca_ES.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_cs_CZ.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_da_DK.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_de.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_de_AT.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_de_CH.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_de_DE.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_de_GR.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_de_LU.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_el_CY.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_el_GR.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_en_AU.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_en_CA.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_en_GB.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_en_IE.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_en_IN.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_en_MT.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_en_NZ.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_en_PH.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_en_SG.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_en_ZA.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_AR.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_BO.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_CL.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_CO.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_CR.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_CU.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_DO.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_EC.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_ES.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_GT.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_HN.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_MX.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_NI.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_PA.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_PE.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_PR.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_PY.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_SV.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_US.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_UY.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_VE.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_et_EE.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_fi_FI.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_fr.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_fr_BE.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_fr_CA.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_fr_CH.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_fr_FR.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_fr_LU.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ga_IE.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_hi_IN.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_hr_HR.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_hu_HU.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_in_ID.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_is_IS.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_it.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_it_CH.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_it_IT.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_iw_IL.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ja.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ja_JP.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ko.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ko_KR.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_lt_LT.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_lv_LV.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_mk_MK.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ms_MY.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_mt_MT.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_nl_BE.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_nl_NL.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_no_NO.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_pl_PL.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_pt.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_pt_BR.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_pt_PT.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ro_RO.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ru_RU.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_sk_SK.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_sl_SI.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_sq_AL.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_sr_BA.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_sr_CS.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_sr_Latn_BA.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_sr_Latn_ME.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_sr_Latn_RS.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_sr_ME.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_sr_RS.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_sv.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_sv_SE.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_th_TH.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_tr_TR.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_uk_UA.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_vi_VN.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_zh_CN.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_zh_HK.java + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_zh_SG.java + src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_zh_TW.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_ar.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_be.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_bg.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_ca.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_cs.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_da.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_de.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_el.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_el_CY.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_en_MT.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_en_PH.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_en_SG.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_es.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_es_US.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_et.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_fi.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_fr.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_ga.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_hi.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_hr.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_hu.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_in.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_is.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_it.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_iw.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_ja.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_ko.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_lt.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_lv.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_mk.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_ms.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_mt.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_nl.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_no.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_no_NO_NY.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_pl.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_pt.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_pt_BR.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_pt_PT.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_ro.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_ru.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_sk.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_sl.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_sq.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_sr.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_sr_Latn.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_sv.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_th.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_tr.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_uk.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_vi.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_zh.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_zh_HK.java + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_zh_SG.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_zh_TW.properties + src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_de.java + src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_en_CA.java + src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_en_GB.java + src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_en_IE.java + src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_es.java + src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_fr.java + src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_hi.java + src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_it.java + src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_ja.java + src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_ko.java + src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_pt_BR.java + src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_sv.java + src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_zh_CN.java + src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_zh_HK.java + src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_zh_TW.java - src/jdk.localedata/share/classes/sun/util/resources/fi/CalendarData_fi.properties - src/jdk.localedata/share/classes/sun/util/resources/fi/FI/CurrencyNames_fi_FI.properties - src/jdk.localedata/share/classes/sun/util/resources/fi/LocaleNames_fi.properties - src/jdk.localedata/share/classes/sun/util/resources/fr/BE/CurrencyNames_fr_BE.properties - src/jdk.localedata/share/classes/sun/util/resources/fr/CA/CalendarData_fr_CA.properties - src/jdk.localedata/share/classes/sun/util/resources/fr/CA/CurrencyNames_fr_CA.properties - src/jdk.localedata/share/classes/sun/util/resources/fr/CH/CurrencyNames_fr_CH.properties - src/jdk.localedata/share/classes/sun/util/resources/fr/CalendarData_fr.properties - src/jdk.localedata/share/classes/sun/util/resources/fr/CurrencyNames_fr.properties - src/jdk.localedata/share/classes/sun/util/resources/fr/FR/CurrencyNames_fr_FR.properties - src/jdk.localedata/share/classes/sun/util/resources/fr/LU/CurrencyNames_fr_LU.properties - src/jdk.localedata/share/classes/sun/util/resources/fr/LocaleNames_fr.properties - src/jdk.localedata/share/classes/sun/util/resources/fr/TimeZoneNames_fr.java - src/jdk.localedata/share/classes/sun/util/resources/ga/IE/CurrencyNames_ga_IE.properties - src/jdk.localedata/share/classes/sun/util/resources/ga/LocaleNames_ga.properties - src/jdk.localedata/share/classes/sun/util/resources/hi/CalendarData_hi.properties - src/jdk.localedata/share/classes/sun/util/resources/hi/IN/CurrencyNames_hi_IN.properties - src/jdk.localedata/share/classes/sun/util/resources/hi/LocaleNames_hi.properties - src/jdk.localedata/share/classes/sun/util/resources/hi/TimeZoneNames_hi.java - src/jdk.localedata/share/classes/sun/util/resources/hr/CalendarData_hr.properties - src/jdk.localedata/share/classes/sun/util/resources/hr/HR/CurrencyNames_hr_HR.properties - src/jdk.localedata/share/classes/sun/util/resources/hr/LocaleNames_hr.properties - src/jdk.localedata/share/classes/sun/util/resources/hu/CalendarData_hu.properties - src/jdk.localedata/share/classes/sun/util/resources/hu/HU/CurrencyNames_hu_HU.properties - src/jdk.localedata/share/classes/sun/util/resources/hu/LocaleNames_hu.properties - src/jdk.localedata/share/classes/sun/util/resources/in/ID/CalendarData_in_ID.properties - src/jdk.localedata/share/classes/sun/util/resources/in/ID/CurrencyNames_in_ID.properties - src/jdk.localedata/share/classes/sun/util/resources/in/LocaleNames_in.properties - src/jdk.localedata/share/classes/sun/util/resources/is/CalendarData_is.properties - src/jdk.localedata/share/classes/sun/util/resources/is/IS/CurrencyNames_is_IS.properties - src/jdk.localedata/share/classes/sun/util/resources/is/LocaleNames_is.properties - src/jdk.localedata/share/classes/sun/util/resources/it/CH/CurrencyNames_it_CH.properties - src/jdk.localedata/share/classes/sun/util/resources/it/CalendarData_it.properties - src/jdk.localedata/share/classes/sun/util/resources/it/CurrencyNames_it.properties - src/jdk.localedata/share/classes/sun/util/resources/it/IT/CurrencyNames_it_IT.properties - src/jdk.localedata/share/classes/sun/util/resources/it/LocaleNames_it.properties - src/jdk.localedata/share/classes/sun/util/resources/it/TimeZoneNames_it.java - src/jdk.localedata/share/classes/sun/util/resources/iw/CalendarData_iw.properties - src/jdk.localedata/share/classes/sun/util/resources/iw/IL/CurrencyNames_iw_IL.properties - src/jdk.localedata/share/classes/sun/util/resources/iw/LocaleNames_iw.properties - src/jdk.localedata/share/classes/sun/util/resources/ja/CalendarData_ja.properties - src/jdk.localedata/share/classes/sun/util/resources/ja/CurrencyNames_ja.properties - src/jdk.localedata/share/classes/sun/util/resources/ja/JP/CurrencyNames_ja_JP.properties - src/jdk.localedata/share/classes/sun/util/resources/ja/LocaleNames_ja.properties - src/jdk.localedata/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java - src/jdk.localedata/share/classes/sun/util/resources/ko/CalendarData_ko.properties - src/jdk.localedata/share/classes/sun/util/resources/ko/CurrencyNames_ko.properties - src/jdk.localedata/share/classes/sun/util/resources/ko/KR/CurrencyNames_ko_KR.properties - src/jdk.localedata/share/classes/sun/util/resources/ko/LocaleNames_ko.properties - src/jdk.localedata/share/classes/sun/util/resources/ko/TimeZoneNames_ko.java - src/jdk.localedata/share/classes/sun/util/resources/lt/CalendarData_lt.properties - src/jdk.localedata/share/classes/sun/util/resources/lt/LT/CurrencyNames_lt_LT.properties - src/jdk.localedata/share/classes/sun/util/resources/lt/LocaleNames_lt.properties - src/jdk.localedata/share/classes/sun/util/resources/lv/CalendarData_lv.properties - src/jdk.localedata/share/classes/sun/util/resources/lv/LV/CurrencyNames_lv_LV.properties - src/jdk.localedata/share/classes/sun/util/resources/lv/LocaleNames_lv.properties - src/jdk.localedata/share/classes/sun/util/resources/mk/CalendarData_mk.properties - src/jdk.localedata/share/classes/sun/util/resources/mk/LocaleNames_mk.properties - src/jdk.localedata/share/classes/sun/util/resources/mk/MK/CurrencyNames_mk_MK.properties - src/jdk.localedata/share/classes/sun/util/resources/ms/LocaleNames_ms.properties - src/jdk.localedata/share/classes/sun/util/resources/ms/MY/CalendarData_ms_MY.properties - src/jdk.localedata/share/classes/sun/util/resources/ms/MY/CurrencyNames_ms_MY.properties - src/jdk.localedata/share/classes/sun/util/resources/mt/CalendarData_mt.properties - src/jdk.localedata/share/classes/sun/util/resources/mt/LocaleNames_mt.properties - src/jdk.localedata/share/classes/sun/util/resources/mt/MT/CalendarData_mt_MT.properties - src/jdk.localedata/share/classes/sun/util/resources/mt/MT/CurrencyNames_mt_MT.properties - src/jdk.localedata/share/classes/sun/util/resources/nl/BE/CurrencyNames_nl_BE.properties - src/jdk.localedata/share/classes/sun/util/resources/nl/CalendarData_nl.properties - src/jdk.localedata/share/classes/sun/util/resources/nl/LocaleNames_nl.properties - src/jdk.localedata/share/classes/sun/util/resources/nl/NL/CurrencyNames_nl_NL.properties - src/jdk.localedata/share/classes/sun/util/resources/no/CalendarData_no.properties - src/jdk.localedata/share/classes/sun/util/resources/no/LocaleNames_no.properties - src/jdk.localedata/share/classes/sun/util/resources/no/NO/CurrencyNames_no_NO.properties - src/jdk.localedata/share/classes/sun/util/resources/no/NO/LocaleNames_no_NO_NY.properties - src/jdk.localedata/share/classes/sun/util/resources/pl/CalendarData_pl.properties - src/jdk.localedata/share/classes/sun/util/resources/pl/LocaleNames_pl.properties - src/jdk.localedata/share/classes/sun/util/resources/pl/PL/CurrencyNames_pl_PL.properties - src/jdk.localedata/share/classes/sun/util/resources/pt/BR/CalendarData_pt_BR.properties - src/jdk.localedata/share/classes/sun/util/resources/pt/BR/CurrencyNames_pt_BR.properties - src/jdk.localedata/share/classes/sun/util/resources/pt/BR/LocaleNames_pt_BR.properties - src/jdk.localedata/share/classes/sun/util/resources/pt/BR/TimeZoneNames_pt_BR.java - src/jdk.localedata/share/classes/sun/util/resources/pt/CalendarData_pt.properties - src/jdk.localedata/share/classes/sun/util/resources/pt/CurrencyNames_pt.properties - src/jdk.localedata/share/classes/sun/util/resources/pt/LocaleNames_pt.properties - src/jdk.localedata/share/classes/sun/util/resources/pt/PT/CalendarData_pt_PT.properties - src/jdk.localedata/share/classes/sun/util/resources/pt/PT/CurrencyNames_pt_PT.properties - src/jdk.localedata/share/classes/sun/util/resources/pt/PT/LocaleNames_pt_PT.properties - src/jdk.localedata/share/classes/sun/util/resources/ro/CalendarData_ro.properties - src/jdk.localedata/share/classes/sun/util/resources/ro/LocaleNames_ro.properties - src/jdk.localedata/share/classes/sun/util/resources/ro/RO/CurrencyNames_ro_RO.properties - src/jdk.localedata/share/classes/sun/util/resources/ru/CalendarData_ru.properties - src/jdk.localedata/share/classes/sun/util/resources/ru/LocaleNames_ru.properties - src/jdk.localedata/share/classes/sun/util/resources/ru/RU/CurrencyNames_ru_RU.properties - src/jdk.localedata/share/classes/sun/util/resources/sk/CalendarData_sk.properties - src/jdk.localedata/share/classes/sun/util/resources/sk/LocaleNames_sk.properties - src/jdk.localedata/share/classes/sun/util/resources/sk/SK/CurrencyNames_sk_SK.properties - src/jdk.localedata/share/classes/sun/util/resources/sl/CalendarData_sl.properties - src/jdk.localedata/share/classes/sun/util/resources/sl/LocaleNames_sl.properties - src/jdk.localedata/share/classes/sun/util/resources/sl/SI/CurrencyNames_sl_SI.properties - src/jdk.localedata/share/classes/sun/util/resources/sq/AL/CurrencyNames_sq_AL.properties - src/jdk.localedata/share/classes/sun/util/resources/sq/CalendarData_sq.properties - src/jdk.localedata/share/classes/sun/util/resources/sq/LocaleNames_sq.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/BA/CalendarData_sr_Latn_BA.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/BA/CurrencyNames_sr_BA.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/BA/CurrencyNames_sr_Latn_BA.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/CS/CurrencyNames_sr_CS.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/CalendarData_sr.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/LocaleNames_sr.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/LocaleNames_sr_Latn.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/ME/CalendarData_sr_Latn_ME.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/ME/CurrencyNames_sr_Latn_ME.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/ME/CurrencyNames_sr_ME.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/RS/CalendarData_sr_Latn_RS.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/RS/CurrencyNames_sr_Latn_RS.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/RS/CurrencyNames_sr_RS.properties - src/jdk.localedata/share/classes/sun/util/resources/sv/CalendarData_sv.properties - src/jdk.localedata/share/classes/sun/util/resources/sv/CurrencyNames_sv.properties - src/jdk.localedata/share/classes/sun/util/resources/sv/LocaleNames_sv.properties - src/jdk.localedata/share/classes/sun/util/resources/sv/SE/CurrencyNames_sv_SE.properties - src/jdk.localedata/share/classes/sun/util/resources/sv/TimeZoneNames_sv.java - src/jdk.localedata/share/classes/sun/util/resources/th/CalendarData_th.properties - src/jdk.localedata/share/classes/sun/util/resources/th/LocaleNames_th.properties - src/jdk.localedata/share/classes/sun/util/resources/th/TH/CurrencyNames_th_TH.properties - src/jdk.localedata/share/classes/sun/util/resources/tr/CalendarData_tr.properties - src/jdk.localedata/share/classes/sun/util/resources/tr/LocaleNames_tr.properties - src/jdk.localedata/share/classes/sun/util/resources/tr/TR/CurrencyNames_tr_TR.properties - src/jdk.localedata/share/classes/sun/util/resources/uk/CalendarData_uk.properties - src/jdk.localedata/share/classes/sun/util/resources/uk/LocaleNames_uk.properties - src/jdk.localedata/share/classes/sun/util/resources/uk/UA/CurrencyNames_uk_UA.properties - src/jdk.localedata/share/classes/sun/util/resources/vi/CalendarData_vi.properties - src/jdk.localedata/share/classes/sun/util/resources/vi/LocaleNames_vi.properties - src/jdk.localedata/share/classes/sun/util/resources/vi/VN/CurrencyNames_vi_VN.properties - src/jdk.localedata/share/classes/sun/util/resources/zh/CN/CurrencyNames_zh_CN.properties - src/jdk.localedata/share/classes/sun/util/resources/zh/CN/TimeZoneNames_zh_CN.java - src/jdk.localedata/share/classes/sun/util/resources/zh/CalendarData_zh.properties - src/jdk.localedata/share/classes/sun/util/resources/zh/HK/CurrencyNames_zh_HK.java - src/jdk.localedata/share/classes/sun/util/resources/zh/HK/LocaleNames_zh_HK.java - src/jdk.localedata/share/classes/sun/util/resources/zh/HK/TimeZoneNames_zh_HK.java - src/jdk.localedata/share/classes/sun/util/resources/zh/LocaleNames_zh.properties - src/jdk.localedata/share/classes/sun/util/resources/zh/SG/CurrencyNames_zh_SG.java - src/jdk.localedata/share/classes/sun/util/resources/zh/SG/LocaleNames_zh_SG.properties - src/jdk.localedata/share/classes/sun/util/resources/zh/TW/CurrencyNames_zh_TW.properties - src/jdk.localedata/share/classes/sun/util/resources/zh/TW/LocaleNames_zh_TW.properties - src/jdk.localedata/share/classes/sun/util/resources/zh/TW/TimeZoneNames_zh_TW.java Changeset: 63b2f9287a8d Author: dl Date: 2016-02-20 12:19 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/63b2f9287a8d 8150014: java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java fails with NoClassDefFoundError Reviewed-by: martin, psandoz, darcy, mhaupt, dholmes ! src/java.base/share/classes/java/util/SplittableRandom.java ! src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java Changeset: 8701b2bb1d2e Author: srastogi Date: 2016-02-22 09:02 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8701b2bb1d2e 8144931: Assert class signatures are correct and refer to valid classes Reviewed-by: vlivanov, psandoz, mhaupt ! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java Changeset: b84b5f6d9ed5 Author: lana Date: 2016-02-25 09:41 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b84b5f6d9ed5 Added tag jdk-9+107 for changeset 8701b2bb1d2e ! .hgtags Changeset: 468e9ea4993b Author: henryjen Date: 2016-03-01 13:08 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/468e9ea4993b Merge ! .hgtags ! make/Tools.gmk ! make/gendata/GendataBreakIterator.gmk ! make/mapfiles/libjava/mapfile-vers - make/src/classes/build/tools/buildmetaindex/BuildMetaIndex.java ! make/src/classes/build/tools/generatebreakiteratordata/GenerateBreakIteratorData.java ! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java - src/java.base/share/classes/sun/misc/MetaIndex.java - src/java.base/share/classes/sun/misc/NativeSignalHandler.java ! src/java.base/share/classes/sun/misc/URLClassPath.java ! src/java.base/share/classes/sun/util/resources/LocaleData.java ! src/java.base/share/conf/security/java.security - src/java.base/share/native/libjava/NativeSignalHandler.c ! src/jdk.jconsole/share/classes/sun/tools/jconsole/AboutDialog.java ! test/ProblemList.txt ! test/TEST.groups ! test/sun/jvmstat/perfdata/PrologSanity/PrologSizeSanityCheck.java ! test/sun/security/mscapi/ShortRSAKey1024.sh From mandy.chung at oracle.com Tue Mar 1 22:02:32 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 01 Mar 2016 22:02:32 +0000 Subject: hg: jigsaw/jake/langtools: 11 new changesets Message-ID: <201603012202.u21M2WMv026267@aojmv0008.oracle.com> Changeset: a579d393fdd9 Author: jjg Date: 2016-02-15 14:02 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/a579d393fdd9 8149773: StandardDocFileFactory should be converted to use java.nio.file.Path Reviewed-by: ksrini ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets.properties - src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/util/SimpleDocFileFactory.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/util/StandardDocFileFactory.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/Configuration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/SimpleDocFileFactory.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/StandardDocFileFactory.java Changeset: 51c59975ddfd Author: darcy Date: 2016-02-15 17:17 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/51c59975ddfd 6469561: javadoc for annotation types should not display "public abstract" modifiers on methods 6469562: Use compact notation to display annotation values Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractMemberWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! test/jdk/javadoc/doclet/testAnnotationTypes/TestAnnotationTypes.java ! test/jdk/javadoc/doclet/testAnnotationTypes/pkg/AnnotationType.java ! test/jdk/javadoc/doclet/testRepeatedAnnotations/TestRepeatedAnnotations.java ! test/jdk/javadoc/doclet/testRepeatedAnnotations/pkg/C.java ! test/jdk/javadoc/doclet/testRepeatedAnnotations/pkg/D.java ! test/jdk/javadoc/doclet/testTypeAnnotations/TestTypeAnnotations.java ! test/jdk/javadoc/doclet/testTypeAnnotations/typeannos/Throws.java ! test/jdk/javadoc/doclet/testTypeAnnotations/typeannos/Wildcards.java Changeset: a2cdf1f97da8 Author: jjg Date: 2016-02-15 19:52 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/a2cdf1f97da8 8149886: 16 windows tests broke with recent putback Reviewed-by: sundar ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java Changeset: a910d5c72bbc Author: jjg Date: 2016-02-15 22:21 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/a910d5c72bbc 8149903: Fix other Extern. Reviewed-by: darcy ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Extern.java Changeset: 28bc1393dbdc Author: shade Date: 2016-02-17 19:29 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/28bc1393dbdc 8149835: StringConcatFactory should emit classes with the same package as the host class Reviewed-by: psandoz, alanb, mchung ! test/tools/javac/TestIndyStringConcat.java Changeset: fb1ccb29bf7f Author: ksrini Date: 2016-02-17 11:19 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/fb1ccb29bf7f 8149842: javadoc incorrectly tries to get the documentation for inherited methods. Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/DocEnv.java + test/jdk/javadoc/doclet/testIncluded/TestIncluded.java + test/jdk/javadoc/doclet/testIncluded/parent/A.java + test/jdk/javadoc/doclet/testIncluded/pkg/B.java Changeset: 028ef371113f Author: simonis Date: 2016-02-17 19:09 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/028ef371113f 8150077: Due to a javac type inference issue, javadoc doesn't compile with a jdk prior to 8u40 Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/RootDocImpl.java Changeset: b14765617d7f Author: lana Date: 2016-02-18 13:42 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/b14765617d7f Merge - src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/util/SimpleDocFileFactory.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/SimpleDocFileFactory.java Changeset: 7a0c34355149 Author: ksrini Date: 2016-02-18 12:48 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/7a0c34355149 8150096: Cleanup synthetic JCCompilationUnit for html files Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/doclint/Checker.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/JavadocClassFinder.java + test/jdk/javadoc/doclet/testPackageHtml/TestPackageHtml.java + test/jdk/javadoc/doclet/testPackageHtml/pkg1/X.java + test/jdk/javadoc/doclet/testPackageHtml/pkg1/package.html ! test/jdk/javadoc/doclet/testWarnings/TestWarnings.java Changeset: f0d9874b56e7 Author: lana Date: 2016-02-25 09:41 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/f0d9874b56e7 Added tag jdk-9+107 for changeset 7a0c34355149 ! .hgtags Changeset: bbc4edca1588 Author: henryjen Date: 2016-03-01 13:08 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/bbc4edca1588 Merge ! .hgtags ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets.properties ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/util/SimpleDocFileFactory.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/util/StandardDocFileFactory.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/Configuration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Extern.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/SimpleDocFileFactory.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/StandardDocFileFactory.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/DocEnv.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/JavadocClassFinder.java ! test/jdk/javadoc/doclet/testAnnotationTypes/TestAnnotationTypes.java ! test/jdk/javadoc/doclet/testRepeatedAnnotations/TestRepeatedAnnotations.java ! test/jdk/javadoc/doclet/testTypeAnnotations/TestTypeAnnotations.java ! test/jdk/javadoc/doclet/testWarnings/TestWarnings.java ! test/tools/javac/TestIndyStringConcat.java From mandy.chung at oracle.com Tue Mar 1 22:02:35 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 01 Mar 2016 22:02:35 +0000 Subject: hg: jigsaw/jake/nashorn: 6 new changesets Message-ID: <201603012202.u21M2Z7h026372@aojmv0008.oracle.com> Changeset: d99fa86747ee Author: hannesw Date: 2016-02-15 17:02 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/d99fa86747ee 8147558: Add support for ES6 collections Reviewed-by: attila, mhaupt ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ClassGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/MemberInfo.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/StringConstants.java + src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/AbstractIterator.java + src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/ArrayIterator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/Global.java + src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/IteratorResult.java + src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/LinkedMap.java + src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/MapIterator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeArray.java + src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeMap.java + src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeSet.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeString.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeSymbol.java + src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeWeakMap.java + src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeWeakSet.java + src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/SetIterator.java + src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/StringIterator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/annotations/Attribute.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/FindProperty.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Property.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/PropertyMap.java ! 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/SetMethodCreator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/UserAccessorProperty.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/Messages.properties ! test/script/basic/es6.js + test/script/basic/es6/iterator.js + test/script/basic/es6/map.js + test/script/basic/es6/set.js + test/script/basic/es6/weakmap.js + test/script/basic/es6/weakset.js Changeset: 221378857767 Author: mhaupt Date: 2016-02-16 15:34 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/221378857767 8148140: arguments are handled differently in apply for JS functions and AbstractJSObjects Reviewed-by: hannesw, sundar ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java + test/src/jdk/nashorn/api/scripting/test/JDK_8148140_Test.java ! test/src/jdk/nashorn/internal/runtime/test/JDK_8142924_Test.java Changeset: 1a96d288cb50 Author: lana Date: 2016-02-18 13:43 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/1a96d288cb50 Merge Changeset: 8042e81b530e Author: attila Date: 2016-02-18 22:34 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/8042e81b530e 8149451: Fix bytecode generation issue after 8149186 Reviewed-by: mhaupt, sundar ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/types/BooleanType.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/types/IntType.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/types/LongType.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/types/Type.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/Bootstrap.java Changeset: f33edb1f75f3 Author: lana Date: 2016-02-25 09:41 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/f33edb1f75f3 Added tag jdk-9+107 for changeset 8042e81b530e ! .hgtags Changeset: 41b5809270a6 Author: henryjen Date: 2016-03-01 13:08 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/41b5809270a6 Merge ! .hgtags From mandy.chung at oracle.com Wed Mar 2 00:42:50 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 02 Mar 2016 00:42:50 +0000 Subject: hg: jigsaw/jake/langtools: Minor clean up on jdk9 b107 merge Message-ID: <201603020042.u220goTt023879@aojmv0008.oracle.com> Changeset: 6b66d9527a76 Author: ksrini Date: 2016-03-01 16:42 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/6b66d9527a76 Minor clean up on jdk9 b107 merge ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java From mandy.chung at oracle.com Wed Mar 2 02:09:44 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 02 Mar 2016 02:09:44 +0000 Subject: hg: jigsaw/jake/jdk: clean up stale requires and qualified exports Message-ID: <201603020209.u2229iHC021052@aojmv0008.oracle.com> Changeset: 4fae0f1cf1eb Author: mchung Date: 2016-03-01 18:04 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4fae0f1cf1eb clean up stale requires and qualified exports ! src/java.base/share/classes/module-info.java ! src/java.desktop/share/classes/module-info.java ! src/java.naming/share/classes/sun/security/provider/certpath/ldap/LDAPCertStoreImpl.java ! src/java.sql.rowset/share/classes/module-info.java ! src/jdk.crypto.ec/share/classes/module-info.java ! src/jdk.crypto.pkcs11/share/classes/module-info.java From stuart.marks at oracle.com Wed Mar 2 02:28:16 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 1 Mar 2016 18:28:16 -0800 Subject: RFR 8078812, Test RMI with client and servers as modules In-Reply-To: <56D5312E.9030508@oracle.com> References: <56D5312E.9030508@oracle.com> Message-ID: <56D64FC0.2050609@oracle.com> Hi Felix, sorry for the delay. Several comments below. -------------------------------------------------- 119 // wait for rmiregistry to be fully ready 120 Thread.sleep(3000); There are some RMI test utilities that will handle starting up and waiting for the registry to be ready. Unfortunately they're in the unnamed package (still haven't cleaned that up) so you can't use them from this test. For now I'd recommend scaling the timeout by the test.timeout.factor, so that this won't fail on slow systems. There's a test utility for that; see Utils.adjustTimeout(). -------------------------------------------------- The directory "unamed" is misspelled; it has classes in the unnamed module. This misspelling is reflected in variable names and values, e.g., 59 private static final Path UNAMED_SRC_DIR = Paths.get(TEST_SRC, "unamed"); 60 private static final Path MODS_OUTPUT_DIR = Paths.get("mods"); 61 private static final Path UNAMED_OUTPUT_DIR = Paths.get("unamed"); While spelling errors aren't that big a deal, since this involves file and directory names, I'd recommend fixing this now. It'll just be harder to fix it later. Also, "SeperateModuleClient" => "SeparateModuleClient" -------------------------------------------------- Overall the structure of the test seems reasonable to test various clients and servers in combinations of the same, different, and unnamed modules. I'm not entirely sure what p2.SeperateModuleClient is testing. It extends p1.Client and its constructor and testStub() method simply call the corresponding methods on super, so it doesn't seem to be testing anything different from p1.Client running against p3.Server. Also, p4.UnamedModuleClient seems to want to run the client from the unnamed module, but it too extends p1.Client and simply defers all of its execution to its superclass. So I don't think this actually testing an RMI client call originating from an unnamed module. There is an uncomfortable amount of duplication between mtest/test/DummyApp.java and p4/UnamedModuleDummyApp. I see what this is trying to do, which is to test a RMI server from an unnamed module. It instantiates p3.Server, which resides in a named module, but exports it from an unnamed module. So I think there's some tension here. There's subclassing among the clients that attempts to avoid duplication, which is good, but it doesn't truly seem to be testing clients in different modules and in an unnamed module. The server, on the other hand, does seem to be testing things properly in different modules, at the cost of duplicating all the code into another class that resides in a different (unnamed) module. I'm not entirely sure what the best approach is here. Ideally you'd want to have a single implementation of client, server + remote interface, and application, and compile each of them once. Then since you're invoking a new JVM for each test, invoke it with different options to put the client, or the server, or the app, into modules, or onto the classpath (to get into an unnamed module). You might have to copy compiled class files to different locations so that different classes can be either on the classpath or in a named module without causing any conflicts. I'm willing to entertain some simplifications here as well. It might be sufficient to deal with just clients and servers in different/unnamed modules, and not worry about putting the application into different modules. That should reduce the number of cases to cover. s'marks On 2/29/16 10:05 PM, Felix Yang wrote: > Ping... > > -Felix > On 2016/2/24 14:06, Felix Yang wrote: >> Hi all, >> please review the new tests to use RMI in module world. >> >> Webrev: >> http://cr.openjdk.java.net/~xiaofeya/8078812/webrev.00/ >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8078812 >> >> Thanks, >> Felix > From scolebourne at joda.org Wed Mar 2 12:40:15 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 2 Mar 2016 12:40:15 +0000 Subject: Missing issue? - indexing Message-ID: Tools like Reflections [1], Scannotaions [2] and many more [3] provide the ability to find instances of annotations on the classpath. They also provide the ability to find subclasses of an interface. This kind of tooling is commonly needed by Java EE. Different tools use different approaches to gather the information, but it is definitely something that could be captured when building a module. At the very least, it is important to ensure that these tools continue to work. Stephen [1] https://github.com/ronmamo/reflections [2] http://scannotation.sourceforge.net/ [3] http://stackoverflow.com/questions/259140/scanning-java-annotations-at-runtime From Alan.Bateman at oracle.com Wed Mar 2 13:30:06 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 2 Mar 2016 13:30:06 +0000 Subject: Missing issue? - indexing In-Reply-To: References: Message-ID: <56D6EADE.5080606@oracle.com> On 02/03/2016 12:40, Stephen Colebourne wrote: > Tools like Reflections [1], Scannotaions [2] and many more [3] provide > the ability to find instances of annotations on the classpath. They > also provide the ability to find subclasses of an interface. This kind > of tooling is commonly needed by Java EE. Different tools use > different approaches to gather the information, but it is definitely > something that could be captured when building a module. At the very > least, it is important to ensure that these tools continue to work. > There is an item in the requirements document on this [1] but nothing in the jake forest specifically for this. Link-time is potentially a great phase to do indexing of modules that will be linked into the run-time image and I'm sure that lots could be explored there. Just on existing tools that are scanning the class path, have you run into issues there that suggest they won't work as before? -Alan [1] http://openjdk.java.net/projects/jigsaw/spec/reqs/#efficient-annotation-detection From scolebourne at joda.org Wed Mar 2 14:45:31 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 2 Mar 2016 14:45:31 +0000 Subject: Missing issue? - indexing In-Reply-To: <56D6EADE.5080606@oracle.com> References: <56D6EADE.5080606@oracle.com> Message-ID: On 2 March 2016 at 13:30, Alan Bateman wrote: > Just on existing tools that are scanning the class path, have you run into > issues there that suggest they won't work as before? I know that the internals of reflections are complex, trying to find files in jars, classpath and other app-server specific locations. I haven't tried it on JDK 9, but I'd imagine it would need alteration. Stephen From Alan.Bateman at oracle.com Wed Mar 2 15:00:58 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 2 Mar 2016 15:00:58 +0000 Subject: Need help testing the EA builds Message-ID: <56D7002A.9000509@oracle.com> We are starting to think through how to bring the module system that is the monster patch in jigsaw/jake forest into the JDK 9 main line. There are many reasons to do this. One reason is to reduce testing effort. Another is to reduce the cost of sync ups as it takes a lot of effort each week to merge in the changes from JDK 9. We also have confused some developers by having two early access (EA) builds, one EA build with Project Jigsaw, the other without. It should also be obvious that time is moving on and we don't want to be rushing things right before JDK 9 Feature Complete. Merging into the JDK 9 main line will be a big step and there are many things that need to be done to make this happen. The proposal will most likely be to take snapshot of what we have in jake and bring it into JDK 9 after stabilization, testing and of course review. Once it is in JDK 9 then we'll continue to iterate and work through the many issues that need attention. One thing that would be useful is to get as many people as possible to try out the EA builds [1]. It really helps confidence when there is confirmation that existing libraries and applications work as before. If there are bugs or issues that involve any of the supported interfaces then we want to know. We know well that there are several compatibility issues and we've attempted to capture those in the Risks and Assumption section of JEP 261 [2]. We also interested in bug reports and issues from those trying out the EA builds to create their own modules or migrating existing code or libraries to modules. Bonus points for those brave enough to try out some of the many new APIs too. -Alan [1] https://jdk9.java.net/jigsaw/ [2] http://openjdk.java.net/jeps/261 From stephen.felts at oracle.com Wed Mar 2 15:26:14 2016 From: stephen.felts at oracle.com (Stephen Felts) Date: Wed, 2 Mar 2016 07:26:14 -0800 (PST) Subject: Need help testing the EA builds In-Reply-To: <56D7002A.9000509@oracle.com> References: <56D7002A.9000509@oracle.com> Message-ID: <7bfb9090-4fef-400f-abef-bfc7a3e50b79@default> This will be a significant problem for a lot of people with respect to tools not working. Gradle junit - basic problem fixed in upcoming release Jython Ant - certain cases with classloader JDT - doesn't work at all Asm - never tracked down issue Jmockit Simplestub Of course, these are problems that I don't have a workaround for. I'm currently exporting 25 packages, have 30 patch files, two module jars, and two upgrade jars, setting both command line options and undocumented loader options, playing tricks to get the gradle daemon to run, etc. And because of these problems that I don't have a workaround for, we can't run any tests, either unit or functional, so coverage is almost non-existent and I don't know what else is broken. -----Original Message----- From: Alan Bateman Sent: Wednesday, March 02, 2016 10:01 AM To: jigsaw-dev Subject: Need help testing the EA builds We are starting to think through how to bring the module system that is the monster patch in jigsaw/jake forest into the JDK 9 main line. There are many reasons to do this. One reason is to reduce testing effort. Another is to reduce the cost of sync ups as it takes a lot of effort each week to merge in the changes from JDK 9. We also have confused some developers by having two early access (EA) builds, one EA build with Project Jigsaw, the other without. It should also be obvious that time is moving on and we don't want to be rushing things right before JDK 9 Feature Complete. Merging into the JDK 9 main line will be a big step and there are many things that need to be done to make this happen. The proposal will most likely be to take snapshot of what we have in jake and bring it into JDK 9 after stabilization, testing and of course review. Once it is in JDK 9 then we'll continue to iterate and work through the many issues that need attention. One thing that would be useful is to get as many people as possible to try out the EA builds [1]. It really helps confidence when there is confirmation that existing libraries and applications work as before. If there are bugs or issues that involve any of the supported interfaces then we want to know. We know well that there are several compatibility issues and we've attempted to capture those in the Risks and Assumption section of JEP 261 [2]. We also interested in bug reports and issues from those trying out the EA builds to create their own modules or migrating existing code or libraries to modules. Bonus points for those brave enough to try out some of the many new APIs too. -Alan [1] https://jdk9.java.net/jigsaw/ [2] http://openjdk.java.net/jeps/261 From christian.tornqvist at oracle.com Wed Mar 2 15:28:53 2016 From: christian.tornqvist at oracle.com (christian.tornqvist at oracle.com) Date: Wed, 02 Mar 2016 15:28:53 +0000 Subject: hg: jigsaw/jake/hotspot: Revert unnecessary changes in Hotspot tests Message-ID: <201603021528.u22FSr51026237@aojmv0008.oracle.com> Changeset: a02ebbf1f732 Author: ctornqvi Date: 2016-03-02 07:25 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a02ebbf1f732 Revert unnecessary changes in Hotspot tests ! test/compiler/intrinsics/classcast/NullCheckDroppingsTest.java ! test/compiler/uncommontrap/TestUnstableIfTrap.java ! test/gc/g1/TestLargePageUseForAuxMemory.java ! test/gc/g1/TestRemsetLogging.java ! test/gc/g1/TestRemsetLoggingPerRegion.java ! test/gc/g1/TestShrinkAuxiliaryData00.java ! test/gc/g1/TestShrinkAuxiliaryData05.java ! test/gc/g1/TestShrinkAuxiliaryData10.java ! test/gc/g1/TestShrinkAuxiliaryData15.java ! test/gc/g1/TestShrinkAuxiliaryData20.java ! test/gc/g1/TestShrinkAuxiliaryData25.java ! test/gc/g1/TestShrinkAuxiliaryData30.java ! test/gc/g1/TestShrinkDefragmentedHeap.java ! test/gc/g1/TestStringDeduplicationTools.java ! test/gc/parallel/TestDynShrinkHeap.java ! test/runtime/ClassFile/UnsupportedClassFileVersion.java ! test/runtime/ErrorHandling/CreateCoredumpOnCrash.java ! test/runtime/ErrorHandling/TestExitOnOutOfMemoryError.java ! test/runtime/NMT/JcmdWithNMTDisabled.java ! test/runtime/RedefineTests/RedefineFinalizer.java ! test/runtime/RedefineTests/RedefineRunningMethods.java ! test/runtime/Unsafe/GetKlassPointerGetJavaMirror.java ! test/runtime/Unsafe/GetUncompressedObject.java ! test/runtime/Unsafe/RangeCheck.java ! test/serviceability/attach/AttachSetGetFlag.java ! test/serviceability/attach/AttachWithStalePidFile.java ! test/serviceability/dcmd/compiler/CodelistTest.java ! test/serviceability/dcmd/compiler/CompilerQueueTest.java ! test/serviceability/dcmd/jvmti/DataDumpDcmdTest.java ! test/serviceability/jvmti/TestRedefineWithUnresolvedClass.java ! test/serviceability/sa/TestClassLoaderStats.java ! test/serviceability/sa/TestStackTrace.java ! test/testlibrary_tests/RedefineClassTest.java From alan.bateman at oracle.com Wed Mar 2 15:41:57 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 02 Mar 2016 15:41:57 +0000 Subject: hg: jigsaw/jake/hotspot: 2 new changesets Message-ID: <201603021541.u22FfvVf001591@aojmv0008.oracle.com> Changeset: b4bba9d7bb60 Author: alanb Date: 2016-03-02 10:47 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b4bba9d7bb60 Move built-in class loaders to jdk.internal.loader ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp Changeset: 3f8af4b449a3 Author: alanb Date: 2016-03-02 15:42 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3f8af4b449a3 Merge From alan.bateman at oracle.com Wed Mar 2 15:42:09 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 02 Mar 2016 15:42:09 +0000 Subject: hg: jigsaw/jake/jdk: 7 new changesets Message-ID: <201603021542.u22Fg9bU001703@aojmv0008.oracle.com> Changeset: 97ee4e575b0d Author: alanb Date: 2016-03-02 09:40 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/97ee4e575b0d Fix isSynthetic ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java ! src/java.base/share/classes/java/lang/module/ModuleInfo.java ! src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java ! test/jdk/jigsaw/module/AutomaticModulesTest.java ! test/jdk/jigsaw/module/ModuleDescriptorTest.java Changeset: d1e6e1d3cfc8 Author: alanb Date: 2016-03-02 10:47 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d1e6e1d3cfc8 Move built-in class loaders to jdk.internal.loader ! make/mapfiles/libjava/mapfile-vers ! src/java.base/macosx/classes/module-info.java.extra ! 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/java/lang/reflect/Layer.java ! src/java.base/share/classes/java/lang/reflect/Module.java ! src/java.base/share/classes/java/lang/reflect/Proxy.java ! src/java.base/share/classes/java/util/ServiceLoader.java + src/java.base/share/classes/jdk/internal/loader/BootLoader.java + src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java + src/java.base/share/classes/jdk/internal/loader/ClassLoaders.java + src/java.base/share/classes/jdk/internal/loader/Loader.java + src/java.base/share/classes/jdk/internal/loader/LoaderPool.java - src/java.base/share/classes/jdk/internal/misc/BootLoader.java - src/java.base/share/classes/jdk/internal/misc/BuiltinClassLoader.java - src/java.base/share/classes/jdk/internal/misc/ClassLoaders.java - src/java.base/share/classes/jdk/internal/misc/Loader.java - src/java.base/share/classes/jdk/internal/misc/LoaderPool.java ! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java ! src/java.base/share/classes/jdk/internal/module/ModuleLoaderMap.java ! src/java.base/share/classes/jdk/internal/module/Modules.java ! src/java.base/share/classes/sun/util/locale/provider/ResourceBundleProviderSupport.java ! src/java.base/share/native/libjava/BootLoader.c ! src/java.desktop/macosx/classes/com/apple/laf/AquaUtils.java Changeset: 43eda1da4b60 Author: alanb Date: 2016-03-02 11:06 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/43eda1da4b60 Minor javadoc update ! src/java.base/share/classes/java/lang/reflect/Layer.java Changeset: 382a3232f04f Author: alanb Date: 2016-03-02 12:05 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/382a3232f04f Remove dependency on Reflection.verifyModuleAccess ! src/java.base/share/classes/sun/invoke/util/VerifyAccess.java Changeset: 57652a3bd006 Author: alanb Date: 2016-03-02 12:05 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/57652a3bd006 Remove SignedJarTest from exclude list ! test/ProblemList.jake.txt Changeset: 4b6e5280e43b Author: alanb Date: 2016-03-02 15:25 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4b6e5280e43b Align core reflection checks to current proposal ! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java ! src/java.base/share/classes/java/lang/reflect/package-info.java ! src/java.base/share/classes/java/security/UnresolvedPermission.java ! src/java.base/share/classes/java/util/ServiceLoader.java ! src/java.base/share/classes/javax/security/auth/login/LoginContext.java ! src/java.base/share/classes/sun/reflect/MethodAccessorGenerator.java ! src/java.base/share/classes/sun/reflect/Reflection.java ! src/java.base/share/classes/sun/security/provider/PolicyFile.java ! test/ProblemList.jake.txt ! test/java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java ! test/jdk/jigsaw/reflect/Module/access/src/test/test/Main.java Changeset: 1b9780bce9d3 Author: alanb Date: 2016-03-02 15:39 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1b9780bce9d3 Revert uses of addReads in several modules ! src/java.datatransfer/share/classes/sun/datatransfer/DataFlavorUtil.java ! src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java ! src/java.logging/share/classes/java/util/logging/LogManager.java ! src/java.logging/share/classes/java/util/logging/MemoryHandler.java ! src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java ! src/java.naming/share/classes/com/sun/naming/internal/FactoryEnumeration.java ! src/java.naming/share/classes/com/sun/naming/internal/ResourceManager.java ! src/java.naming/share/classes/javax/naming/spi/NamingManager.java ! src/java.prefs/share/classes/java/util/prefs/Preferences.java ! src/java.sql.rowset/share/classes/com/sun/rowset/CachedRowSetImpl.java ! src/java.sql.rowset/share/classes/com/sun/rowset/internal/CachedRowSetWriter.java ! src/java.sql.rowset/share/classes/javax/sql/rowset/RowSetProvider.java ! src/java.sql.rowset/share/classes/javax/sql/rowset/serial/SQLInputImpl.java ! src/java.sql.rowset/share/classes/javax/sql/rowset/spi/SyncFactory.java ! src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/SunPKCS11.java ! src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java ! src/jdk.policytool/share/classes/sun/security/tools/policytool/PolicyTool.java From alan.bateman at oracle.com Wed Mar 2 15:59:25 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 02 Mar 2016 15:59:25 +0000 Subject: hg: jigsaw/jake/jaxp: Revert uses of addReads in java.xml module Message-ID: <201603021559.u22FxPJn008094@aojmv0008.oracle.com> Changeset: 6757519583ae Author: alanb Date: 2016-03-02 16:00 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/6757519583ae Revert uses of addReads in java.xml module ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/AbstractDOMParser.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/compiler/FunctionTable.java ! src/java.xml/share/classes/javax/xml/datatype/FactoryFinder.java ! src/java.xml/share/classes/javax/xml/parsers/FactoryFinder.java ! src/java.xml/share/classes/javax/xml/stream/FactoryFinder.java ! src/java.xml/share/classes/javax/xml/transform/FactoryFinder.java ! src/java.xml/share/classes/javax/xml/validation/SchemaFactoryFinder.java ! src/java.xml/share/classes/javax/xml/xpath/XPathFactoryFinder.java ! src/java.xml/share/classes/org/w3c/dom/bootstrap/DOMImplementationRegistry.java ! src/java.xml/share/classes/org/xml/sax/helpers/NewInstance.java From Alan.Bateman at oracle.com Wed Mar 2 16:13:22 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 2 Mar 2016 16:13:22 +0000 Subject: Need help testing the EA builds In-Reply-To: <7bfb9090-4fef-400f-abef-bfc7a3e50b79@default> References: <56D7002A.9000509@oracle.com> <7bfb9090-4fef-400f-abef-bfc7a3e50b79@default> Message-ID: <56D71122.4040406@oracle.com> On 02/03/2016 15:26, Stephen Felts wrote: > This will be a significant problem for a lot of people with respect to tools not working. > Gradle junit - basic problem fixed in upcoming release > Jython > Ant - certain cases with classloader > JDT - doesn't work at all > Asm - never tracked down issue > Jmockit > Simplestub > For some of the tools/libraries that you list then I assume the issues aren't specific to the module system or other changes in the jigsaw/jake forest. Instead I assume that at least some of the issues are due to the restructuring of the JDK run-time image (JEP 220). We knew this would be a disruptive change so this is one of the reasons it went into JDK 9 very early (in late 2014) and give the tools as much time as possible. I see for Jython that you have an issue in their issue tracker for this. Jayaprakash Arthanareeswaran has been on this list a few times and might be able to say a few words about JDT. I've read several articles about beta versions working with JDK 9 and it appears that good progress has been made. -Alan From alan.bateman at oracle.com Wed Mar 2 16:17:38 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 02 Mar 2016 16:17:38 +0000 Subject: hg: jigsaw/jake/corba: Revert uses of addReads in java.corba module Message-ID: <201603021617.u22GHcwF015597@aojmv0008.oracle.com> Changeset: 2ccacd84caa9 Author: alanb Date: 2016-03-02 16:18 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/2ccacd84caa9 Revert uses of addReads in java.corba module ! src/java.corba/share/classes/com/sun/corba/se/impl/activation/ServerMain.java ! src/java.corba/share/classes/com/sun/corba/se/impl/encoding/CDRInputStream_1_0.java ! src/java.corba/share/classes/com/sun/corba/se/impl/encoding/CDROutputStream_1_0.java ! src/java.corba/share/classes/com/sun/corba/se/impl/interceptors/RequestInfoImpl.java ! src/java.corba/share/classes/com/sun/corba/se/impl/io/IIOPOutputStream.java ! src/java.corba/share/classes/com/sun/corba/se/impl/io/ObjectStreamClass.java ! src/java.corba/share/classes/com/sun/corba/se/impl/orb/ORBConfiguratorImpl.java ! src/java.corba/share/classes/com/sun/corba/se/impl/orb/ORBImpl.java ! src/java.corba/share/classes/com/sun/corba/se/impl/orb/ParserTable.java ! src/java.corba/share/classes/com/sun/corba/se/impl/orbutil/ORBUtility.java ! src/java.corba/share/classes/com/sun/corba/se/impl/presentation/rmi/ExceptionHandlerImpl.java ! src/java.corba/share/classes/com/sun/corba/se/impl/presentation/rmi/ReflectiveTie.java ! src/java.corba/share/classes/com/sun/corba/se/impl/presentation/rmi/StubFactoryFactoryStaticImpl.java ! src/java.corba/share/classes/com/sun/corba/se/impl/presentation/rmi/StubFactoryStaticImpl.java ! src/java.corba/share/classes/com/sun/corba/se/impl/protocol/CorbaClientDelegateImpl.java ! src/java.corba/share/classes/com/sun/corba/se/impl/protocol/giopmsgheaders/MessageBase.java - src/java.corba/share/classes/com/sun/corba/se/impl/util/Modules.java ! src/java.corba/share/classes/com/sun/corba/se/impl/util/RepositoryId.java ! src/java.corba/share/classes/com/sun/corba/se/impl/util/Utility.java ! src/java.corba/share/classes/com/sun/corba/se/spi/orbutil/proxy/DelegateInvocationHandlerImpl.java ! src/java.corba/share/classes/javax/rmi/CORBA/Stub.java ! src/java.corba/share/classes/javax/rmi/CORBA/Util.java ! src/java.corba/share/classes/javax/rmi/PortableRemoteObject.java ! src/java.corba/share/classes/org/omg/CORBA/ORB.java ! src/java.corba/share/classes/org/omg/CORBA/portable/ObjectImpl.java ! src/java.corba/share/classes/org/omg/PortableServer/Servant.java From stephen.felts at oracle.com Wed Mar 2 16:29:39 2016 From: stephen.felts at oracle.com (Stephen Felts) Date: Wed, 2 Mar 2016 08:29:39 -0800 (PST) Subject: Need help testing the EA builds In-Reply-To: <56D71122.4040406@oracle.com> References: <56D7002A.9000509@oracle.com> <7bfb9090-4fef-400f-abef-bfc7a3e50b79@default> <56D71122.4040406@oracle.com> Message-ID: <416b178c-b60f-491d-b05f-1e58b568254e@default> Yes, you are correct. The rt.jar change and the classloading changes have caused many of these tools problems. I should have tried to separate the Jake from non-Jake problems. I've also been entering bugs where possible. I entered them for gradle, jython, eclipselink, and findbugs for tools outside Oracle. Using upgrade, module, and patch files is clearly Jake as are the need to use exports. Jmockit and Simplestub are I think partly related to Jake but it's hard to tell until we figure out the full problem. Passing information to the Gradle daemon is Jake related (separate from the junit problem). -----Original Message----- From: Alan Bateman Sent: Wednesday, March 02, 2016 11:13 AM To: Stephen Felts; jigsaw-dev Subject: Re: Need help testing the EA builds On 02/03/2016 15:26, Stephen Felts wrote: > This will be a significant problem for a lot of people with respect to tools not working. > Gradle junit - basic problem fixed in upcoming release Jython Ant - > certain cases with classloader JDT - doesn't work at all Asm - never > tracked down issue Jmockit Simplestub > For some of the tools/libraries that you list then I assume the issues aren't specific to the module system or other changes in the jigsaw/jake forest. Instead I assume that at least some of the issues are due to the restructuring of the JDK run-time image (JEP 220). We knew this would be a disruptive change so this is one of the reasons it went into JDK 9 very early (in late 2014) and give the tools as much time as possible. I see for Jython that you have an issue in their issue tracker for this. Jayaprakash Arthanareeswaran has been on this list a few times and might be able to say a few words about JDT. I've read several articles about beta versions working with JDK 9 and it appears that good progress has been made. -Alan From russell.gold at oracle.com Wed Mar 2 16:41:00 2016 From: russell.gold at oracle.com (Russell Gold) Date: Wed, 2 Mar 2016 11:41:00 -0500 Subject: Need help testing the EA builds In-Reply-To: <416b178c-b60f-491d-b05f-1e58b568254e@default> References: <56D7002A.9000509@oracle.com> <7bfb9090-4fef-400f-abef-bfc7a3e50b79@default> <56D71122.4040406@oracle.com> <416b178c-b60f-491d-b05f-1e58b568254e@default> Message-ID: Simplestub, at least, should no longer be a problem. The issue there was Javassist, but the ASM implementation works on Jigsaw. > On Mar 2, 2016, at 11:29 AM, Stephen Felts wrote: > > Yes, you are correct. The rt.jar change and the classloading changes have caused many of these tools problems. I should have tried to separate the Jake from non-Jake problems. > I've also been entering bugs where possible. I entered them for gradle, jython, eclipselink, and findbugs for tools outside Oracle. > > Using upgrade, module, and patch files is clearly Jake as are the need to use exports. > Jmockit and Simplestub are I think partly related to Jake but it's hard to tell until we figure out the full problem. > Passing information to the Gradle daemon is Jake related (separate from the junit problem). > > -----Original Message----- > From: Alan Bateman > Sent: Wednesday, March 02, 2016 11:13 AM > To: Stephen Felts; jigsaw-dev > Subject: Re: Need help testing the EA builds > > > On 02/03/2016 15:26, Stephen Felts wrote: >> This will be a significant problem for a lot of people with respect to tools not working. >> Gradle junit - basic problem fixed in upcoming release Jython Ant - >> certain cases with classloader JDT - doesn't work at all Asm - never >> tracked down issue Jmockit Simplestub >> > For some of the tools/libraries that you list then I assume the issues aren't specific to the module system or other changes in the jigsaw/jake forest. Instead I assume that at least some of the issues are due to the restructuring of the JDK run-time image (JEP 220). We knew this would be a disruptive change so this is one of the reasons it went into JDK 9 very early (in late 2014) and give the tools as much time as possible. > > I see for Jython that you have an issue in their issue tracker for this. > > Jayaprakash Arthanareeswaran has been on this list a few times and might be able to say a few words about JDT. I've read several articles about beta versions working with JDK 9 and it appears that good progress has been made. > > -Alan From alan.bateman at oracle.com Wed Mar 2 16:44:06 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 02 Mar 2016 16:44:06 +0000 Subject: hg: jigsaw/jake/jdk: Revert uses of addReads in java.rmi module Message-ID: <201603021644.u22Gi6iG024970@aojmv0008.oracle.com> Changeset: 2fe9d4061c0c Author: alanb Date: 2016-03-02 16:45 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2fe9d4061c0c Revert uses of addReads in java.rmi module ! src/java.rmi/share/classes/java/rmi/activation/ActivationGroup.java ! src/java.rmi/share/classes/java/rmi/server/RMIClassLoader.java ! src/java.rmi/share/classes/sun/rmi/log/ReliableLog.java ! src/java.rmi/share/classes/sun/rmi/server/Activation.java ! src/java.rmi/share/classes/sun/rmi/server/ActivationGroupImpl.java ! src/java.rmi/share/classes/sun/rmi/server/UnicastServerRef.java ! src/java.rmi/share/classes/sun/rmi/server/Util.java From david.lloyd at redhat.com Wed Mar 2 16:50:16 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 2 Mar 2016 10:50:16 -0600 Subject: Need help testing the EA builds In-Reply-To: <56D7002A.9000509@oracle.com> References: <56D7002A.9000509@oracle.com> Message-ID: <56D719C8.5000405@redhat.com> On 03/02/2016 09:00 AM, Alan Bateman wrote: > > We are starting to think through how to bring the module system that is > the monster patch in jigsaw/jake forest into the JDK 9 main line. Isn't there any way to break it up into functional sections or stages that can be individually reviewed? -- - DML From alexandre.iline at oracle.com Wed Mar 2 17:48:29 2016 From: alexandre.iline at oracle.com (Alexandre Iline (Shura)) Date: Wed, 2 Mar 2016 09:48:29 -0800 Subject: RFR: JDK-8150998: Fix module dependences in java/lang tests Message-ID: Hi. Could you please take a look on a fix to add missing module dependencies for tests in java/lang. JDK9 changes: http://cr.openjdk.java.net/~shurailine/8150998/webrev.jdk9.01 Jake changes: http://cr.openjdk.java.net/~shurailine/8150998/webrev.jake.01 Shura. From daniel.fuchs at oracle.com Wed Mar 2 18:06:27 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 2 Mar 2016 19:06:27 +0100 Subject: RFR: JDK-8150998: Fix module dependences in java/lang tests In-Reply-To: References: Message-ID: <56D72BA3.3010905@oracle.com> On 02/03/16 18:48, Alexandre (Shura) Iline wrote: > Hi. > > Could you please take a look on a fix to add missing module dependencies for tests in java/lang. > > JDK9 changes: http://cr.openjdk.java.net/~shurailine/8150998/webrev.jdk9.01 > Jake changes: http://cr.openjdk.java.net/~shurailine/8150998/webrev.jake.01 > > Shura. > Hi Shura, I'm not sure I understand exactly the logic behind your proposed changes. I see for instance that you added @modules java.logging to tests that import java.util.logging APIs, but then removed @modules java.management to tests that are importing java.lang.management APIs? In what concern changes to the logging tests, there's a small inconsistency: I see that most of the test are using a single @modules clause, except for this one which has two @modules: http://cr.openjdk.java.net/~shurailine/8150998/webrev.jdk9.01/test/java/lang/System/LoggerFinder/internal/PlatformLoggerBridgeTest/PlatformLoggerBridgeTest.java.frames.html best regards, -- daniel From Roger.Riggs at Oracle.com Wed Mar 2 18:35:34 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 2 Mar 2016 13:35:34 -0500 Subject: RFR: JDK-8150998: Fix module dependences in java/lang tests In-Reply-To: <56D72BA3.3010905@oracle.com> References: <56D72BA3.3010905@oracle.com> Message-ID: <56D73276.6050207@Oracle.com> Hi Daniel, fyi, there is a new TEST.properties file for the java/lang/management tests that includes the needed @modules = jdk.management. Roger On 3/2/2016 1:06 PM, Daniel Fuchs wrote: > On 02/03/16 18:48, Alexandre (Shura) Iline wrote: >> Hi. >> >> Could you please take a look on a fix to add missing module >> dependencies for tests in java/lang. >> >> JDK9 changes: >> http://cr.openjdk.java.net/~shurailine/8150998/webrev.jdk9.01 >> Jake changes: >> http://cr.openjdk.java.net/~shurailine/8150998/webrev.jake.01 >> >> Shura. >> > > Hi Shura, > > I'm not sure I understand exactly the logic behind > your proposed changes. > > I see for instance that you added @modules java.logging to tests > that import java.util.logging APIs, but then removed > @modules java.management to tests that are importing > java.lang.management APIs? > > In what concern changes to the logging tests, there's a small > inconsistency: I see that most of the test are using a > single @modules clause, except for this one which has two @modules: > > http://cr.openjdk.java.net/~shurailine/8150998/webrev.jdk9.01/test/java/lang/System/LoggerFinder/internal/PlatformLoggerBridgeTest/PlatformLoggerBridgeTest.java.frames.html > > > best regards, > > -- daniel From alan.bateman at oracle.com Wed Mar 2 18:59:07 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 02 Mar 2016 18:59:07 +0000 Subject: hg: jigsaw/jake/jdk: Revert uses of addReads in java.desktop module Message-ID: <201603021859.u22Ix76v018574@aojmv0008.oracle.com> Changeset: becadcb5a0ee Author: alanb Date: 2016-03-02 19:00 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/becadcb5a0ee Revert uses of addReads in java.desktop module ! src/java.desktop/share/classes/com/sun/beans/decoder/FieldElementHandler.java ! src/java.desktop/share/classes/com/sun/beans/decoder/NewElementHandler.java ! src/java.desktop/share/classes/com/sun/beans/finder/InstanceFinder.java ! src/java.desktop/share/classes/com/sun/beans/introspect/PropertyInfo.java ! src/java.desktop/share/classes/com/sun/media/sound/JARSoundbankReader.java ! src/java.desktop/share/classes/java/awt/Toolkit.java ! src/java.desktop/share/classes/java/beans/Beans.java ! src/java.desktop/share/classes/java/beans/Introspector.java ! src/java.desktop/share/classes/java/beans/MetaData.java ! src/java.desktop/share/classes/java/beans/PropertyDescriptor.java ! src/java.desktop/share/classes/java/beans/Statement.java ! src/java.desktop/share/classes/javax/imageio/metadata/IIOMetadata.java ! src/java.desktop/share/classes/javax/imageio/spi/ImageReaderWriterSpi.java ! src/java.desktop/share/classes/javax/swing/JEditorPane.java ! src/java.desktop/share/classes/javax/swing/JTable.java ! src/java.desktop/share/classes/javax/swing/UIDefaults.java ! src/java.desktop/share/classes/javax/swing/UIManager.java ! src/java.desktop/share/classes/javax/swing/text/DefaultFormatter.java ! src/java.desktop/share/classes/javax/swing/text/NumberFormatter.java ! src/java.desktop/share/classes/javax/swing/text/html/ObjectView.java ! src/java.desktop/share/classes/sun/applet/AppletPanel.java ! src/java.desktop/share/classes/sun/awt/datatransfer/DataTransferer.java From alex.buckley at oracle.com Wed Mar 2 19:05:33 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 02 Mar 2016 11:05:33 -0800 Subject: Missing issue? - indexing In-Reply-To: References: Message-ID: <56D7397D.3000102@oracle.com> Rory, Could you please add Reflections and Scannotation to the Quality Outreach effort? The concern is not whether these tools understand the new JDK image or the modulepath. The concern is whether these tools make assumptions about the JDK's class loader hierarchy (Gradle was hit by this) and the JDK classes loaded by each loader (Eclipse was hit by this). Alex On 3/2/2016 4:40 AM, Stephen Colebourne wrote: > Tools like Reflections [1], Scannotaions [2] and many more [3] provide > the ability to find instances of annotations on the classpath. They > also provide the ability to find subclasses of an interface. This kind > of tooling is commonly needed by Java EE. Different tools use > different approaches to gather the information, but it is definitely > something that could be captured when building a module. At the very > least, it is important to ensure that these tools continue to work. > > Stephen > > > [1] https://github.com/ronmamo/reflections > [2] http://scannotation.sourceforge.net/ > [3] http://stackoverflow.com/questions/259140/scanning-java-annotations-at-runtime > From Alan.Bateman at oracle.com Wed Mar 2 19:12:50 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 2 Mar 2016 19:12:50 +0000 Subject: Need help testing the EA builds In-Reply-To: <56D719C8.5000405@redhat.com> References: <56D7002A.9000509@oracle.com> <56D719C8.5000405@redhat.com> Message-ID: <56D73B32.2000201@oracle.com> On 02/03/2016 16:50, David M. Lloyd wrote: > > Isn't there any way to break it up into functional sections or stages > that can be individually reviewed? > There source code is organized by module and there are also several repositories, so I think it should be manageable without needing to do fine grain slicing. -Alan. From christian.tornqvist at oracle.com Wed Mar 2 19:27:19 2016 From: christian.tornqvist at oracle.com (christian.tornqvist at oracle.com) Date: Wed, 02 Mar 2016 19:27:19 +0000 Subject: hg: jigsaw/jake/hotspot: Fixed missing @ignore Message-ID: <201603021927.u22JRJ61029591@aojmv0008.oracle.com> Changeset: e5d23d4695ea Author: ctornqvi Date: 2016-03-02 11:26 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e5d23d4695ea Fixed missing @ignore ! test/compiler/jvmci/compilerToVM/ExecuteInstalledCodeTest.java From mandy.chung at oracle.com Wed Mar 2 19:40:04 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 02 Mar 2016 19:40:04 +0000 Subject: hg: jigsaw/jake/jdk: Revert uses of addReads in java.management module Message-ID: <201603021940.u22Je45j004045@aojmv0008.oracle.com> Changeset: b3204d802108 Author: mchung Date: 2016-03-02 11:39 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b3204d802108 Revert uses of addReads in java.management module ! src/java.management/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java ! src/java.management/share/classes/com/sun/jmx/mbeanserver/MBeanInstantiator.java ! src/java.management/share/classes/javax/management/MBeanServerFactory.java ! src/java.management/share/classes/javax/management/remote/JMXConnectorFactory.java ! src/java.management/share/classes/sun/management/Agent.java ! src/java.management/share/classes/sun/management/MappedMXBeanType.java ! src/java.management/share/classes/sun/management/Util.java From alex.buckley at oracle.com Wed Mar 2 20:17:30 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 02 Mar 2016 12:17:30 -0800 Subject: Need help testing the EA builds In-Reply-To: <416b178c-b60f-491d-b05f-1e58b568254e@default> References: <56D7002A.9000509@oracle.com> <7bfb9090-4fef-400f-abef-bfc7a3e50b79@default> <56D71122.4040406@oracle.com> <416b178c-b60f-491d-b05f-1e58b568254e@default> Message-ID: <56D74A5A.4090208@oracle.com> On 3/2/2016 8:29 AM, Stephen Felts wrote: > Yes, you are correct. The rt.jar change and the classloading changes have caused many of these tools problems. I should have tried to separate the Jake from non-Jake problems. > I've also been entering bugs where possible. I entered them for gradle, jython, eclipselink, and findbugs for tools outside Oracle. > > Using upgrade, module, and patch files is clearly Jake as are the need to use exports. > Jmockit and Simplestub are I think partly related to Jake but it's hard to tell until we figure out the full problem. > Passing information to the Gradle daemon is Jake related (separate from the junit problem). Let's clarify that "Jake problems" arise for two very different reasons: 1. A limitation (usually deliberate, sometimes accidental) in a mechanism of the module system. 2. A policy decision by the JDK team during JDK modularization, implemented via a mechanism of the module system. Needing to use -XaddExports for JDK modules is due to (2). JEP 260 sets forth the policy of limiting access to non-standard, unstable, and unsupported APIs. The policy could have been set forth at any time in the last twenty years, and been implemented by (say) renaming internal packages in every major JDK release. It "just so happens" that the policy is now implemented via a mechanism of the module system (i.e. not exporting certain packages). Needing to use -upgrademodulepath and -Xpatch for JDK modules is due to (1). The module system is philosophically opposed to split packages, so attempting to augment packages in JDK modules by placing classes on the classpath doesn't work by design. We are aware that certain packages in the JDK (e.g. javax.annotation) are frequently augmented on the JDK 8 classpath by third party JARs (e.g. jsr305.jar), and that this implies widespread use of -Xpatch on JDK 9 ... this should be addressed by a policy of JDK modularization rather than a change to the module system proper. Alex From alexandre.iline at oracle.com Wed Mar 2 20:38:52 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Wed, 2 Mar 2016 12:38:52 -0800 Subject: RFR: JDK-8150998: Fix module dependences in java/lang tests In-Reply-To: <56D72BA3.3010905@oracle.com> References: <56D72BA3.3010905@oracle.com> Message-ID: <94650A68-282F-435D-B9C5-2BA959AFA0DD@oracle.com> > On Mar 2, 2016, at 10:06 AM, Daniel Fuchs wrote: > > On 02/03/16 18:48, Alexandre (Shura) Iline wrote: >> Hi. >> >> Could you please take a look on a fix to add missing module dependencies for tests in java/lang. >> >> JDK9 changes: http://cr.openjdk.java.net/~shurailine/8150998/webrev.jdk9.01 >> Jake changes: http://cr.openjdk.java.net/~shurailine/8150998/webrev.jake.01 >> >> Shura. >> > > Hi Shura, > > I'm not sure I understand exactly the logic behind > your proposed changes. > > I see for instance that you added @modules java.logging to tests > that import java.util.logging APIs, but then removed > @modules java.management to tests that are importing > java.lang.management APIs? Most of those tests were declaring dependencies to java.management, which is a compile-time dependency. What is actually needed for those tests to work is jdk.management module. So, the dependency declaration needed to be changed anyway. Instead of fixing every test, I have declared the dependency in a newly added TEST.properties file, and removed @modules from tests altogether. Module dependencies for a test are inherited from TEST.properties files above in the hierarchy, unless the test overrides @modules explicitly. > > In what concern changes to the logging tests, there's a small > inconsistency: I see that most of the test are using a > single @modules clause, except for this one which has two @modules: > > http://cr.openjdk.java.net/~shurailine/8150998/webrev.jdk9.01/test/java/lang/System/LoggerFinder/internal/PlatformLoggerBridgeTest/PlatformLoggerBridgeTest.java.frames.html Indeed! Thank you! Fixed: http://cr.openjdk.java.net/~shurailine/8150998/webrev.jdk9.02/ Shura > > best regards, > > -- daniel From alan.bateman at oracle.com Wed Mar 2 20:43:50 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 02 Mar 2016 20:43:50 +0000 Subject: hg: jigsaw/jake/jdk: Remove unused import Message-ID: <201603022043.u22Khose028822@aojmv0008.oracle.com> Changeset: 223bb29c8fcd Author: alanb Date: 2016-03-02 20:27 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/223bb29c8fcd Remove unused import ! src/java.management/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java ! src/java.management/share/classes/com/sun/jmx/mbeanserver/MBeanInstantiator.java From mandy.chung at oracle.com Wed Mar 2 21:06:41 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 02 Mar 2016 21:06:41 +0000 Subject: hg: jigsaw/jake/jaxws: Revert uses of addReads in jaxws/jaxb/jaf modules Message-ID: <201603022106.u22L6hGR009580@aojmv0008.oracle.com> Changeset: 1bb1addef965 Author: mchung Date: 2016-03-02 13:06 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/1bb1addef965 Revert uses of addReads in jaxws/jaxb/jaf modules ! src/java.activation/share/classes/javax/activation/MailcapCommandMap.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/ClassFactory.java - src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/Modules.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/model/annotation/LocatableAnnotation.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/model/impl/ClassInfoImpl.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeEnumLeafInfoImpl.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/ElementBeanInfoImpl.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/Accessor.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/org/jvnet/mimepull/FactoryFinder.java ! src/java.xml.bind/share/classes/javax/xml/bind/ContextFinder.java - src/java.xml.ws/share/classes/com/sun/xml/internal/ws/Modules.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/client/sei/StubAsyncHandler.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/db/glassfish/JAXBRIContextWrapper.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/fault/SOAPFaultBuilder.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/handler/HandlerChainsModel.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/util/InjectionPlan.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/util/ServiceFinder.java ! src/java.xml.ws/share/classes/javax/xml/soap/ServiceLoaderUtil.java ! src/java.xml.ws/share/classes/javax/xml/ws/spi/FactoryFinder.java From christian.tornqvist at oracle.com Wed Mar 2 21:35:48 2016 From: christian.tornqvist at oracle.com (christian.tornqvist at oracle.com) Date: Wed, 02 Mar 2016 21:35:48 +0000 Subject: hg: jigsaw/jake/hotspot: Fixed mistakes made in previous reverting of Hotspot test changes Message-ID: <201603022135.u22LZmKB021582@aojmv0008.oracle.com> Changeset: bbf3fff35cde Author: ctornqvi Date: 2016-03-02 13:34 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/bbf3fff35cde Fixed mistakes made in previous reverting of Hotspot test changes ! test/gc/g1/TestShrinkAuxiliaryData20.java ! test/gc/g1/TestStringDeduplicationTools.java ! test/runtime/ClassFile/UnsupportedClassFileVersion.java ! test/runtime/Unsafe/GetKlassPointerGetJavaMirror.java From mandy.chung at oracle.com Wed Mar 2 21:54:09 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 02 Mar 2016 21:54:09 +0000 Subject: hg: jigsaw/jake/jaxws: Minor cleanup Message-ID: <201603022154.u22Ls9Qh027356@aojmv0008.oracle.com> Changeset: c5206a2a4c9f Author: mchung Date: 2016-03-02 13:54 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/c5206a2a4c9f Minor cleanup ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/ElementBeanInfoImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/client/sei/StubAsyncHandler.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/db/glassfish/JAXBRIContextWrapper.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/fault/SOAPFaultBuilder.java ! src/java.xml.ws/share/classes/javax/xml/ws/spi/FactoryFinder.java From mandy.chung at oracle.com Wed Mar 2 22:03:40 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 2 Mar 2016 14:03:40 -0800 Subject: RFR: JDK-8150998: Fix module dependences in java/lang tests In-Reply-To: <94650A68-282F-435D-B9C5-2BA959AFA0DD@oracle.com> References: <56D72BA3.3010905@oracle.com> <94650A68-282F-435D-B9C5-2BA959AFA0DD@oracle.com> Message-ID: <1796B310-9483-4678-8C49-422EB1ECB57D@oracle.com> > On Mar 2, 2016, at 12:38 PM, Alexandre (Shura) Iline wrote: > > http://cr.openjdk.java.net/~shurailine/8150998/webrev.jdk9.02/ test/java/lang/instrument/MakeJAR2.sh -XaddExports should not be brought to jdk9. test/java/lang/management/ManagementFactory/TEST.properties Should it be moved to test/java/lang/management since all tests under it are testing java/lang/management? should this require java.management instead? I expect most tests only need java.management. What about test/javax/management and other tests for java.management module? Are you planning to migrate to use Test.properties gradually? Maybe good to it for the entire module at a time. Mandy From alexandre.iline at oracle.com Wed Mar 2 22:13:53 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Wed, 2 Mar 2016 14:13:53 -0800 Subject: RFR: JDK-8150998: Fix module dependences in java/lang tests In-Reply-To: <1796B310-9483-4678-8C49-422EB1ECB57D@oracle.com> References: <56D72BA3.3010905@oracle.com> <94650A68-282F-435D-B9C5-2BA959AFA0DD@oracle.com> <1796B310-9483-4678-8C49-422EB1ECB57D@oracle.com> Message-ID: > On Mar 2, 2016, at 2:03 PM, Mandy Chung wrote: > > >> On Mar 2, 2016, at 12:38 PM, Alexandre (Shura) Iline wrote: >> >> http://cr.openjdk.java.net/~shurailine/8150998/webrev.jdk9.02/ > > > test/java/lang/instrument/MakeJAR2.sh > -XaddExports should not be brought to jdk9. > > test/java/lang/management/ManagementFactory/TEST.properties > Should it be moved to test/java/lang/management since all tests under it are testing java/lang/management? > > should this require java.management instead? I expect most tests only need java.management. 10 of 11 tests in java/lang/management/ManagementFactory throw java.lang.NoClassDefFoundError: com/sun/management/internal/GarbageCollectorExtImpl when jdk.management is not available. java/lang/management/ManagementFactory/GetObjectName.java indeed works with java.management. Are you suggesting to get back to declaring dependencies in every test? That would include java/lang/management/ManagementFactory/GetObjectName.java into a run when java.management is present but not jdk.management. Shura > > What about test/javax/management and other tests for java.management module? Are you planning to migrate to use Test.properties gradually? Maybe good to it for the entire module at a time. > > Mandy From jonathan.gibbons at oracle.com Wed Mar 2 22:18:11 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 02 Mar 2016 14:18:11 -0800 Subject: RFR: JDK-8150998: Fix module dependences in java/lang tests In-Reply-To: <94650A68-282F-435D-B9C5-2BA959AFA0DD@oracle.com> References: <56D72BA3.3010905@oracle.com> <94650A68-282F-435D-B9C5-2BA959AFA0DD@oracle.com> Message-ID: <56D766A3.30906@oracle.com> On 03/02/2016 12:38 PM, Alexandre (Shura) Iline wrote: > So, the dependency declaration needed to be changed anyway. Instead of fixing every test, I have declared the dependency in a newly added TEST.properties file, and removed @modules from tests altogether. Stylistically, I think it is better for each test to overtly declare its module dependencies, instead of having folk scrounge around looking for TEST.properties files. -- Jon From david.lloyd at redhat.com Wed Mar 2 22:47:52 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 2 Mar 2016 16:47:52 -0600 Subject: Need help testing the EA builds In-Reply-To: <56D73B32.2000201@oracle.com> References: <56D7002A.9000509@oracle.com> <56D719C8.5000405@redhat.com> <56D73B32.2000201@oracle.com> Message-ID: <56D76D98.8070605@redhat.com> On 03/02/2016 01:12 PM, Alan Bateman wrote: > > > On 02/03/2016 16:50, David M. Lloyd wrote: >> >> Isn't there any way to break it up into functional sections or stages >> that can be individually reviewed? >> > There source code is organized by module and there are also several > repositories, so I think it should be manageable without needing to do > fine grain slicing. I am a bit more skeptical: I count a combined 2,928 files changed with 156,053 insertions and 51,363 deletions compared to the upstream jdk9/jdk9 trees. With a single blob of that size, is it realistic to expect that it can be reviewed sensibly? Using the most recent data from my git mirror I get this approximate breakdown (there are rounding errors in dirstat but this gives a good general idea): 19.4% hotspot/ 55.0% jdk/ 20.0% langtools/ The JDK patch alone is going to be nearly 100,000 lines of insertions and nearly 20,000 deletions. That's a pretty big patch. -- - DML From alexandre.iline at oracle.com Wed Mar 2 22:48:06 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Wed, 2 Mar 2016 14:48:06 -0800 Subject: RFR: JDK-8150998: Fix module dependences in java/lang tests In-Reply-To: <1796B310-9483-4678-8C49-422EB1ECB57D@oracle.com> References: <56D72BA3.3010905@oracle.com> <94650A68-282F-435D-B9C5-2BA959AFA0DD@oracle.com> <1796B310-9483-4678-8C49-422EB1ECB57D@oracle.com> Message-ID: > On Mar 2, 2016, at 2:03 PM, Mandy Chung wrote: > > >> On Mar 2, 2016, at 12:38 PM, Alexandre (Shura) Iline wrote: >> >> http://cr.openjdk.java.net/~shurailine/8150998/webrev.jdk9.02/ > > > test/java/lang/instrument/MakeJAR2.sh > -XaddExports should not be brought to jdk9. Oh, that?s right! I will move this file into the Jake part. Shura > > test/java/lang/management/ManagementFactory/TEST.properties > Should it be moved to test/java/lang/management since all tests under it are testing java/lang/management? > > should this require java.management instead? I expect most tests only need java.management. > > What about test/javax/management and other tests for java.management module? Are you planning to migrate to use Test.properties gradually? Maybe good to it for the entire module at a time. > > Mandy From mandy.chung at oracle.com Wed Mar 2 22:56:15 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 2 Mar 2016 14:56:15 -0800 Subject: RFR: JDK-8150998: Fix module dependences in java/lang tests In-Reply-To: References: <56D72BA3.3010905@oracle.com> <94650A68-282F-435D-B9C5-2BA959AFA0DD@oracle.com> <1796B310-9483-4678-8C49-422EB1ECB57D@oracle.com> Message-ID: > On Mar 2, 2016, at 2:13 PM, Alexandre (Shura) Iline wrote: > > >> On Mar 2, 2016, at 2:03 PM, Mandy Chung wrote: >> >> >>> On Mar 2, 2016, at 12:38 PM, Alexandre (Shura) Iline wrote: >>> >>> http://cr.openjdk.java.net/~shurailine/8150998/webrev.jdk9.02/ >> >> >> test/java/lang/instrument/MakeJAR2.sh >> -XaddExports should not be brought to jdk9. >> >> test/java/lang/management/ManagementFactory/TEST.properties >> Should it be moved to test/java/lang/management since all tests under it are testing java/lang/management? >> >> should this require java.management instead? I expect most tests only need java.management. > > 10 of 11 tests in java/lang/management/ManagementFactory throw > java.lang.NoClassDefFoundError: com/sun/management/internal/GarbageCollectorExtImpl > when jdk.management is not available. > Thanks for the stack trace you sent offline. I think it?s a bug. java.lang.management.ManagementFactory.getPlatformMXBeans() should work even if jdk.management is not present. Can you help file an issue? > java/lang/management/ManagementFactory/GetObjectName.java indeed works with java.management. Are you suggesting to get back to declaring dependencies in every test? I agree with Jon that declaring the module dependences in each test makes it explicitly but either way is fine with me. > That would include java/lang/management/ManagementFactory/GetObjectName.java into a run when java.management is present but not jdk.management. This reveals a bug. Mandy From alexandre.iline at oracle.com Wed Mar 2 23:04:23 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Wed, 2 Mar 2016 15:04:23 -0800 Subject: RFR: JDK-8150998: Fix module dependences in java/lang tests In-Reply-To: References: <56D72BA3.3010905@oracle.com> <94650A68-282F-435D-B9C5-2BA959AFA0DD@oracle.com> <1796B310-9483-4678-8C49-422EB1ECB57D@oracle.com> Message-ID: > On Mar 2, 2016, at 2:56 PM, Mandy Chung wrote: > > >> On Mar 2, 2016, at 2:13 PM, Alexandre (Shura) Iline wrote: >> >> >>> On Mar 2, 2016, at 2:03 PM, Mandy Chung wrote: >>> >>> >>>> On Mar 2, 2016, at 12:38 PM, Alexandre (Shura) Iline wrote: >>>> >>>> http://cr.openjdk.java.net/~shurailine/8150998/webrev.jdk9.02/ >>> >>> >>> test/java/lang/instrument/MakeJAR2.sh >>> -XaddExports should not be brought to jdk9. >>> >>> test/java/lang/management/ManagementFactory/TEST.properties >>> Should it be moved to test/java/lang/management since all tests under it are testing java/lang/management? >>> >>> should this require java.management instead? I expect most tests only need java.management. >> >> 10 of 11 tests in java/lang/management/ManagementFactory throw >> java.lang.NoClassDefFoundError: com/sun/management/internal/GarbageCollectorExtImpl >> when jdk.management is not available. >> > > Thanks for the stack trace you sent offline. > > I think it?s a bug. java.lang.management.ManagementFactory.getPlatformMXBeans() should work even if jdk.management is not present. Can you help file an issue? > >> java/lang/management/ManagementFactory/GetObjectName.java indeed works with java.management. Are you suggesting to get back to declaring dependencies in every test? > > I agree with Jon that declaring the module dependences in each test makes it explicitly but either way is fine with me. > >> That would include java/lang/management/ManagementFactory/GetObjectName.java into a run when java.management is present but not jdk.management. > > This reveals a bug. I will redo the fix with this new info. Shura > > Mandy From mandy.chung at oracle.com Wed Mar 2 23:30:06 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 2 Mar 2016 15:30:06 -0800 Subject: RFR: JDK-8150998: Fix module dependences in java/lang tests In-Reply-To: References: <56D72BA3.3010905@oracle.com> <94650A68-282F-435D-B9C5-2BA959AFA0DD@oracle.com> <1796B310-9483-4678-8C49-422EB1ECB57D@oracle.com> Message-ID: > On Mar 2, 2016, at 2:48 PM, Alexandre (Shura) Iline wrote: > > >> On Mar 2, 2016, at 2:03 PM, Mandy Chung wrote: >> >> >>> On Mar 2, 2016, at 12:38 PM, Alexandre (Shura) Iline wrote: >>> >>> http://cr.openjdk.java.net/~shurailine/8150998/webrev.jdk9.02/ >> >> >> test/java/lang/instrument/MakeJAR2.sh >> -XaddExports should not be brought to jdk9. > > Oh, that?s right! I will move this file into the Jake part. > Jake changes: http://cr.openjdk.java.net/~shurailine/8150998/webrev.jake.01 > test/java/lang/management/MemoryMXBean/PendingAllGC.sh test/java/lang/ref/CleanerTest.java - should the patch for these 2 tests be pushed to jdk9? Mandy From mandy.chung at oracle.com Wed Mar 2 23:32:35 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 02 Mar 2016 23:32:35 +0000 Subject: hg: jigsaw/jake/jdk: new tests to verify permission check for Class::forName Message-ID: <201603022332.u22NWZPp003355@aojmv0008.oracle.com> Changeset: c919c57d5640 Author: mchung Date: 2016-03-02 15:32 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c919c57d5640 new tests to verify permission check for Class::forName ! src/java.base/share/classes/java/lang/Class.java ! test/java/lang/Class/forName/modules/TestDriver.java + test/java/lang/Class/forName/modules/policy.denied + test/java/lang/Class/forName/modules/src/m3/module-info.java + test/java/lang/Class/forName/modules/src/m3/p3/NoAccess.java + test/java/lang/Class/forName/modules/src/m3/p3/NoGetClassLoaderAccess.java + test/java/lang/Class/forName/modules/src/m3/p3/internal/Foo.java From mandy.chung at oracle.com Wed Mar 2 23:45:15 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 02 Mar 2016 23:45:15 +0000 Subject: hg: jigsaw/jake/nashorn: Remove legacy service config file Message-ID: <201603022345.u22NjFwO006911@aojmv0008.oracle.com> Changeset: e172426fb366 Author: mchung Date: 2016-03-02 15:45 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/e172426fb366 Remove legacy service config file - src/jdk.scripting.nashorn/share/classes/META-INF/MANIFEST.MF - src/jdk.scripting.nashorn/share/classes/META-INF/services/javax.script.ScriptEngineFactory ! src/jdk.scripting.nashorn/share/classes/module-info.java From mandy.chung at oracle.com Wed Mar 2 23:45:29 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 02 Mar 2016 23:45:29 +0000 Subject: hg: jigsaw/jake/jdk: Remove legacy service config file Message-ID: <201603022345.u22NjT9L007151@aojmv0008.oracle.com> Changeset: 8b5e89db9f26 Author: mchung Date: 2016-03-02 15:45 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8b5e89db9f26 Remove legacy service config file - src/java.base/share/classes/META-INF/services/java.nio.file.spi.FileSystemProvider From mandy.chung at oracle.com Thu Mar 3 00:50:46 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 03 Mar 2016 00:50:46 +0000 Subject: hg: jigsaw/jake/jdk: Restore service config file for jrtfs.jar Message-ID: <201603030050.u230okvE029753@aojmv0008.oracle.com> Changeset: c47be843032b Author: mchung Date: 2016-03-02 16:50 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c47be843032b Restore service config file for jrtfs.jar + src/java.base/share/classes/META-INF/services/java.nio.file.spi.FileSystemProvider From felix.yang at oracle.com Thu Mar 3 07:48:01 2016 From: felix.yang at oracle.com (Felix Yang) Date: Thu, 3 Mar 2016 15:48:01 +0800 Subject: RFR 8141609: Need test for jrtfs that runs on JDK 8 to target a JDK 9 image In-Reply-To: <56D54DD8.5060503@oracle.com> References: <56CBD497.9090609@oracle.com> <56CC6F5A.5090901@oracle.com> <56CC80A6.9020401@oracle.com> <56CEB135.2070005@oracle.com> <56CED599.6060307@oracle.com> <56D52CE2.9060107@oracle.com> <56D54DD8.5060503@oracle.com> Message-ID: <56D7EC31.5080701@oracle.com> Hi Alan and Sundar, please review the new webrev. Simplified the test app as discussed. http://cr.openjdk.java.net/~xiaofeya/8141609/webrev.02/ Thanks, Felix On 2016/3/1 16:07, Alan Bateman wrote: > > > On 01/03/2016 05:47, Felix Yang wrote: >> Hi Alan, >> please review the new webrev: >> http://cr.openjdk.java.net/~xiaofeya/8141609/webrev.02/ >> >> Major changes: >> 1. remove checking for 'java.version' in JrtfsTestMain and add new >> check for 'release' file >> 2. In order to avoid dup tests with Basic.java, add new >> BaseTest.java, which is a plain java app rather than testng tests. As >> stated before, only moved those tests more related with >> 'functionality', not contents. >> > This refactors the main unit test for jrtfs and means it can't use > newer APIs or language features. I'm interested in Sundar's view on > this but I think I would prefer to need to keep the test separate so > that it can compile to -target 8. Also I assume it just needs to do a > few sanity checks, like walk the file system. Once we have something > simple in place then we can add tests to it if needed. > > -Alan From rory.odonnell at oracle.com Thu Mar 3 08:48:31 2016 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Thu, 3 Mar 2016 08:48:31 +0000 Subject: Missing issue? - indexing In-Reply-To: References: Message-ID: <56D7FA5F.7030102@oracle.com> Alex, Sure, I will try to reach out to them. If you or anyone on the list has contacts they can share with me that would be great. Rgds,Rory On 02/03/2016 21:54, jigsaw-dev-request at openjdk.java.net wrote: > Message: 1 > Date: Wed, 02 Mar 2016 11:05:33 -0800 > From: Alex Buckley > To: rory.odonnell at oracle.com, jigsaw-dev > Subject: Re: Missing issue? - indexing > Message-ID: <56D7397D.3000102 at oracle.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > Rory, > > Could you please add Reflections and Scannotation to the Quality > Outreach effort? > > The concern is not whether these tools understand the new JDK image or > the modulepath. The concern is whether these tools make assumptions > about the JDK's class loader hierarchy (Gradle was hit by this) and the > JDK classes loaded by each loader (Eclipse was hit by this). > > Alex > > On 3/2/2016 4:40 AM, Stephen Colebourne wrote: >> Tools like Reflections [1], Scannotaions [2] and many more [3] provide >> the ability to find instances of annotations on the classpath. They >> also provide the ability to find subclasses of an interface. This kind >> of tooling is commonly needed by Java EE. Different tools use >> different approaches to gather the information, but it is definitely >> something that could be captured when building a module. At the very >> least, it is important to ensure that these tools continue to work. >> >> Stephen >> >> >> [1] https://github.com/ronmamo/reflections >> [2] http://scannotation.sourceforge.net/ >> [3] http://stackoverflow.com/questions/259140/scanning-java-annotations-at-runtime >> > -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland From Alan.Bateman at oracle.com Thu Mar 3 09:23:10 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 3 Mar 2016 09:23:10 +0000 Subject: Missing issue? - indexing In-Reply-To: <56D7FA5F.7030102@oracle.com> References: <56D7FA5F.7030102@oracle.com> Message-ID: <56D8027E.5040508@oracle.com> On 03/03/2016 08:48, Rory O'Donnell wrote: > Alex, > > Sure, I will try to reach out to them. > > If you or anyone on the list has contacts they can share with me that > would be great. > > Rgds,Rory I don't know have contacts but just to add to Alex's mail where he said: "The concern is whether these tools make assumptions about the JDK's class loader hierarchy (Gradle was hit by this) and the JDK classes loaded by each loader (Eclipse was hit by this). " It is important to flush out these issues. In the Gradle case then it assumed the system class loader is a URLClassLoader [1]. In the Eclipse case then it seems to be delegating directly to the boot loader and so was tripped up by changes to move non-core classes out of the boot loader [2]. I don't like pointing out specific issue in other tools/libraries of course but they are useful examples that other projects might relate to. I have no doubt that there will be more of these cases like this, particularly the latter as we have moved many non-core modules, including all of the "morally EE" modules, to the extension class loader. -Alan [1] https://issues.gradle.org/browse/GRADLE-3287 [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=466683 From Alan.Bateman at oracle.com Thu Mar 3 14:38:53 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 3 Mar 2016 14:38:53 +0000 Subject: Initial webrev with changes for JDK 9 Message-ID: <56D84C7D.9020006@oracle.com> I've pushed webrevs with the initial changes for JDK 9 here: http://cr.openjdk.java.net/~alanb/8142968/0/ This is a snapshot of what is currently in the jigsaw/jake forest. Our mission over the next few weeks is to iterate on this and get it to the point where we + Reviewers are happy that it is a reasonable/acceptable state to bring into JDK 9. We will need to set a deadline so that we can plan the integration, more on this soon. As per our previous milestones (JEP 201 and JEP 220) then we'll ask that the integration from jdk9/dev to master skip a beat so that the module system is the only change in master that week. It's important to remember that the initial push to JDK 9 is exactly that, it's not the final bits. There are many areas that still need work, there are many open issues, there is an ongoing JSR, and of course there will be ongoing feedback that will help us get it right. Another important thing to say is this isn't a module system design or API review. Questions/comments on the module system design can be brought up here of course but we might have to punt to jpms-spec-comments on topics that involve JSR discussions. For the API then I expect it will go through many iterations, as every good API does. The following is a summary of what is in each repository, this might help to get a feel for where the implementation is currently at. ** top-level repository ** Most of the build changes have already been pushed to JDK 9 as part of JEP 201 and subsequent iteration. There are some additional jake-specific build changes, most of it is in the top-level repository with some changes in other repositories too. Of significance is that the temporary modules.xml document in the root directory is gone, this has been replaced by a module declaration in the source code of each module. The other significant thing is that the build creates a packaged module for each standard and JDK module. It also uses the jlink tool to create the JDK and JRE run-time images. Erik Joelsson will take point for all the build changes, with help from Reviewers from the build group. ** hotspot repository ** At a high-level, the changes in hotspot repository adds support for modules to the virtual machine with access control extended to modules. Startup has been significantly reworked into a sequence of phases, akin to runlevels, so that the module system is initialized before any code outside of the base module is loaded. What we used to know as the boot class path is mostly gone except for agent and -Xbootclasspath/a cases. Classes are instead loaded from modules defined to boot loader. There is also support for patching modules for testing and ad hoc needs. JNI has new functions, as has JVM TI with initial support for debuggers and agents that instrument code in modules. There is additional work on JVM TI in progress so expect to see more in later webrevs. There are a number of diagnosability improvements, include improved exception messages and support for module details in stack traces. There are many new tests. There are also updates to many existing tests. Christian Tornqvist is planning to bring at least some of test changes into jdk9/dev so we should see the patch reduce a bit once we sync up. Lois Foltan will take point on the hotspot repository, she has lined up several Reviewers in the hotspot group to help. ** langtools repository ** As expected, the javac compiler is significantly updated to support compilation containing module declarations. The javadoc tool and doclet code has also involve significant changes. When compiling then there are several new command-line options, support for module paths, and new compilation modes. JEP 261 has useful descriptions. The jdeps tool has been upgraded with many new options. The javap tool has also been updated. This repository also has the initial updates to the javax.tools and javax.lang.model APIs. There are a lot of updates to existing tests in the webrev and many new tests too. Jonathan Gibbons will take point for the langtools repository and I expect will use Reviewers from the compiler group to help get through this. ** jdk repository ** There are a lot of changes in this repository. One of the most obvious is that there is a module-info.java source file in each module's directory. There is a new java.lang.module API to support module descriptors and to create configurations of modules. There are new APIs in java.lang.reflect to represent modules and layers of modules. There are is a lot of support code for the module system itself, for example ModuleBootstrap is the class that creates the configuration and creates the boot layer. The application and extension class loaders have been replaced with a new implementation based on BuiltinClassLoader that supports loading classes/resources from modules (in addition to the class path). Note that there are no changes to class loader hierarchy and no changes to visibility except that some non-core modules are no longer defined to the boot loader. In java.lang then Class and ClassLoader have several updates and new methods to support modules. The legacy Package API and javadoc has also been overhauled. The System class has been updated to support the initialization of the module system. Core reflection has been updated so that access control is aligned with the Java Language and VM, except that it assumes readability (a discussion point in the JSR at this time). Proxy has been significantly updated so that the package, module and accessibility of the generated proxy classes are in line with the accessibility of the proxy interfaces. The MethodHandle API has also been updated but I expect there will be changes soon on this, maybe additional lookup modes and changes when teleporting from one module to another (as things stand then all access is lost). The ServiceLoader API has been updated to support instantiating service providers that are deployed as modules. It also has new support for iterating over service providers in Layers. The ResourceBundle API has been significantly updated to support resources deployed as modules. There are also a lot of changes to the locale providers. This repository has the jlink tool (JEP 282) to assembly a set of modules as a modular run-time image (JEP 220). The jlink tool is invoked in the JDK build to create the JDK and JRE run-time images as I mentioned above. The jlink tool includes an experimental API for developing plugins that do transformations or optimizations at link-time. There are currently 11 plugins in the webrev, the most significant is the "installed-modules" plugin that generates code at link-time to speed up the reconstitution of module descriptors during startup. There are significant updates to the jimage container implementation and jrtfs. The most obvious that is there is now only one jimage container (named "modules") in the run-time image. The java launcher has been updated to support module paths and the other command line options described in JEP 261. The jar tool has been updated to support modules packaged as modular JAR files. It has also been refurbished with support for GNU style command line options. JDI and JDWP have been updated to allow debugger enumerate and introspect modules in the target VM. java.lang.instrument has initial updates to support agents that instrument code in modules. There are smaller changes in many others including updates to the logging API, the JMX implementation, Image I/O, JNDI and several others. Most of these changes are localized and should be straight-forward to understand (esp as the code is organized by module). There are lot of new tests. Some of the new tests aren't in the right location yet and we'll resolve that soon. There are fewer updates to existing tests that might be expected and this is because we've been able to get the changes to several thousand tests into JDK 9 in advance. Jim Laskey and Sundararajan Athijegannathan will take point for the jlink, jimage and jrtfs changes. For everything else then assume that Mandy Chung and I will take point for now. We have approached many jdk9 Reviewers to help get through this. ** nashorn repository ** Nashorn has been updated to work with a modular runtime, including spinning dynamic modules. This is the first of the dynamic languages to get working and we'll need to learn from this to see what might potentially need to exposed further in the API. Sundar will take point on this, with Reviewers from the nashorn project. ** jaxp repository ** JAXP has a small update to support the XSLTC generating of translets in modules at runtime. We need to re-visit this at some point to generate the translets in their own layer. ** jaxws repository ** Most of the changes to JAXB and JAX-WS to work with modules are already in JDK 9 and pushed to the upstream Metro project. There are API changes so there will be updates to JSR 222 and JSR 224. The residual changes in the jaxws repository are mostly handling of resources in modules. ** corba repository ** No changes here except the module declaration. I think that is mostly it for now. I will published new webrevs periodically to take account of the ongoing changes. On wider communication, then we'll send mail to jdk9-dev soon to make everyone working on the JDK 9 project aware that we are starting to plan the integration into JDK 9. -Alan. From sander.mak at luminis.eu Thu Mar 3 15:38:46 2016 From: sander.mak at luminis.eu (Sander Mak) Date: Thu, 3 Mar 2016 15:38:46 +0000 Subject: jlink and automatic modules Message-ID: <8C206F17-19BB-46E9-9A6B-15FAC4D17F56@luminis.eu> I'm experimenting with an application that consists of proper modules (with module-info), where one module A requires an automatic module Lib. After creating modular jars for my application modules and running the application with both the application modules and the non-modular Lib-jar on the modulepath, everything works as expected. Now, I try to create a runtime image for my application using jlink. I add module A using --addmods, and again put both my application modules and the Lib-jar on the --modulepath of jlink. This results in the following error: > Error: jdk.tools.jlink.plugin.PluginException: module-info.class not found for Lib module Is this expected behavior? -- Sander From Alan.Bateman at oracle.com Thu Mar 3 15:50:46 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 3 Mar 2016 15:50:46 +0000 Subject: jlink and automatic modules In-Reply-To: <8C206F17-19BB-46E9-9A6B-15FAC4D17F56@luminis.eu> References: <8C206F17-19BB-46E9-9A6B-15FAC4D17F56@luminis.eu> Message-ID: <56D85D56.7030109@oracle.com> On 03/03/2016 15:38, Sander Mak wrote: > I'm experimenting with an application that consists of proper modules (with module-info), where one module A requires an automatic module Lib. After creating modular jars for my application modules and running the application with both the application modules and the non-modular Lib-jar on the modulepath, everything works as expected. > > Now, I try to create a runtime image for my application using jlink. I add module A using --addmods, and again put both my application modules and the Lib-jar on the --modulepath of jlink. This results in the following error: > >> Error: jdk.tools.jlink.plugin.PluginException: module-info.class not found for Lib module > Is this expected behavior? > There isn't currently any support for automatic modules at link-time. We have an issue tracking it [1] but I think requires thinking through whether it's the right thing to do. -Alan [1] https://bugs.openjdk.java.net/browse/JDK-8130047 From sander.mak at luminis.eu Thu Mar 3 16:04:43 2016 From: sander.mak at luminis.eu (Sander Mak) Date: Thu, 3 Mar 2016 16:04:43 +0000 Subject: jlink and automatic modules In-Reply-To: <56D85D56.7030109@oracle.com> References: <8C206F17-19BB-46E9-9A6B-15FAC4D17F56@luminis.eu> <56D85D56.7030109@oracle.com> Message-ID: <2E18832D-CC36-40FA-AAB0-6F4946C6ECEE@luminis.eu> > On 03 Mar 2016, at 16:50, Alan Bateman wrote: > > There isn't currently any support for automatic modules at link-time. We have an issue tracking it [1] but I think requires thinking through whether it's the right thing to do. Thanks, that explains it. The difference in behavior between the two modulepaths threw me off for a bit. Whether it's the right thing to do almost sounds more like a philosophical rather than a technical discussion? -- Sander From lois.foltan at oracle.com Thu Mar 3 17:04:31 2016 From: lois.foltan at oracle.com (lois.foltan at oracle.com) Date: Thu, 03 Mar 2016 17:04:31 +0000 Subject: hg: jigsaw/jake/hotspot: Trivial change to fix cosmetic difference in 2 files between jigsaw and JDK 9. Message-ID: <201603031704.u23H4Vnr002431@aojmv0008.oracle.com> Changeset: 89f7ea11f0cd Author: lfoltan Date: 2016-03-03 11:37 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/89f7ea11f0cd Trivial change to fix cosmetic difference in 2 files between jigsaw and JDK 9. ! make/bsd/makefiles/mapfile-vers-darwin-debug ! make/solaris/makefiles/mapfile-vers From harold.seigel at oracle.com Thu Mar 3 17:09:36 2016 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Thu, 03 Mar 2016 17:09:36 +0000 Subject: hg: jigsaw/jake/hotspot: Change test because class BootLoader was moved to package jdk.internal.loader Message-ID: <201603031709.u23H9aDc004916@aojmv0008.oracle.com> Changeset: 870fb65a6dd1 Author: hseigel Date: 2016-03-03 11:43 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/870fb65a6dd1 Change test because class BootLoader was moved to package jdk.internal.loader ! test/runtime/getSysPackage/GetSysPkgTest.java From alexandre.iline at oracle.com Thu Mar 3 20:11:11 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Thu, 3 Mar 2016 12:11:11 -0800 Subject: RFR: JDK-8150998: Fix module dependences in java/lang tests In-Reply-To: References: Message-ID: <5ED082EF-F85A-4A4A-8804-16EA849E5685@oracle.com> Hi. Could you please have another look on the webrev. http://cr.openjdk.java.net/~shurailine/8150998/webrev.jake.03/ http://cr.openjdk.java.net/~shurailine/8150998/webrev.jdk9.03/ I have reverted changes to java/lang/management tests for now, until resolution of https://bugs.openjdk.java.net/browse/JDK-8151099. I have addressed all the comments except moving the fix of test/java/lang/management/MemoryMXBean/PendingAllGC.sh to JDK9, as this test is already different in JDK9 and Jake, so a fix in JDK9 will be overridden. Shura > On Mar 2, 2016, at 9:48 AM, Alexandre (Shura) Iline wrote: > > Hi. > > Could you please take a look on a fix to add missing module dependencies for tests in java/lang. > > JDK9 changes: http://cr.openjdk.java.net/~shurailine/8150998/webrev.jdk9.01 > Jake changes: http://cr.openjdk.java.net/~shurailine/8150998/webrev.jake.01 > > Shura. From mandy.chung at oracle.com Thu Mar 3 21:19:34 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 03 Mar 2016 21:19:34 +0000 Subject: hg: jigsaw/jake: 8 new changesets Message-ID: <201603032119.u23LJYXu029302@aojmv0008.oracle.com> Changeset: 623e45a43ff3 Author: ihse Date: 2016-02-22 11:22 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/623e45a43ff3 8150203: Incremental update from build-infra project Reviewed-by: erikj ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/libraries.m4 ! common/autoconf/spec.gmk.in ! make/Init.gmk ! make/common/NativeCompilation.gmk Changeset: 900e2e405414 Author: simonis Date: 2016-02-22 11:27 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/900e2e405414 8150197: Integrate AIX fixes from build-infra Reviewed-by: erikj ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! make/common/NativeCompilation.gmk Changeset: 4040949857df Author: ihse Date: 2016-02-23 21:43 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/4040949857df 8150257: Remove softfloat lib support Reviewed-by: dholmes, erikj ! make/common/NativeCompilation.gmk Changeset: 958ccf794051 Author: lana Date: 2016-02-25 11:27 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/958ccf794051 Merge Changeset: c7be2a78c31b Author: michaelm Date: 2016-02-25 23:00 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/c7be2a78c31b 8087112: HTTP API and HTTP/1.1 implementation Reviewed-by: alanb, chegar, coffeys, psandoz, rriggs ! make/common/CORE_PKGS.gmk ! modules.xml Changeset: 906d3d2cbd3a Author: henryjen Date: 2016-03-02 21:50 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/906d3d2cbd3a Merge ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! make/common/CORE_PKGS.gmk ! make/common/NativeCompilation.gmk Changeset: 83fe2455dcc1 Author: lana Date: 2016-03-03 12:25 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/83fe2455dcc1 Added tag jdk-9+108 for changeset c7be2a78c31b ! .hgtags Changeset: 019e092d159d Author: mchung Date: 2016-03-03 12:37 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/019e092d159d Merge From mandy.chung at oracle.com Thu Mar 3 21:19:39 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 03 Mar 2016 21:19:39 +0000 Subject: hg: jigsaw/jake/corba: 2 new changesets Message-ID: <201603032119.u23LJd4n029438@aojmv0008.oracle.com> Changeset: b75afa17aefe Author: lana Date: 2016-03-03 12:25 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/b75afa17aefe Added tag jdk-9+108 for changeset 84f2862a25eb ! .hgtags Changeset: 9ba71f9ac61d Author: mchung Date: 2016-03-03 12:37 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/9ba71f9ac61d Merge From mandy.chung at oracle.com Thu Mar 3 21:19:50 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 03 Mar 2016 21:19:50 +0000 Subject: hg: jigsaw/jake/hotspot: 56 new changesets Message-ID: <201603032119.u23LJpvj029582@aojmv0008.oracle.com> Changeset: 45c738cde513 Author: ihse Date: 2016-02-23 21:44 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/45c738cde513 8150257: Remove softfloat lib support Reviewed-by: dholmes, erikj ! make/bsd/makefiles/arm.make Changeset: ddd51ea1a9b0 Author: thartmann Date: 2016-02-10 15:24 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ddd51ea1a9b0 8149123: [TESTBUG] compiler/loopopts/superword/SumRed* tests running on non-x86 platforms Summary: Restricted test execution to supported archs. Reviewed-by: kvn Contributed-by: Jamsheed Mohammed ! test/compiler/loopopts/superword/ProdRed_Double.java ! test/compiler/loopopts/superword/ProdRed_Float.java ! test/compiler/loopopts/superword/ProdRed_Int.java ! test/compiler/loopopts/superword/ReductionPerf.java ! test/compiler/loopopts/superword/SumRedSqrt_Double.java ! test/compiler/loopopts/superword/SumRed_Double.java ! test/compiler/loopopts/superword/SumRed_Float.java ! test/compiler/loopopts/superword/SumRed_Int.java ! test/compiler/loopopts/superword/SumRed_Long.java Changeset: 69fc70ea2f4e Author: shade Date: 2016-02-10 15:58 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/69fc70ea2f4e 8149356: Leftover from JDK-8141044: UseNewCode usage Reviewed-by: vlivanov ! src/share/vm/c1/c1_Canonicalizer.cpp Changeset: 306affd7e6c9 Author: shade Date: 2016-02-10 16:31 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/306affd7e6c9 Merge Changeset: b038c3bea5a4 Author: twisti Date: 2016-02-10 11:23 -1000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b038c3bea5a4 8149415: [AArch64] implement JVMCI CodeInstaller Reviewed-by: aph, kvn ! src/cpu/aarch64/vm/jvmciCodeInstaller_aarch64.cpp ! src/cpu/aarch64/vm/nativeInst_aarch64.cpp ! src/cpu/aarch64/vm/nativeInst_aarch64.hpp ! src/jdk.vm.ci/share/classes/jdk.vm.ci.aarch64/src/jdk/vm/ci/aarch64/AArch64.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot.aarch64/src/jdk/vm/ci/hotspot/aarch64/AArch64HotSpotRegisterConfig.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot.amd64/src/jdk/vm/ci/hotspot/amd64/AMD64HotSpotRegisterConfig.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot.sparc/src/jdk/vm/ci/hotspot/sparc/SPARCHotSpotRegisterConfig.java Changeset: 1f62d2e8308f Author: thartmann Date: 2016-02-11 11:15 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1f62d2e8308f 8145700: Uninitialised variable in macroAssembler_x86.cpp:7038 Summary: Added missing local variable initializations. Reviewed-by: kvn, vlivanov, thartmann, mcberg Contributed-by: Rahul Raghavan ! src/cpu/x86/vm/macroAssembler_x86.cpp Changeset: a43579055b3c Author: twisti Date: 2016-02-11 11:32 -1000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a43579055b3c 8149695: [JVMCI] add missing Checkstyle configuration file Reviewed-by: kvn + src/jdk.vm.ci/share/classes/jdk.vm.ci.services/.checkstyle_checks.xml Changeset: e8d72190f6ba Author: twisti Date: 2016-02-11 12:29 -1000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e8d72190f6ba 8149689: [JVMCI] CodeInstaller::pd_patch_DataSectionReference should be able to throw exceptions Reviewed-by: kvn ! src/cpu/aarch64/vm/jvmciCodeInstaller_aarch64.cpp ! src/cpu/ppc/vm/jvmciCodeInstaller_ppc.cpp ! src/cpu/sparc/vm/jvmciCodeInstaller_sparc.cpp ! src/cpu/x86/vm/jvmciCodeInstaller_x86.cpp ! src/share/vm/jvmci/jvmciCodeInstaller.cpp ! src/share/vm/jvmci/jvmciCodeInstaller.hpp Changeset: 3769c85083ca Author: thartmann Date: 2016-02-12 12:18 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3769c85083ca 8148564: compiler/intrinsics/string/TestStringIntrinsics2.java times out Summary: Test should not run with -Xcomp because MaxInlineSize is large. Reviewed-by: kvn, simonis ! test/compiler/intrinsics/string/TestStringIntrinsics2.java Changeset: 894c8b63e200 Author: roland Date: 2016-02-03 12:36 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/894c8b63e200 8143542: C2 doesn't eliminate identical checks Summary: Two identical Ifs back to back can be merged Reviewed-by: kvn ! src/share/vm/opto/castnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp Changeset: 5fefcbeda616 Author: mcberg Date: 2016-02-12 16:12 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5fefcbeda616 8149421: Vectorized Post Loops Summary: add vectorised post loop for counted loops with vectors. Reviewed-by: kvn ! src/cpu/aarch64/vm/c2_globals_aarch64.hpp ! src/cpu/ppc/vm/c2_globals_ppc.hpp ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c2_globals_x86.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/superword.cpp Changeset: a63cf6a69972 Author: roland Date: 2016-02-11 12:42 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a63cf6a69972 8149543: range check CastII nodes should not be split through Phi Summary: splitting range check CastIIs through loop induction Phi prevents further optimizations Reviewed-by: kvn, mcberg ! src/share/vm/opto/loopopts.cpp Changeset: 233e1f5a4279 Author: thartmann Date: 2016-02-15 11:52 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/233e1f5a4279 Merge ! src/cpu/x86/vm/macroAssembler_x86.cpp - src/share/vm/gc/g1/concurrentMark.cpp - src/share/vm/gc/g1/concurrentMark.hpp - src/share/vm/gc/g1/concurrentMark.inline.hpp Changeset: 5e57f1e0424c Author: kshefov Date: 2016-02-15 14:31 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5e57f1e0424c 8149472: NPE when executing HotSpotConstantReflectionProvider::constantEquals with null first arg Reviewed-by: twisti, kvn, dnsimon ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotConstantReflectionProvider.java Changeset: 59c73358af32 Author: kshefov Date: 2016-02-15 14:32 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/59c73358af32 8149740: NPEs when executing some HotSpotConstantReflectionProvider with null args Reviewed-by: twisti, dnsimon ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotConstantReflectionProvider.java Changeset: a4dbb762e571 Author: kshefov Date: 2016-02-15 13:26 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a4dbb762e571 Merge Changeset: fbfe20c87c17 Author: roland Date: 2016-02-15 15:15 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/fbfe20c87c17 8149797: Compilation fails with "assert(in_hash) failed: node should be in igvn hash table" Summary: node replaced by dominating dead cast during parsing Reviewed-by: kvn ! src/share/vm/opto/castnode.cpp Changeset: b860ea3c1616 Author: vlivanov Date: 2016-02-15 20:02 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b860ea3c1616 8149141: Optimized build is broken Reviewed-by: kvn, kbarrett ! src/share/vm/gc/shared/memset_with_concurrent_readers.cpp ! src/share/vm/utilities/quickSort.cpp Changeset: 30b120bce29d Author: vlivanov Date: 2016-02-15 20:26 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/30b120bce29d 8138922: StubCodeDesc constructor publishes partially-constructed objects on StubCodeDesc::_list Reviewed-by: kvn, coleenp, dholmes ! src/share/vm/code/codeBlob.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/runtime/stubCodeGenerator.cpp ! src/share/vm/runtime/stubCodeGenerator.hpp ! src/share/vm/runtime/thread.cpp Changeset: 6f460a0b0600 Author: vlivanov Date: 2016-02-15 20:26 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6f460a0b0600 8148994: Replacing MH::invokeBasic with a direct call breaks LF customization Reviewed-by: jrose, redestad ! src/share/vm/opto/callGenerator.cpp Changeset: 6ac1feb0794c Author: vlivanov Date: 2016-02-15 18:42 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6ac1feb0794c Merge Changeset: 9cf33e51c2d4 Author: shade Date: 2016-02-15 23:45 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9cf33e51c2d4 8149813: Move trusted final field handling from C2 LoadNode::Value to shared code Reviewed-by: thartmann, kvn ! src/share/vm/ci/ciField.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/stringopts.cpp ! src/share/vm/opto/stringopts.hpp Changeset: 417cf2936379 Author: never Date: 2016-02-16 09:49 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/417cf2936379 8149969: [JVMCI] PrintNMethods is ignored for CompilerToVM.installCode when not called from the broker Reviewed-by: kvn ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/jvmci/jvmciEnv.cpp Changeset: ccc25f034f38 Author: thartmann Date: 2016-02-17 12:24 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ccc25f034f38 6378256: Performance problem with System.identityHashCode in client compiler Summary: Enabled C1 optimization to try pull out hashCode from object header, before calling into the VM. Reviewed-by: dlong, roland, thartmann Contributed-by: Rahul Raghavan ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp + src/cpu/x86/vm/sharedRuntime_x86.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/share/vm/runtime/sharedRuntime.hpp Changeset: cffca6de2c45 Author: never Date: 2016-02-17 09:57 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/cffca6de2c45 8150075: [JVMCI] expose reserved stack machinery and Inline flag in HotSpotVMConfig Reviewed-by: kvn, twisti ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedJavaMethod.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedJavaMethodImpl.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java ! src/share/vm/jvmci/vmStructs_jvmci.cpp Changeset: 3b58a1c9a466 Author: tschatzl Date: 2016-02-10 12:05 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3b58a1c9a466 8143220: Fix documentation of InitiatingHeapOccupancyPercent Summary: Adjust internal flag documentation to how it currently works. Reviewed-by: brutisso, jmasa, tamao ! src/share/vm/runtime/globals.hpp Changeset: 992cdaf21e93 Author: tschatzl Date: 2016-02-10 12:08 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/992cdaf21e93 8136854: G1 ConcurrentG1RefineThread::stop delays JVM shutdown for >150ms Summary: Decrease the default wait delay for mark thread initialization to accomodate very short running applications. Reviewed-by: tbenson, mgerdin ! src/share/vm/gc/shared/concurrentGCThread.cpp ! src/share/vm/gc/shared/concurrentGCThread.hpp ! src/share/vm/runtime/init.cpp Changeset: e3e5642da773 Author: tschatzl Date: 2016-02-10 12:32 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e3e5642da773 Merge Changeset: 71a634eeec42 Author: brutisso Date: 2016-02-10 12:56 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/71a634eeec42 8148992: VM can hang on exit if root region scanning is initiated but not executed Reviewed-by: tschatzl, pliden, jwilhelm ! src/share/vm/gc/g1/concurrentMarkThread.cpp ! src/share/vm/gc/g1/g1CollectedHeap.cpp ! src/share/vm/gc/g1/g1ConcurrentMark.cpp ! src/share/vm/gc/g1/g1ConcurrentMark.hpp Changeset: 70c9e56e4ace Author: brutisso Date: 2016-02-10 14:30 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/70c9e56e4ace Merge Changeset: 75f6573e9c44 Author: mikael Date: 2016-02-10 15:20 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/75f6573e9c44 8141491: Unaligned memory access in Bits.c Summary: Introduce alignment-safe Copy::conjoint_swap and j.i.m.Unsafe.copySwapMemory Reviewed-by: jrose, dholmes, psandoz ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/interfaceSupport.hpp ! src/share/vm/utilities/copy.cpp ! src/share/vm/utilities/copy.hpp Changeset: e6a78fdf8cff Author: dholmes Date: 2016-02-10 18:57 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e6a78fdf8cff 8145725: Remove the WorkAroundNPTLTimedWaitHang workaround Reviewed-by: ddmitriev, stuefe, dcubed ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/share/vm/runtime/globals.hpp Changeset: 43674df081a7 Author: dholmes Date: 2016-02-11 01:06 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/43674df081a7 Merge Changeset: 6411ec1cfbb6 Author: dholmes Date: 2016-02-10 22:22 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6411ec1cfbb6 8148987: [Linux] Allow building on older systems without CPU_ALLOC support Reviewed-by: dsamersoff, stuefe, dcubed ! src/os/linux/vm/os_linux.cpp Changeset: 231a9e1d77c1 Author: brutisso Date: 2016-02-11 08:55 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/231a9e1d77c1 8149541: Use log_error() instead of log_info() when verification reports a problem Reviewed-by: jwilhelm, tbenson ! src/share/vm/gc/cms/compactibleFreeListSpace.cpp ! src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc/g1/g1CollectedHeap.cpp ! src/share/vm/gc/g1/g1CollectorPolicy.cpp ! src/share/vm/gc/g1/g1HeapVerifier.cpp ! src/share/vm/gc/g1/heapRegion.cpp ! src/share/vm/gc/g1/satbMarkQueue.cpp ! src/share/vm/gc/g1/youngList.cpp Changeset: 7d9cce2e700b Author: brutisso Date: 2016-02-11 08:57 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7d9cce2e700b 8149542: Missing failure reporting in HeapRegion::verify Reviewed-by: tschatzl, jprovino ! src/share/vm/gc/g1/heapRegion.cpp Changeset: fc2c277bce14 Author: stuefe Date: 2016-02-11 02:39 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/fc2c277bce14 8149096: Remove unused code in methodComparator Summary: Remove unused code in methodComparator Reviewed-by: coleenp, sspitsyn, dholmes ! src/share/vm/prims/methodComparator.cpp ! src/share/vm/prims/methodComparator.hpp Changeset: 0e6c867c8418 Author: kevinw Date: 2016-02-08 15:46 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0e6c867c8418 8144957: Remove PICL warning message Summary: There is no need to print any error/warning message when a library needed for performance optimization is not found on the system Reviewed-by: poonam, kvn Contributed-by: Shafi Ahmad ! src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp Changeset: aafce3cb3c9a Author: kevinw Date: 2016-02-11 12:11 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/aafce3cb3c9a Merge Changeset: 1610a87dfa21 Author: david Date: 2016-02-11 16:49 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1610a87dfa21 8149648: Add number of regions to the G1HeapSummary event Reviewed-by: sjohanss, jwilhelm ! src/share/vm/gc/g1/g1CollectedHeap.cpp ! src/share/vm/gc/shared/gcHeapSummary.hpp ! src/share/vm/gc/shared/gcTraceSend.cpp ! src/share/vm/trace/trace.xml Changeset: 49f65299b140 Author: dholmes Date: 2016-02-11 15:43 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/49f65299b140 8149697: Fix for 8145725 is broken Summary: As per the existing comment we needed to check the saved 'index' instead Reviewed-by: gthornbr, dcubed, kbarrett ! src/os/linux/vm/os_linux.cpp Changeset: e840fab590ea Author: david Date: 2016-02-12 09:12 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e840fab590ea 8009538: [Event Request] Want events for tenuring distribution Reviewed-by: jwilhelm, sjohanss ! src/share/vm/gc/shared/ageTable.cpp + src/share/vm/gc/shared/ageTableTracer.cpp + src/share/vm/gc/shared/ageTableTracer.hpp ! src/share/vm/trace/trace.xml Changeset: 95e00dc4c516 Author: david Date: 2016-02-12 09:19 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/95e00dc4c516 8149650: Create a trace event for G1 heap region type transitions Reviewed-by: jwilhelm, sjohanss + src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shared/G1HeapRegionType.java + src/share/vm/gc/g1/g1HeapRegionTraceType.hpp ! src/share/vm/gc/g1/heapRegion.cpp ! src/share/vm/gc/g1/heapRegion.hpp + src/share/vm/gc/g1/heapRegionTracer.cpp + src/share/vm/gc/g1/heapRegionTracer.hpp ! src/share/vm/gc/g1/heapRegionType.cpp ! src/share/vm/gc/g1/heapRegionType.hpp ! src/share/vm/trace/trace.xml ! src/share/vm/trace/tracetypes.xml Changeset: 002843deba76 Author: dholmes Date: 2016-02-15 05:54 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/002843deba76 8147379: Investigate if ConvertSleepToYield still should be false by default on Sparc Reviewed-by: dcubed, sjohanss ! src/cpu/aarch64/vm/globals_aarch64.hpp ! src/cpu/ppc/vm/globals_ppc.hpp ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/zero/vm/globals_zero.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! test/runtime/CommandLine/VMDeprecatedOptions.java Changeset: 207b25527262 Author: brutisso Date: 2016-02-15 16:22 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/207b25527262 8149826: Concurrent misspelled in the CMS logging Reviewed-by: david ! src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp Changeset: 93a449cbce98 Author: dholmes Date: 2016-02-15 21:57 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/93a449cbce98 8149427: Remove .class files from the hotspot repo .hgignore file Reviewed-by: mikael, twisti ! .hgignore Changeset: 76bab013c21f Author: ehelin Date: 2016-02-15 15:55 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/76bab013c21f 8149820: Move G1YoungGenSizer to g1CollectorPolicy.cpp Reviewed-by: jwilhelm, tbenson ! src/share/vm/gc/g1/g1CollectorPolicy.cpp ! src/share/vm/gc/g1/g1CollectorPolicy.hpp Changeset: 50222fa5848f Author: dcubed Date: 2016-02-16 12:01 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/50222fa5848f Merge ! src/cpu/aarch64/vm/globals_aarch64.hpp ! src/share/vm/runtime/globals.hpp Changeset: 283bd3489681 Author: jwilhelm Date: 2016-02-18 18:10 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/283bd3489681 Merge ! src/share/vm/runtime/init.cpp Changeset: 1d51771bad5c Author: amurillo Date: 2016-02-18 15:19 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1d51771bad5c Merge Changeset: f14a0a890704 Author: amurillo Date: 2016-02-23 18:57 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f14a0a890704 Merge Changeset: 934f6793f5f7 Author: lana Date: 2016-02-25 11:27 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/934f6793f5f7 Merge Changeset: 49adfa2f0fe9 Author: henryjen Date: 2016-03-02 21:50 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/49adfa2f0fe9 Merge ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/share/vm/jvmci/jvmciEnv.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/trace/tracetypes.xml Changeset: 0b59275aed6d Author: henryjen Date: 2016-03-03 10:45 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0b59275aed6d Merge Changeset: 3e3a10fe9511 Author: lana Date: 2016-03-03 12:25 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3e3a10fe9511 Added tag jdk-9+108 for changeset 934f6793f5f7 ! .hgtags Changeset: 704359fcb38c Author: mchung Date: 2016-03-03 12:37 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/704359fcb38c Merge ! .hgtags - src/jdk.vm.ci/share/classes/META-INF/services/jdk.vm.ci.hotspot.HotSpotJVMCIBackendFactory - test/compiler/jsr292/NonInlinedCall/NonInlinedReinvoker.java - test/compiler/jvmci/common/CompilerToVMHelper.java - test/compiler/jvmci/common/PublicMetaspaceWrapperObject.java - test/compiler/jvmci/events/MetaAccessWrapper.java - test/runtime/BadObjectClass/Object.java - test/testlibrary/jdk/test/lib/PerfCounter.java - test/testlibrary/jdk/test/lib/PerfCounters.java From mandy.chung at oracle.com Thu Mar 3 21:19:54 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 03 Mar 2016 21:19:54 +0000 Subject: hg: jigsaw/jake/jaxp: 6 new changesets Message-ID: <201603032119.u23LJs22029637@aojmv0008.oracle.com> Changeset: 95c223e6eaf0 Author: joehw Date: 2016-02-22 11:00 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/95c223e6eaf0 8149915: enabling validate-annotations feature for xsd schema with annotation causes NPE Reviewed-by: joehw Contributed-by: christoph.langer at sap.com ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XML11DTDScannerImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLDTDScannerImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLDocumentScannerImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLNSDocumentScannerImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLScanner.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSAttributeChecker.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDHandler.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/XML11Configuration.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/HTTPInputSource.java + test/javax/xml/jaxp/unittest/validation/Bug8149915.xsd + test/javax/xml/jaxp/unittest/validation/SchemaTest.java Changeset: 264df5d957cd Author: clanger Date: 2016-02-24 19:25 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/264df5d957cd 8150470: JCK: api/xsl/conf/copy/copy19 test failure Reviewed-by: joehw, aefimov ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java Changeset: 3b9fa8b14914 Author: lana Date: 2016-02-25 11:27 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/3b9fa8b14914 Merge Changeset: 94b08a4d8fcc Author: henryjen Date: 2016-03-02 21:50 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/94b08a4d8fcc Merge Changeset: 24e247ee1fff Author: lana Date: 2016-03-03 12:25 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/24e247ee1fff Added tag jdk-9+108 for changeset 3b9fa8b14914 ! .hgtags Changeset: b78ff3e8c408 Author: mchung Date: 2016-03-03 12:37 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/b78ff3e8c408 Merge From mandy.chung at oracle.com Thu Mar 3 21:19:57 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 03 Mar 2016 21:19:57 +0000 Subject: hg: jigsaw/jake/jaxws: 2 new changesets Message-ID: <201603032119.u23LJveZ029735@aojmv0008.oracle.com> Changeset: a4c1ffe5fdec Author: lana Date: 2016-03-03 12:25 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/a4c1ffe5fdec Added tag jdk-9+108 for changeset 513eb2e432f6 ! .hgtags Changeset: 364f3dc30f72 Author: mchung Date: 2016-03-03 12:37 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/364f3dc30f72 Merge From mandy.chung at oracle.com Thu Mar 3 21:20:08 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 03 Mar 2016 21:20:08 +0000 Subject: hg: jigsaw/jake/jdk: 31 new changesets Message-ID: <201603032120.u23LKAMp029972@aojmv0008.oracle.com> Changeset: b9b28d7137cd Author: ihse Date: 2016-02-22 11:23 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b9b28d7137cd 8150203: Incremental update from build-infra project Reviewed-by: erikj ! make/gensrc/GensrcMisc.gmk ! make/lib/Awt2dLibraries.gmk ! make/lib/CoreLibraries.gmk ! make/lib/Lib-java.instrument.gmk ! make/lib/Lib-jdk.jdi.gmk ! make/lib/Lib-jdk.jdwp.agent.gmk ! make/src/classes/build/tools/dtdbuilder/DTDParser.java Changeset: 0b0518bff70c Author: amlu Date: 2016-02-23 09:52 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0b0518bff70c 8149154: tools/pack200/Pack200Test.java failed with NullPointerException Reviewed-by: ksrini ! test/tools/pack200/Pack200Test.java ! test/tools/pack200/Utils.java Changeset: 4d1292a702b8 Author: mhaupt Date: 2016-02-23 07:17 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4d1292a702b8 8150360: augment/correct MethodHandle API documentation Reviewed-by: psandoz ! src/java.base/share/classes/java/lang/invoke/MethodHandle.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java Changeset: 8096d018a9a5 Author: peytoia Date: 2016-02-23 17:09 +0900 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8096d018a9a5 8074411: Describe "minor unit" and/or "default fraction digits" in Currency class' javadoc clearly Reviewed-by: naoto, okutsu, peytoia Contributed-by: Nishit Jain ! src/java.base/share/classes/java/util/Currency.java Changeset: 9d536355b828 Author: mhaupt Date: 2016-02-23 09:49 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9d536355b828 8143410: augment pseudo-code descriptions in MethodHandles API Reviewed-by: psandoz ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java Changeset: f92af283ab18 Author: alanb Date: 2016-02-23 17:41 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f92af283ab18 6432031: Add support for SO_REUSEPORT Reviewed-by: alanb, simonis, chegar Contributed-by: yingqi.lu at intel.com ! make/mapfiles/libnet/mapfile-vers ! make/mapfiles/libnio/mapfile-linux ! make/mapfiles/libnio/mapfile-macosx ! make/mapfiles/libnio/mapfile-solaris ! make/src/native/genconstants/ch/genSocketOptionRegistry.c ! src/java.base/share/classes/java/net/AbstractPlainDatagramSocketImpl.java ! src/java.base/share/classes/java/net/AbstractPlainSocketImpl.java ! src/java.base/share/classes/java/net/DatagramSocketImpl.java ! src/java.base/share/classes/java/net/MulticastSocket.java ! src/java.base/share/classes/java/net/SocketImpl.java ! src/java.base/share/classes/java/net/SocketOptions.java ! src/java.base/share/classes/java/net/StandardSocketOptions.java ! src/java.base/share/classes/jdk/net/Sockets.java ! src/java.base/share/classes/sun/nio/ch/AsynchronousServerSocketChannelImpl.java ! src/java.base/share/classes/sun/nio/ch/AsynchronousSocketChannelImpl.java ! src/java.base/share/classes/sun/nio/ch/DatagramChannelImpl.java ! src/java.base/share/classes/sun/nio/ch/Net.java ! src/java.base/share/classes/sun/nio/ch/ServerSocketChannelImpl.java ! src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java ! src/java.base/share/native/libnet/net_util.c ! src/java.base/share/native/libnet/net_util.h ! src/java.base/unix/classes/java/net/PlainDatagramSocketImpl.java ! src/java.base/unix/classes/java/net/PlainSocketImpl.java ! src/java.base/unix/native/libnet/PlainDatagramSocketImpl.c ! src/java.base/unix/native/libnet/SdpSupport.c + src/java.base/unix/native/libnet/SocketImpl.c ! src/java.base/unix/native/libnet/net_util_md.c ! src/java.base/unix/native/libnet/net_util_md.h ! src/java.base/unix/native/libnio/ch/Net.c ! src/java.base/unix/native/libnio/ch/nio_util.h ! src/java.base/windows/classes/java/net/DualStackPlainDatagramSocketImpl.java ! src/java.base/windows/classes/java/net/DualStackPlainSocketImpl.java ! src/java.base/windows/classes/java/net/PlainSocketImpl.java ! src/java.base/windows/classes/java/net/TwoStacksPlainDatagramSocketImpl.java ! src/java.base/windows/classes/java/net/TwoStacksPlainSocketImpl.java + src/java.base/windows/native/libnet/SocketImpl.c ! src/java.base/windows/native/libnet/net_util_md.c ! src/java.base/windows/native/libnet/net_util_md.h ! src/java.base/windows/native/libnio/ch/Net.c ! test/java/net/SocketOption/OptionsTest.java ! test/java/nio/channels/AsynchronousServerSocketChannel/Basic.java ! test/java/nio/channels/AsynchronousSocketChannel/Basic.java ! test/java/nio/channels/DatagramChannel/SocketOptionTests.java ! test/java/nio/channels/ServerSocketChannel/SocketOptionTests.java Changeset: c92ae3d0e6a3 Author: naoto Date: 2016-02-23 10:51 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c92ae3d0e6a3 8150434: Remove redundant "jdk_localedata" from the CLDR locale data meta info class name Reviewed-by: mchung ! make/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java ! src/jdk.localedata/share/classes/META-INF/services/sun.util.locale.provider.LocaleDataMetaInfo Changeset: 78f9275a6493 Author: rriggs Date: 2016-02-23 17:19 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/78f9275a6493 8150337: sun/misc/SunMiscSignalTest.java failed intermittently Summary: Correct test to allow for signals to be ignored Reviewed-by: bpb ! src/java.base/share/classes/jdk/internal/misc/Signal.java ! test/sun/misc/SunMiscSignalTest.java Changeset: ff1b81648957 Author: erikj Date: 2016-02-24 00:14 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ff1b81648957 8150456: jdk 9 nightly build fails on Windows 32 bit Reviewed-by: tbell, ihse ! make/lib/CoreLibraries.gmk ! src/java.base/share/native/libzip/CRC32.c Changeset: 8256c192e4b5 Author: xuelei Date: 2016-02-24 02:50 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8256c192e4b5 8149417: Use final restricted flag Reviewed-by: mullan, weijun, coffeys ! src/java.base/share/classes/javax/crypto/JceSecurity.java + test/javax/crypto/JceSecurity/FinalRestricted.java Changeset: 02f76138c022 Author: vlivanov Date: 2016-02-15 20:27 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/02f76138c022 8148994: Replacing MH::invokeBasic with a direct call breaks LF customization Reviewed-by: jrose, redestad ! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java Changeset: 6c649a7ac744 Author: vlivanov Date: 2016-02-17 18:49 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6c649a7ac744 8148518: Unsafe.getCharUnaligned() loads aren't folded in case of -XX:-UseUnalignedAccesses Reviewed-by: kvn, shade ! src/java.base/share/classes/jdk/internal/misc/Unsafe.java Changeset: 13759d57abca Author: mikael Date: 2016-02-10 15:20 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/13759d57abca 8141491: Unaligned memory access in Bits.c Summary: Introduce alignment-safe Copy::conjoint_swap and j.i.m.Unsafe.copySwapMemory Reviewed-by: jrose, dholmes, psandoz ! make/lib/CoreLibraries.gmk ! make/mapfiles/libjava/mapfile-vers ! src/java.base/share/classes/java/nio/Bits.java ! src/java.base/share/classes/jdk/internal/misc/Unsafe.java - src/java.base/share/native/libjava/Bits.c Changeset: b344be36b569 Author: mikael Date: 2016-02-10 19:55 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b344be36b569 8149611: Add tests for Unsafe.copySwapMemory Reviewed-by: dholmes + test/jdk/internal/misc/Unsafe/CopySwap.java Changeset: 045dc0b6203c Author: dcubed Date: 2016-02-16 12:09 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/045dc0b6203c Merge ! make/lib/CoreLibraries.gmk - src/java.base/share/native/libjava/Bits.c Changeset: f32f683182d2 Author: jwilhelm Date: 2016-02-18 18:07 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f32f683182d2 Merge ! src/java.base/share/classes/jdk/internal/misc/Unsafe.java Changeset: dcf2d62a3e5b Author: amurillo Date: 2016-02-18 15:19 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/dcf2d62a3e5b Merge ! make/mapfiles/libjava/mapfile-vers - src/java.base/share/native/libjava/Bits.c Changeset: a2a823780a7c Author: amurillo Date: 2016-02-23 18:57 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a2a823780a7c Merge ! make/lib/CoreLibraries.gmk - src/java.base/share/native/libjava/Bits.c Changeset: e4af8119eba4 Author: bpb Date: 2016-02-15 16:59 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e4af8119eba4 8150204: (fs) Enhance java/nio/file/Files/probeContentType/Basic.java debugging output Summary: Add debugging information to the test. Reviewed-by: alanb ! test/java/nio/file/Files/probeContentType/Basic.java Changeset: f9913ea0f95c Author: sdrach Date: 2016-02-15 17:47 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f9913ea0f95c 8132734: JDK 9 runtime changes to support multi-release jar files Summary: JEP 238 Multi-Release JAR Files runtime support Reviewed-by: alanb, psandoz, sherman ! src/java.base/share/classes/java/net/JarURLConnection.java ! src/java.base/share/classes/java/util/jar/Attributes.java ! src/java.base/share/classes/java/util/jar/JarFile.java ! src/java.base/share/classes/sun/misc/URLClassPath.java ! src/java.base/share/classes/sun/net/www/protocol/jar/URLJarFile.java ! src/java.base/unix/classes/sun/net/www/protocol/jar/JarFileFactory.java ! src/java.base/windows/classes/sun/net/www/protocol/jar/JarFileFactory.java + test/java/util/jar/JarFile/MultiReleaseJarAPI.java + test/java/util/jar/JarFile/MultiReleaseJarHttpProperties.java + test/java/util/jar/JarFile/MultiReleaseJarIterators.java + test/java/util/jar/JarFile/MultiReleaseJarProperties.java + test/java/util/jar/JarFile/MultiReleaseJarSecurity.java + test/sun/net/www/protocol/jar/MultiReleaseJarURLConnection.java Changeset: d1974f961903 Author: lana Date: 2016-02-25 11:27 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d1974f961903 Merge - src/java.base/share/native/libjava/Bits.c Changeset: e0da6c2a5c32 Author: michaelm Date: 2016-02-25 23:14 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e0da6c2a5c32 8087112: HTTP API and HTTP/1.1 implementation Reviewed-by: alanb, chegar, coffeys, psandoz, rriggs ! make/src/classes/build/tools/module/boot.modules ! src/java.base/share/classes/java/net/Authenticator.java ! src/java.base/share/classes/java/net/ProxySelector.java ! src/java.base/share/classes/java/net/package-info.java + src/java.httpclient/share/classes/java/net/http/AsyncEvent.java + src/java.httpclient/share/classes/java/net/http/AuthenticationFilter.java + src/java.httpclient/share/classes/java/net/http/BufferHandler.java + src/java.httpclient/share/classes/java/net/http/ConnectionPool.java + src/java.httpclient/share/classes/java/net/http/CookieFilter.java + src/java.httpclient/share/classes/java/net/http/Exchange.java + src/java.httpclient/share/classes/java/net/http/ExchangeImpl.java + src/java.httpclient/share/classes/java/net/http/ExecutorWrapper.java + src/java.httpclient/share/classes/java/net/http/FilterFactory.java + src/java.httpclient/share/classes/java/net/http/HeaderFilter.java + src/java.httpclient/share/classes/java/net/http/HeaderParser.java + src/java.httpclient/share/classes/java/net/http/Http1Exchange.java + src/java.httpclient/share/classes/java/net/http/Http1Request.java + src/java.httpclient/share/classes/java/net/http/Http1Response.java + src/java.httpclient/share/classes/java/net/http/Http2ClientImpl.java + src/java.httpclient/share/classes/java/net/http/Http2Connection.java + src/java.httpclient/share/classes/java/net/http/HttpClient.java + src/java.httpclient/share/classes/java/net/http/HttpClientBuilderImpl.java + src/java.httpclient/share/classes/java/net/http/HttpClientImpl.java + src/java.httpclient/share/classes/java/net/http/HttpConnection.java + src/java.httpclient/share/classes/java/net/http/HttpHeaders.java + src/java.httpclient/share/classes/java/net/http/HttpHeaders1.java + src/java.httpclient/share/classes/java/net/http/HttpHeadersImpl.java + src/java.httpclient/share/classes/java/net/http/HttpRedirectImpl.java + src/java.httpclient/share/classes/java/net/http/HttpRequest.java + src/java.httpclient/share/classes/java/net/http/HttpRequestBuilderImpl.java + src/java.httpclient/share/classes/java/net/http/HttpRequestImpl.java + src/java.httpclient/share/classes/java/net/http/HttpResponse.java + src/java.httpclient/share/classes/java/net/http/HttpResponseImpl.java + src/java.httpclient/share/classes/java/net/http/HttpTimeoutException.java + src/java.httpclient/share/classes/java/net/http/Log.java + src/java.httpclient/share/classes/java/net/http/MultiExchange.java + src/java.httpclient/share/classes/java/net/http/Pair.java + src/java.httpclient/share/classes/java/net/http/PlainHttpConnection.java + src/java.httpclient/share/classes/java/net/http/PlainProxyConnection.java + src/java.httpclient/share/classes/java/net/http/PlainTunnelingConnection.java + src/java.httpclient/share/classes/java/net/http/RawChannel.java + src/java.httpclient/share/classes/java/net/http/RedirectFilter.java + src/java.httpclient/share/classes/java/net/http/ResponseContent.java + src/java.httpclient/share/classes/java/net/http/ResponseHeaders.java + src/java.httpclient/share/classes/java/net/http/SSLConnection.java + src/java.httpclient/share/classes/java/net/http/SSLDelegate.java + src/java.httpclient/share/classes/java/net/http/SSLTunnelConnection.java + src/java.httpclient/share/classes/java/net/http/Stream.java + src/java.httpclient/share/classes/java/net/http/TimeoutEvent.java + src/java.httpclient/share/classes/java/net/http/Utils.java + src/java.httpclient/share/classes/java/net/http/package-info.java ! test/com/sun/net/httpserver/FileServerHandler.java + test/java/net/httpclient/APIErrors.java + test/java/net/httpclient/BasicAuthTest.java + test/java/net/httpclient/HeadersTest.java + test/java/net/httpclient/HttpUtils.java + test/java/net/httpclient/ImmutableHeaders.java + test/java/net/httpclient/LightWeightHttpServer.java + test/java/net/httpclient/ManyRequests.java + test/java/net/httpclient/ProxyServer.java + test/java/net/httpclient/QuickResponses.java + test/java/net/httpclient/RequestBodyTest.java + test/java/net/httpclient/Server.java + test/java/net/httpclient/SmokeTest.java + test/java/net/httpclient/SplitResponse.java + test/java/net/httpclient/TimeoutTest.java + test/java/net/httpclient/docs/files/foo.txt + test/java/net/httpclient/docs/files/notsobigfile.txt + test/java/net/httpclient/docs/files/smallfile.txt + test/java/net/httpclient/security/0.policy + test/java/net/httpclient/security/1.policy + test/java/net/httpclient/security/10.policy + test/java/net/httpclient/security/11.policy + test/java/net/httpclient/security/12.policy + test/java/net/httpclient/security/15.policy + test/java/net/httpclient/security/2.policy + test/java/net/httpclient/security/3.policy + test/java/net/httpclient/security/4.policy + test/java/net/httpclient/security/5.policy + test/java/net/httpclient/security/6.policy + test/java/net/httpclient/security/7.policy + test/java/net/httpclient/security/8.policy + test/java/net/httpclient/security/9.policy + test/java/net/httpclient/security/Security.java Changeset: e143c31a205b Author: jnimeh Date: 2016-02-25 16:10 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e143c31a205b 8145854: SSLContextImpl.statusResponseManager should be generated if required Summary: Implement server-side lazy initialization of StatusResponseManagers in the SSLContextImpl class. Reviewed-by: xuelei ! src/java.base/share/classes/sun/security/ssl/ClientHandshaker.java ! src/java.base/share/classes/sun/security/ssl/SSLContextImpl.java ! src/java.base/share/classes/sun/security/ssl/ServerHandshaker.java + test/javax/net/ssl/Stapling/StapleEnableProps.java Changeset: f0bd5f763f1e Author: amlu Date: 2016-02-26 09:55 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f0bd5f763f1e 8150608: Mark BashStreams.java as intermittently failing and put to ProblemList Reviewed-by: bpb, rriggs ! test/ProblemList.txt ! test/java/nio/charset/coders/BashStreams.java Changeset: 4c8676710c25 Author: erikj Date: 2016-02-26 06:03 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4c8676710c25 8150497: 32 jshell tests failed on Windows 32 bit Reviewed-by: darcy, tbell ! make/lib/Lib-jdk.jdi.gmk ! make/lib/Lib-jdk.jdwp.agent.gmk ! src/jdk.jdi/share/native/libdt_shmem/shmemBack.c ! src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c Changeset: 41e3c10db27a Author: dfuchs Date: 2016-02-26 12:11 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/41e3c10db27a 8150533: Test java/util/logging/LogManagerAppContextDeadlock.java times out intermittently. Summary: This is a test bug caused by a Logger being garbage collected too early. Reviewed-by: darcy ! test/java/util/logging/LogManagerAppContextDeadlock.java Changeset: 42794e648cfe Author: mhaupt Date: 2016-02-29 14:16 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/42794e648cfe 8150825: MethodHandles.tryFinally throws IndexOutOfBoundsException for non-conforming parameter lists Reviewed-by: redestad ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! test/java/lang/invoke/T8139885.java Changeset: fcc726885cbe Author: henryjen Date: 2016-03-02 21:50 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fcc726885cbe Merge ! make/gensrc/GensrcMisc.gmk ! make/gensrc/GensrcModuleLoaderMap.gmk ! make/lib/Awt2dLibraries.gmk ! make/lib/CoreLibraries.gmk ! make/lib/Lib-java.instrument.gmk ! make/lib/Lib-jdk.jdi.gmk ! make/lib/Lib-jdk.jdwp.agent.gmk ! make/mapfiles/libjava/mapfile-vers ! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/nio/Bits.java ! src/java.base/share/classes/javax/crypto/JceSecurity.java ! src/java.base/share/classes/module-info.java ! src/java.base/share/classes/sun/misc/URLClassPath.java - src/java.base/share/native/libjava/Bits.c ! src/java.compact3/share/classes/module-info.java ! src/jdk.localedata/share/classes/module-info.java ! test/ProblemList.txt ! test/tools/pack200/Utils.java Changeset: 9a91f53d03d4 Author: henryjen Date: 2016-03-03 10:40 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9a91f53d03d4 Merge ! make/gensrc/GensrcModuleLoaderMap.gmk + src/java.httpclient/share/classes/module-info.java Changeset: 2582665c63ce Author: lana Date: 2016-03-03 12:25 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2582665c63ce Added tag jdk-9+108 for changeset 42794e648cfe ! .hgtags Changeset: 790714f1e0fc Author: mchung Date: 2016-03-03 12:37 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/790714f1e0fc Merge ! .hgtags - make/gendata/Gendata-jdk.jdeps.gmk - make/gensrc/Gensrc-jdk.dev.gmk - make/gensrc/Gensrc-jdk.jvmstat.gmk - make/launcher/Launcher-jdk.dev.gmk - make/scripts/localelist.sh - make/src/classes/build/tools/module/GenJdepsModulesXml.java - make/src/classes/build/tools/module/GenModulesList.java - make/src/classes/build/tools/module/ImageBuilder.java - make/src/classes/build/tools/module/ModuleArchive.java - make/src/classes/build/tools/module/boot.modules - make/src/classes/build/tools/module/ext.modules - src/java.base/share/classes/jdk/internal/jimage/Archive.java - src/java.base/share/classes/jdk/internal/jimage/BasicImageWriter.java - src/java.base/share/classes/jdk/internal/jimage/ExternalFilesWriter.java - src/java.base/share/classes/jdk/internal/jimage/ImageFileCreator.java - src/java.base/share/classes/jdk/internal/jimage/ImageJavaSubstrate.java - src/java.base/share/classes/jdk/internal/jimage/ImageLocationWriter.java - src/java.base/share/classes/jdk/internal/jimage/ImageModuleDataWriter.java - src/java.base/share/classes/jdk/internal/jimage/ImageNativeSubstrate.java - src/java.base/share/classes/jdk/internal/jimage/ImageResourcesTree.java - src/java.base/share/classes/jdk/internal/jimage/ImageStringsWriter.java - src/java.base/share/classes/jdk/internal/jimage/ImageSubstrate.java - src/java.base/share/classes/jdk/internal/jimage/PerfectHashBuilder.java - src/java.base/share/classes/jdk/internal/jimage/ResourcePool.java - src/java.base/share/classes/jdk/internal/jimage/ResourcePoolImpl.java - src/java.base/share/classes/jdk/internal/jimage/StringTable.java - src/java.base/share/classes/jdk/internal/jimage/UTF8String.java - src/java.base/share/classes/sun/misc/Launcher.java - src/java.base/share/classes/sun/util/CoreResourceBundleControl-XLocales.java.template - src/java.base/share/native/libjava/Package.c - src/java.base/share/native/libjava/Proxy.c - src/java.base/share/native/libjimage/ImageNativeSubstrate.cpp - src/java.desktop/share/classes/META-INF/services/java.net.ContentHandlerFactory - src/java.desktop/share/classes/META-INF/services/javax.print.PrintServiceLookup - src/java.desktop/share/classes/META-INF/services/javax.print.StreamPrintServiceFactory - src/java.desktop/share/classes/META-INF/services/javax.sound.midi.spi.MidiDeviceProvider - src/java.desktop/share/classes/META-INF/services/javax.sound.midi.spi.MidiFileReader - src/java.desktop/share/classes/META-INF/services/javax.sound.midi.spi.MidiFileWriter - src/java.desktop/share/classes/META-INF/services/javax.sound.midi.spi.SoundbankReader - src/java.desktop/share/classes/META-INF/services/javax.sound.sampled.spi.AudioFileReader - src/java.desktop/share/classes/META-INF/services/javax.sound.sampled.spi.AudioFileWriter - src/java.desktop/share/classes/META-INF/services/javax.sound.sampled.spi.FormatConversionProvider - src/java.desktop/share/classes/META-INF/services/javax.sound.sampled.spi.MixerProvider - src/java.desktop/share/classes/META-INF/services/sun.datatransfer.DesktopDatatransferService - src/java.logging/share/classes/META-INF/services/jdk.internal.logger.DefaultLoggerFinder - src/java.security.jgss/share/classes/META-INF/services/sun.security.ssl.ClientKeyExchangeService - src/jdk.accessibility/windows/classes/META-INF/services/javax.accessibility.AccessibilityProvider - src/jdk.attach/share/classes/META-INF/services/com.sun.tools.attach.spi.AttachProvider - src/jdk.charsets/share/classes/META-INF/services/java.nio.charset.spi.CharsetProvider - src/jdk.dev/share/classes/jdk/tools/jimage/ExtractedImage.java - src/jdk.dev/share/classes/jdk/tools/jimage/JImageTask.java - src/jdk.dev/share/classes/jdk/tools/jimage/Main.java - src/jdk.dev/share/classes/jdk/tools/jimage/TaskHelper.java - src/jdk.dev/share/classes/jdk/tools/jimage/resources/jimage.properties - src/jdk.jdi/share/classes/META-INF/services/com.sun.jdi.connect.Connector - src/jdk.jdi/share/classes/META-INF/services/com.sun.jdi.connect.spi.TransportService - src/jdk.jvmstat.rmi/share/classes/META-INF/services/sun.jvmstat.monitor.MonitoredHostService - src/jdk.jvmstat/share/classes/META-INF/services/sun.jvmstat.monitor.MonitoredHostService - src/jdk.localedata/share/classes/META-INF/services/sun.util.locale.provider.LocaleDataMetaInfo - src/jdk.management/share/classes/META-INF/services/sun.management.spi.PlatformMBeanProvider - src/jdk.naming.dns/share/classes/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - src/jdk.zipfs/share/classes/META-INF/services/java.nio.file.spi.FileSystemProvider - test/java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.sh - test/java/net/DatagramSocket/SetDatagramSocketImplFactory/java/net/MyDatagramSocketImplFactory.java - test/java/util/stream/bootlib/TEST.properties - test/jdk/internal/jimage/ExecutableTest.java - test/jdk/internal/jimage/JImageTest.java - test/jdk/internal/jimage/VerifyJimage.java - test/sun/security/krb5/config/NamingManager.java - test/sun/security/krb5/config/dns.sh - test/sun/security/mscapi/IsSunMSCAPIAvailable.sh - test/sun/security/ssl/StatusStapling/BogusStatusRequest.java - test/sun/security/ssl/StatusStapling/CertStatusReqExtensionTests.java - test/sun/security/ssl/StatusStapling/CertStatusReqItemV2Tests.java - test/sun/security/ssl/StatusStapling/CertStatusReqListV2ExtensionTests.java - test/sun/security/ssl/StatusStapling/OCSPStatusRequestTests.java - test/sun/security/ssl/StatusStapling/StatusResponseManagerTests.java - test/sun/security/ssl/StatusStapling/TestCase.java - test/sun/security/ssl/StatusStapling/TestUtils.java From mandy.chung at oracle.com Thu Mar 3 21:20:15 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 03 Mar 2016 21:20:15 +0000 Subject: hg: jigsaw/jake/langtools: 16 new changesets Message-ID: <201603032120.u23LKFFf000163@aojmv0008.oracle.com> Changeset: 3cdfbbdb6f61 Author: vromero Date: 2016-02-22 16:17 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/3cdfbbdb6f61 8149600: javac, remove unused options, step 2 Reviewed-by: jjg, mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java ! 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/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties ! src/jdk.compiler/share/classes/com/sun/tools/javah/JavahTask.java ! test/tools/javac/6257443/T6257443.java - test/tools/javac/6521805/T6521805a.java - test/tools/javac/6521805/T6521805a_1.out - test/tools/javac/6521805/T6521805a_2.out ! test/tools/javac/api/taskListeners/EventsBalancedTest.java ! test/tools/javac/diags/CheckResourceKeys.java ! test/tools/javac/diags/examples.not-yet.txt - test/tools/javac/diags/examples/WarnSyntheticNameConflict.java Changeset: dd43a467134b Author: darcy Date: 2016-02-23 11:17 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/dd43a467134b 8150427: Demote ToolReloadTest.java and mark as intermittently failing Reviewed-by: jjg ! test/TEST.groups ! test/jdk/jshell/ToolReloadTest.java Changeset: 700565092eb6 Author: jjg Date: 2016-02-23 16:13 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/700565092eb6 8149772: cleanup handling of -encoding in JavacFileManager Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/BaseFileManager.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java Changeset: f04e97a97930 Author: vromero Date: 2016-02-23 16:25 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/f04e97a97930 8149328: remove the dependency on java.logging from java.compiler Reviewed-by: jjg ! src/java.compiler/share/classes/javax/tools/ToolProvider.java Changeset: 527e819dbc95 Author: jjg Date: 2016-02-23 16:38 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/527e819dbc95 8145472: replace remaining java.io.File with java.nio.file.Path Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Arguments.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/CommandLine.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/OptionHelper.java Changeset: 21d9e172e9f6 Author: jjg Date: 2016-02-23 19:17 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/21d9e172e9f6 8150475: -sourcepath / crashes javac Reviewed-by: darcy, vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java + test/tools/javac/file/T8150475.java Changeset: 7892ba7c7015 Author: lana Date: 2016-02-25 11:28 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/7892ba7c7015 Merge - test/tools/javac/6521805/T6521805a.java - test/tools/javac/6521805/T6521805a_1.out - test/tools/javac/6521805/T6521805a_2.out - test/tools/javac/diags/examples/WarnSyntheticNameConflict.java Changeset: ddfdf0304052 Author: jlahoda Date: 2016-02-29 11:54 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/ddfdf0304052 8131027: JShell API/tool: suggest imports for a class Summary: Adding two new actions to JShell: add imports and create variable. Reviewed-by: rfield ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java ! src/jdk.jshell/share/classes/jdk/jshell/Eval.java ! src/jdk.jshell/share/classes/jdk/jshell/JShell.java ! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysis.java ! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java ! src/jdk.jshell/share/classes/jdk/jshell/TreeDissector.java + test/jdk/jshell/ComputeFQNsTest.java + test/jdk/jshell/InferTypeTest.java ! test/jdk/jshell/KullaTesting.java Changeset: b7583d50f67d Author: alundblad Date: 2016-02-29 13:24 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/b7583d50f67d 8147569: Error messages from sjavac server does not always get relayed back to client Summary: Refactored how logging works in sjavac. Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/CleanProperties.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/CompileJavaPackages.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/CompileProperties.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/CopyFile.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/JavacState.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/Log.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/Transformer.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/Util.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/client/ClientMain.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/client/SjavacClient.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/PooledSjavac.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/SjavacImpl.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/IdleResetSjavac.java - src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/LinePrefixFilterWriter.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/PortFileMonitor.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/RequestHandler.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/ServerMain.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/Sjavac.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/SjavacServer.java + src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/log/LazyInitFileLog.java + src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/log/LoggingOutputStream.java ! test/tools/sjavac/IdleShutdown.java ! test/tools/sjavac/PooledExecution.java Changeset: 8ea3f9487e89 Author: alundblad Date: 2016-02-29 13:37 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/8ea3f9487e89 8147571: Information about written .h files is printed on the wrong logging level Summary: Changed how SmartWriter outputs log messages. Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/CompilationService.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/SmartFileManager.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/SmartFileObject.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/SmartWriter.java Changeset: 5282596d34b3 Author: alundblad Date: 2016-02-29 19:07 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/5282596d34b3 8148498: The sjavac client should never create a port file Summary: Sjavac client now avoids creating a port file. Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/client/ClientMain.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/client/SjavacClient.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/PortFile.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/SjavacServer.java Changeset: fd18a155ad22 Author: jlahoda Date: 2016-02-29 19:52 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/fd18a155ad22 8150874: Disable the ComputeFQNsTest.testSuspendIndexing test Reviewed-by: rfield ! test/jdk/jshell/ComputeFQNsTest.java Changeset: 2e244d526f4a Author: henryjen Date: 2016-03-02 21:50 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/2e244d526f4a Merge ! src/java.compiler/share/classes/javax/tools/ToolProvider.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/BaseFileManager.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Arguments.java ! 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/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties ! src/jdk.compiler/share/classes/com/sun/tools/javah/JavahTask.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/SjavacImpl.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/SmartFileManager.java - src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/LinePrefixFilterWriter.java ! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java - test/tools/javac/6521805/T6521805a.java - test/tools/javac/6521805/T6521805a_1.out - test/tools/javac/6521805/T6521805a_2.out ! test/tools/javac/diags/CheckResourceKeys.java - test/tools/javac/diags/examples/WarnSyntheticNameConflict.java Changeset: 5925968048bd Author: henryjen Date: 2016-03-03 10:40 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/5925968048bd Merge ! test/ProblemList.jake.txt ! test/jdk/jshell/ComputeFQNsTest.java Changeset: f035d3881296 Author: lana Date: 2016-03-03 12:26 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/f035d3881296 Added tag jdk-9+108 for changeset fd18a155ad22 ! .hgtags Changeset: c22ed8f3d442 Author: mchung Date: 2016-03-03 12:37 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/c22ed8f3d442 Merge ! .hgtags - src/jdk.compiler/share/classes/com/sun/tools/javac/sym/CreateSymbols.java - src/jdk.compiler/share/classes/com/sun/tools/javac/sym/Profiles.java - src/jdk.compiler/share/classes/com/sun/tools/javac/util/ServiceLoader.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/AbstractProfileIndexWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfileIndexFrameWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageFrameWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageIndexFrameWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageWriterImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfileWriterImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/ProfilePackageSummaryWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/ProfileSummaryWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ProfilePackageSummaryBuilder.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ProfileSummaryBuilder.java - src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModulesXmlReader.java - src/jdk.jdeps/share/classes/com/sun/tools/jdeps/PlatformClassPath.java - test/com/sun/javadoc/testLinkOption/java/lang/StringBuilderChild.java - test/com/sun/javadoc/testLinkOption/package-list - test/com/sun/javadoc/testProfiles/TestProfiles.java - test/com/sun/javadoc/testProfiles/TestProfilesConfiguration.java - test/com/sun/javadoc/testProfiles/pkg1/Class1Pkg1.java - test/com/sun/javadoc/testProfiles/pkg1/Class2Pkg1.java - test/com/sun/javadoc/testProfiles/pkg1/Class3Pkg1.java - test/com/sun/javadoc/testProfiles/pkg1/Interface1Pkg1.java - test/com/sun/javadoc/testProfiles/pkg2/Anno1Pkg2.java - test/com/sun/javadoc/testProfiles/pkg2/Anno2Pkg2.java - test/com/sun/javadoc/testProfiles/pkg2/Class1Pkg2.java - test/com/sun/javadoc/testProfiles/pkg2/ClassError.java - test/com/sun/javadoc/testProfiles/pkg2/ClassException.java - test/com/sun/javadoc/testProfiles/pkg3/Class1Pkg3.java - test/com/sun/javadoc/testProfiles/pkg3/Class2Pkg3.java - test/com/sun/javadoc/testProfiles/pkg3/Interface1Pkg3.java - test/com/sun/javadoc/testProfiles/pkg4/Anno1Pkg4.java - test/com/sun/javadoc/testProfiles/pkg4/Class1Pkg4.java - test/com/sun/javadoc/testProfiles/pkg5/Class1Pkg5.java - test/com/sun/javadoc/testProfiles/pkg5/Interface1Pkg5.java - test/com/sun/javadoc/testProfiles/pkgDeprecated/Class1PkgDeprecated.java - test/com/sun/javadoc/testProfiles/pkgDeprecated/package-info.java - test/com/sun/javadoc/testProfiles/profile-rtjar-includes-nopkgs.txt - test/com/sun/javadoc/testProfiles/profile-rtjar-includes.txt - test/jdk/javadoc/doclet/testLinkOption/java/lang/StringBuilderChild.java - test/jdk/javadoc/doclet/testLinkOption/package-list - test/tools/javac/Object1.java - test/tools/javac/Object1.out - test/tools/javac/Object2.java - test/tools/javac/Object2.out - test/tools/javac/profiles/ProfileTest.java - test/tools/javac/proprietary/WarnClass.java - test/tools/javac/proprietary/WarnClass.out - test/tools/javac/proprietary/WarnImport.java - test/tools/javac/proprietary/WarnImport.out - test/tools/javac/proprietary/WarnMethod.java - test/tools/javac/proprietary/WarnMethod.out - test/tools/javac/proprietary/WarnStaticImport.java - test/tools/javac/proprietary/WarnStaticImport.out - test/tools/javac/proprietary/WarnVariable.java - test/tools/javac/proprietary/WarnVariable.out - test/tools/javac/proprietary/WarnWildcard.java - test/tools/javac/proprietary/WarnWildcard.out - test/tools/javac/synthesize/Boolean.java - test/tools/javac/synthesize/Byte.java - test/tools/javac/synthesize/Character.java - test/tools/javac/synthesize/Cloneable.java - test/tools/javac/synthesize/Double.java - test/tools/javac/synthesize/Float.java - test/tools/javac/synthesize/Integer.java - test/tools/javac/synthesize/Long.java - test/tools/javac/synthesize/Number.java - test/tools/javac/synthesize/Object.java - test/tools/javac/synthesize/Serializable.java - test/tools/javac/synthesize/Short.java - test/tools/javac/synthesize/Test.java - test/tools/javac/synthesize/Void.java - test/tools/jdeps/VerboseFormat/use/indirect/DontUseUnsafe2.java - test/tools/jdeps/VerboseFormat/use/indirect/UseUnsafeIndirectly.java - test/tools/jdeps/VerboseFormat/use/indirect2/DontUseUnsafe3.java - test/tools/jdeps/VerboseFormat/use/indirect2/UseUnsafeIndirectly2.java - test/tools/jdeps/VerboseFormat/use/unsafe/DontUseUnsafe.java - test/tools/jdeps/VerboseFormat/use/unsafe/UseClassWithUnsafe.java - test/tools/jdeps/VerboseFormat/use/unsafe/UseUnsafeClass.java - test/tools/jdeps/VerboseFormat/use/unsafe/UseUnsafeClass2.java - test/tools/jdeps/javax/activity/NotCompactProfile.java From mandy.chung at oracle.com Thu Mar 3 21:20:18 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 03 Mar 2016 21:20:18 +0000 Subject: hg: jigsaw/jake/nashorn: 6 new changesets Message-ID: <201603032120.u23LKJud000296@aojmv0008.oracle.com> Changeset: 93854b0b5e5e Author: sundar Date: 2016-02-25 13:56 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/93854b0b5e5e 8148379: jdk.nashorn.api.scripting spec. adjustments, clarifications Reviewed-by: hannesw, mhaupt ! make/build.xml ! make/project.properties ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/scripting/AbstractJSObject.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/scripting/JSObject.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/scripting/NashornException.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/scripting/NashornScriptEngineFactory.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/scripting/ScriptUtils.java ! test/script/basic/JDK-8026367.js Changeset: a797fcfb7780 Author: lana Date: 2016-02-25 11:28 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/a797fcfb7780 Merge Changeset: 58409eff7e3e Author: mhaupt Date: 2016-02-29 09:49 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/58409eff7e3e 8150814: correct package declaration in Nashorn test Reviewed-by: sundar ! test/src/jdk/nashorn/api/scripting/test/JDK_8148140_Test.java Changeset: e63f20c52128 Author: henryjen Date: 2016-03-02 21:50 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/e63f20c52128 Merge ! make/build.xml ! make/project.properties Changeset: 10d21e3ecd4f Author: lana Date: 2016-03-03 12:26 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/10d21e3ecd4f Added tag jdk-9+108 for changeset 58409eff7e3e ! .hgtags Changeset: e9c8b229c463 Author: mchung Date: 2016-03-03 12:37 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/e9c8b229c463 Merge ! .hgtags - src/jdk.scripting.nashorn/share/classes/META-INF/MANIFEST.MF - src/jdk.scripting.nashorn/share/classes/META-INF/services/javax.script.ScriptEngineFactory From keimpe.bronkhorst at oracle.com Thu Mar 3 22:49:51 2016 From: keimpe.bronkhorst at oracle.com (Keimpe Bronkhorst) Date: Thu, 3 Mar 2016 15:49:51 -0700 Subject: -XaddExports: not recognized in JavaVMInitArgs on Windows Message-ID: <56D8BF8F.2040702@oracle.com> I'm using build 9-ea+107-jigsaw-nightly-h4560-20160301 on Windows. I'm executing my program through jvm.dll using JavaVMInitArgs and JNI. I set JavaVMInitArgs.ignoreUnrecognized = JNI_FALSE and add -XaddExports:java.desktop/sun.awt=ALL-UNNAMED as one of the JavaVMInitArgs.options. This results in Unrecognized option: -XaddExports:java.desktop/sun.awt=ALL-UNNAMED If use JavaVMInitArgs.ignoreUnrecognized = JNI_TRUE, I run into the exception: Exception breakpoint: Reflection.java:467, java.lang.IllegalAccessException, class org.openide.util.RequestProcessor$TopLevelThreadGroup cannot access class sun.awt.AppContext (in module java.desktop) because module java.desktop does not export sun.awt to unnamed module @204f30ec Is this a known limitation at this time or should I file a bug? Keimpe Bronkhorst From lois.foltan at oracle.com Thu Mar 3 23:38:36 2016 From: lois.foltan at oracle.com (lois.foltan at oracle.com) Date: Thu, 03 Mar 2016 23:38:36 +0000 Subject: hg: jigsaw/jake/hotspot: Continued clean up for JVM's jigsaw support as part of feedback from internal review. Message-ID: <201603032338.u23Nca2v026978@aojmv0008.oracle.com> Changeset: d66480af11d0 Author: lfoltan Date: 2016-03-03 18:11 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d66480af11d0 Continued clean up for JVM's jigsaw support as part of feedback from internal review. ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/klassFactory.cpp ! src/share/vm/classfile/moduleEntry.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp From mandy.chung at oracle.com Thu Mar 3 23:55:13 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 3 Mar 2016 15:55:13 -0800 Subject: -XaddExports: not recognized in JavaVMInitArgs on Windows In-Reply-To: <56D8BF8F.2040702@oracle.com> References: <56D8BF8F.2040702@oracle.com> Message-ID: <6482B306-52D9-44BF-8968-DD856161C240@oracle.com> > On Mar 3, 2016, at 2:49 PM, Keimpe Bronkhorst wrote: > > I'm using build 9-ea+107-jigsaw-nightly-h4560-20160301 on Windows. > > I'm executing my program through jvm.dll using JavaVMInitArgs and JNI. I set JavaVMInitArgs.ignoreUnrecognized = JNI_FALSE and add -XaddExports:java.desktop/sun.awt=ALL-UNNAMED as one of the JavaVMInitArgs.options. > > This results in Unrecognized option: -XaddExports:java.desktop/sun.awt=ALL-UNNAMED > In the current implementation, -XaddExports is a launcher option, not a VM option. For custom launchers, it?s yet to decide whether the equivalent of -XaddExports. For now, you can pass -Djdk.launcher.addexports.=/= $N is a unique number starting from 0, one system property per /. For example -Djdk.launcher.addexports.0=java.desktop/sun.awt=ALL-UNNAMED > If use JavaVMInitArgs.ignoreUnrecognized = JNI_TRUE, I run into the exception: > Exception breakpoint: Reflection.java:467, java.lang.IllegalAccessException, class org.openide.util.RequestProcessor$TopLevelThreadGroup cannot access class sun.awt.AppContext (in module java.desktop) because module java.desktop does not export sun.awt to unnamed module @204f30ec > > Is this a known limitation at this time or should I file a bug? It?s a known open issue (I couldn?t find from JBS yet and will file one). Mandy From mandy.chung at oracle.com Fri Mar 4 00:05:15 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 04 Mar 2016 00:05:15 +0000 Subject: hg: jigsaw/jake/jdk: Minor clean up on test module dependences Message-ID: <201603040005.u2405GBf009046@aojmv0008.oracle.com> Changeset: be591147fb87 Author: shurailine Date: 2016-03-03 16:05 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/be591147fb87 Minor clean up on test module dependences ! test/java/lang/Class/GetModuleTest.java ! test/java/lang/management/MemoryMXBean/PendingAllGC.sh From mandy.chung at oracle.com Fri Mar 4 00:13:48 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 3 Mar 2016 16:13:48 -0800 Subject: RFR: JDK-8150998: Fix module dependences in java/lang tests In-Reply-To: <5ED082EF-F85A-4A4A-8804-16EA849E5685@oracle.com> References: <5ED082EF-F85A-4A4A-8804-16EA849E5685@oracle.com> Message-ID: <84655D04-2C88-4724-9C6B-ED8C8F171248@oracle.com> Shura, > On Mar 3, 2016, at 12:11 PM, Alexandre (Shura) Iline wrote: > > Hi. > > Could you please have another look on the webrev. > > http://cr.openjdk.java.net/~shurailine/8150998/webrev.jake.03/ > http://cr.openjdk.java.net/~shurailine/8150998/webrev.jdk9.03/ I have pushed the patch in webrev.jdk9.03. > I have addressed all the comments except moving the fix of test/java/lang/management/MemoryMXBean/PendingAllGC.sh to JDK9, as this test is already different in JDK9 and Jake, so a fix in JDK9 will be overridden. 30 # @modules java.base/jdk.internal.misc This change should also be in JDK 9 as well. Anyway, I pushed the patch from webrev.jake.03 to jake except FieldSetAccessibleTest.java. Another alternative is to get the modules in the boot layer Layer.boot().stream().map(Module::getName) Mandy From mandy.chung at oracle.com Fri Mar 4 00:16:59 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 3 Mar 2016 16:16:59 -0800 Subject: [9-dev] RfR: JDK-8132743: Move netscape.javascript package from jdk.plugin to new module In-Reply-To: <56D8CF6F.3030502@oracle.com> References: <0DB5EFFD-B4B4-45BA-B866-1AC0DCFDBF90@oracle.com> <61E2A789-BFFC-401F-AA15-425A3702F5B7@oracle.com> <56D8CF6F.3030502@oracle.com> Message-ID: <2CC76624-65B0-4CF6-9EF3-98B489DD991C@oracle.com> jdk9-dev is not the right mailing list. I bcc?ed it and add jigsaw-dev instead. > On Mar 3, 2016, at 3:57 PM, Kevin Rushforth wrote: > > Looks OK to me. I did a quick test build and I can see the new package in the exploded JDK, but not in the images. Maybe I did something wrong? > Good catch. jdk.jsobject needs to be added in MAIN_MODULES list in make/Images.gmk Mandy > -- Kevin > > > David DeHaven wrote: >>>> JBS Issue: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8132743 >>>> >>>> >>>> Code review: >>>> >>>> http://cr.openjdk.java.net/~ddehaven/8132743/webrev.0/ >>>> >>>> >>>> >>> Looks okay. There is no @since - I guess it?s okay because netscape.javascript has been shipped with plugin for long time. >>> >>> >> >> I can't track down when it was first included. It pre-dates anything I've looked at so far. >> >> >> >> >>> package-info.java >>> "when running in an {@link java.applet.Applet Applet}? - is this true when running with JavaFX webkit? >>> >>> >> >> Yes, I believe so, assuming you have a JSObject representing the root window object. Maybe that should be reworded, I think just remove the "when running in an Applet" part. >> >> >> >> >>> JSObject.java >>> @throws JSException is missing in the methods >>> >>> Does it throw NPE if the parameter is null? Or JSException - that needs to be specified. >>> >>> Nit: it?d be good to wrap null with {@code null} in the javadoc. >>> >>> >> >> Ok. I can fix that. >> >> -DrD- >> >> >> From david.dehaven at oracle.com Fri Mar 4 00:35:57 2016 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 3 Mar 2016 16:35:57 -0800 Subject: [9-dev] RfR: JDK-8132743: Move netscape.javascript package from jdk.plugin to new module In-Reply-To: <2CC76624-65B0-4CF6-9EF3-98B489DD991C@oracle.com> References: <0DB5EFFD-B4B4-45BA-B866-1AC0DCFDBF90@oracle.com> <61E2A789-BFFC-401F-AA15-425A3702F5B7@oracle.com> <56D8CF6F.3030502@oracle.com> <2CC76624-65B0-4CF6-9EF3-98B489DD991C@oracle.com> Message-ID: > jdk9-dev is not the right mailing list. I bcc?ed it and add jigsaw-dev instead. > > >> On Mar 3, 2016, at 3:57 PM, Kevin Rushforth wrote: >> >> Looks OK to me. I did a quick test build and I can see the new package in the exploded JDK, but not in the images. Maybe I did something wrong? >> > > Good catch. > > jdk.jsobject needs to be added in MAIN_MODULES list in make/Images.gmk Ok, I'll fix that too. -DrD- From david.dehaven at oracle.com Fri Mar 4 01:06:00 2016 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 3 Mar 2016 17:06:00 -0800 Subject: [9-dev] RfR: JDK-8132743: Move netscape.javascript package from jdk.plugin to new module In-Reply-To: <2CC76624-65B0-4CF6-9EF3-98B489DD991C@oracle.com> References: <0DB5EFFD-B4B4-45BA-B866-1AC0DCFDBF90@oracle.com> <61E2A789-BFFC-401F-AA15-425A3702F5B7@oracle.com> <56D8CF6F.3030502@oracle.com> <2CC76624-65B0-4CF6-9EF3-98B489DD991C@oracle.com> Message-ID: <034652C8-6B32-4E12-9AB9-02912CD80905@oracle.com> Adding it to MAIN_MODULES, I now see it in bootmodules.jimage: /jdk.jsobject/jdk/internal/netscape/javascript/spi/JSObjectProvider.class /jdk.jsobject/netscape/javascript/JSException.class /jdk.jsobject/netscape/javascript/JSObject$ProviderLoader$1.class /jdk.jsobject/netscape/javascript/JSObject$ProviderLoader.class /jdk.jsobject/netscape/javascript/JSObject.class -DrD- > jdk9-dev is not the right mailing list. I bcc?ed it and add jigsaw-dev instead. > > >> On Mar 3, 2016, at 3:57 PM, Kevin Rushforth wrote: >> >> Looks OK to me. I did a quick test build and I can see the new package in the exploded JDK, but not in the images. Maybe I did something wrong? >> > > Good catch. > > jdk.jsobject needs to be added in MAIN_MODULES list in make/Images.gmk > > Mandy > >> -- Kevin >> >> >> David DeHaven wrote: >>>>> JBS Issue: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8132743 >>>>> >>>>> >>>>> Code review: >>>>> >>>>> http://cr.openjdk.java.net/~ddehaven/8132743/webrev.0/ >>>>> >>>>> >>>>> >>>> Looks okay. There is no @since - I guess it?s okay because netscape.javascript has been shipped with plugin for long time. >>>> >>>> >>> >>> I can't track down when it was first included. It pre-dates anything I've looked at so far. >>> >>> >>> >>> >>>> package-info.java >>>> "when running in an {@link java.applet.Applet Applet}? - is this true when running with JavaFX webkit? >>>> >>>> >>> >>> Yes, I believe so, assuming you have a JSObject representing the root window object. Maybe that should be reworded, I think just remove the "when running in an Applet" part. >>> >>> >>> >>> >>>> JSObject.java >>>> @throws JSException is missing in the methods >>>> >>>> Does it throw NPE if the parameter is null? Or JSException - that needs to be specified. >>>> >>>> Nit: it?d be good to wrap null with {@code null} in the javadoc. >>>> >>>> >>> >>> Ok. I can fix that. >>> >>> -DrD- >>> >>> >>> > From mandy.chung at oracle.com Fri Mar 4 01:51:20 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 04 Mar 2016 01:51:20 +0000 Subject: hg: jigsaw/jake/langtools: Test cleanup to add @modules Message-ID: <201603040151.u241pKHk020844@aojmv0008.oracle.com> Changeset: c1a5259e9c75 Author: mchung Date: 2016-03-03 17:51 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/c1a5259e9c75 Test cleanup to add @modules ! test/jdk/jshell/InferTypeTest.java From sundararajan.athijegannathan at oracle.com Fri Mar 4 02:11:53 2016 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Fri, 04 Mar 2016 02:11:53 +0000 Subject: hg: jigsaw/jake/nashorn: removed compile time, runtime dependency from nasgen tool to nashorn code. Nashorn .class files are treated as just data files by nasgen tool. Message-ID: <201603040211.u242BrOQ029207@aojmv0008.oracle.com> Changeset: a67ceefb5a7b Author: sundar Date: 2016-03-04 07:41 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/a67ceefb5a7b removed compile time, runtime dependency from nasgen tool to nashorn code. Nashorn .class files are treated as just data files by nasgen tool. ! buildtools/nasgen/build.xml ! buildtools/nasgen/project.properties ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/MemberInfo.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/MethodGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInfo.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInfoCollector.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInstrumentor.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/StringConstants.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/Where.java ! make/build-nasgen.xml ! make/build.xml ! make/project.properties From david.dehaven at oracle.com Fri Mar 4 03:36:14 2016 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 3 Mar 2016 19:36:14 -0800 Subject: [9-dev] RfR: JDK-8132743: Move netscape.javascript package from jdk.plugin to new module In-Reply-To: <034652C8-6B32-4E12-9AB9-02912CD80905@oracle.com> References: <0DB5EFFD-B4B4-45BA-B866-1AC0DCFDBF90@oracle.com> <61E2A789-BFFC-401F-AA15-425A3702F5B7@oracle.com> <56D8CF6F.3030502@oracle.com> <2CC76624-65B0-4CF6-9EF3-98B489DD991C@oracle.com> <034652C8-6B32-4E12-9AB9-02912CD80905@oracle.com> Message-ID: <411EAC9F-CA8C-4A4C-84D1-D87375567EDE@oracle.com> Updated webrev: http://cr.openjdk.java.net/~ddehaven/8132743/webrev.1/ Added jdk.jsobject to MAIN_MODULES Made suggested Javadoc changes Gave JSException a real serialVersionUID -DrD- > On Mar 3, 2016, at 5:06 PM, David DeHaven wrote: > > > Adding it to MAIN_MODULES, I now see it in bootmodules.jimage: > /jdk.jsobject/jdk/internal/netscape/javascript/spi/JSObjectProvider.class > /jdk.jsobject/netscape/javascript/JSException.class > /jdk.jsobject/netscape/javascript/JSObject$ProviderLoader$1.class > /jdk.jsobject/netscape/javascript/JSObject$ProviderLoader.class > /jdk.jsobject/netscape/javascript/JSObject.class > > -DrD- > >> jdk9-dev is not the right mailing list. I bcc?ed it and add jigsaw-dev instead. >> >> >>> On Mar 3, 2016, at 3:57 PM, Kevin Rushforth wrote: >>> >>> Looks OK to me. I did a quick test build and I can see the new package in the exploded JDK, but not in the images. Maybe I did something wrong? >>> >> >> Good catch. >> >> jdk.jsobject needs to be added in MAIN_MODULES list in make/Images.gmk >> >> Mandy >> >>> -- Kevin >>> >>> >>> David DeHaven wrote: >>>>>> JBS Issue: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8132743 >>>>>> >>>>>> >>>>>> Code review: >>>>>> >>>>>> http://cr.openjdk.java.net/~ddehaven/8132743/webrev.0/ >>>>>> >>>>>> >>>>>> >>>>> Looks okay. There is no @since - I guess it?s okay because netscape.javascript has been shipped with plugin for long time. >>>>> >>>>> >>>> >>>> I can't track down when it was first included. It pre-dates anything I've looked at so far. >>>> >>>> >>>> >>>> >>>>> package-info.java >>>>> "when running in an {@link java.applet.Applet Applet}? - is this true when running with JavaFX webkit? >>>>> >>>>> >>>> >>>> Yes, I believe so, assuming you have a JSObject representing the root window object. Maybe that should be reworded, I think just remove the "when running in an Applet" part. >>>> >>>> >>>> >>>> >>>>> JSObject.java >>>>> @throws JSException is missing in the methods >>>>> >>>>> Does it throw NPE if the parameter is null? Or JSException - that needs to be specified. >>>>> >>>>> Nit: it?d be good to wrap null with {@code null} in the javadoc. >>>>> >>>>> >>>> >>>> Ok. I can fix that. >>>> >>>> -DrD- >>>> >>>> >>>> >> > From mandy.chung at oracle.com Fri Mar 4 04:54:09 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 3 Mar 2016 20:54:09 -0800 Subject: [9-dev] RfR: JDK-8132743: Move netscape.javascript package from jdk.plugin to new module In-Reply-To: <411EAC9F-CA8C-4A4C-84D1-D87375567EDE@oracle.com> References: <0DB5EFFD-B4B4-45BA-B866-1AC0DCFDBF90@oracle.com> <61E2A789-BFFC-401F-AA15-425A3702F5B7@oracle.com> <56D8CF6F.3030502@oracle.com> <2CC76624-65B0-4CF6-9EF3-98B489DD991C@oracle.com> <034652C8-6B32-4E12-9AB9-02912CD80905@oracle.com> <411EAC9F-CA8C-4A4C-84D1-D87375567EDE@oracle.com> Message-ID: <9274C38A-C570-4252-8CC3-22BF27DD64AF@oracle.com> > On Mar 3, 2016, at 7:36 PM, David DeHaven wrote: > > > Updated webrev: > http://cr.openjdk.java.net/~ddehaven/8132743/webrev.1/ > Looks fine to me. Thanks for the update. thanks Mandy From sundararajan.athijegannathan at oracle.com Fri Mar 4 05:07:08 2016 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Fri, 04 Mar 2016 05:07:08 +0000 Subject: hg: jigsaw/jake/nashorn: removed -Xpatch and -Xbootclasspath options in nasgen tool invocation. Message-ID: <201603040507.u24578cc015116@aojmv0008.oracle.com> Changeset: 64016e0013ca Author: sundar Date: 2016-03-04 10:36 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/64016e0013ca removed -Xpatch and -Xbootclasspath options in nasgen tool invocation. ! make/BuildNashorn.gmk From Alan.Bateman at oracle.com Fri Mar 4 07:05:15 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 4 Mar 2016 07:05:15 +0000 Subject: -XaddExports: not recognized in JavaVMInitArgs on Windows In-Reply-To: <6482B306-52D9-44BF-8968-DD856161C240@oracle.com> References: <56D8BF8F.2040702@oracle.com> <6482B306-52D9-44BF-8968-DD856161C240@oracle.com> Message-ID: <56D933AB.8090800@oracle.com> On 03/03/2016 23:55, Mandy Chung wrote: > : > It?s a known open issue (I couldn?t find from JBS yet and will file one). > > The issue is tracked as JDK-8136930 [1], the main issue is whether there is a documented way for custom launchers to do the equivalent of the launcher -X options. For now then just set the property as Mandy pointed out. -Alan [1] https://bugs.openjdk.java.net/browse/JDK-8136930 From Alan.Bateman at oracle.com Fri Mar 4 08:10:58 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 4 Mar 2016 08:10:58 +0000 Subject: jlink and automatic modules In-Reply-To: <2E18832D-CC36-40FA-AAB0-6F4946C6ECEE@luminis.eu> References: <8C206F17-19BB-46E9-9A6B-15FAC4D17F56@luminis.eu> <56D85D56.7030109@oracle.com> <2E18832D-CC36-40FA-AAB0-6F4946C6ECEE@luminis.eu> Message-ID: <56D94312.2080809@oracle.com> On 03/03/2016 16:04, Sander Mak wrote: > : > Thanks, that explains it. > > The difference in behavior between the two modulepaths threw me off for a bit. Whether it's the right thing to do almost sounds more like a philosophical rather than a technical discussion? > Automatic modules are for migration and so may have references to types on the class path. If an automatic module is linked into a run-time image then it could result in dangling references or maybe a DOA run-time image unless used with -cp. The other thing is the optimizers and transformers that execute at link-time as they wouldn't have a "whole world" view. I think these are the main areas that need to be pondered before deciding whether to allow this or not. -Alan From alan.bateman at oracle.com Fri Mar 4 08:57:48 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 04 Mar 2016 08:57:48 +0000 Subject: hg: jigsaw/jake/jdk: Minor javadoc fixes Message-ID: <201603040857.u248vmtX013123@aojmv0008.oracle.com> Changeset: 749136d24009 Author: alanb Date: 2016-03-04 08:57 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/749136d24009 Minor javadoc fixes ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java ! src/java.base/share/classes/java/lang/reflect/Layer.java From jan.lahoda at oracle.com Fri Mar 4 09:27:08 2016 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Fri, 04 Mar 2016 09:27:08 +0000 Subject: hg: jigsaw/jake/langtools: 8151202: jdk/jshell/CompletionSuggestionTest.java fails in jake after jdk-9+108 integration Message-ID: <201603040927.u249R8MM026116@aojmv0008.oracle.com> Changeset: dd284d97bd89 Author: jlahoda Date: 2016-03-04 10:25 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/dd284d97bd89 8151202: jdk/jshell/CompletionSuggestionTest.java fails in jake after jdk-9+108 integration Summary: Re-adjusting test for the java.home marker file. ! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java ! test/ProblemList.jake.txt From harold.seigel at oracle.com Fri Mar 4 13:17:18 2016 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Fri, 04 Mar 2016 13:17:18 +0000 Subject: hg: jigsaw/jake/hotspot: Fix use of unified loggin that was commented out in the merge (JDK-8150999) Message-ID: <201603041317.u24DHIJi013071@aojmv0008.oracle.com> Changeset: b8822efbe831 Author: hseigel Date: 2016-03-04 07:50 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b8822efbe831 Fix use of unified loggin that was commented out in the merge (JDK-8150999) ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/modules.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! test/runtime/modules/Xpatch/XpatchTraceCL.java From alan.bateman at oracle.com Fri Mar 4 13:31:11 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 04 Mar 2016 13:31:11 +0000 Subject: hg: jigsaw/jake/jdk: 2 new changesets Message-ID: <201603041331.u24DVGpq020122@aojmv0008.oracle.com> Changeset: 4d841f45d746 Author: alanb Date: 2016-03-04 11:10 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4d841f45d746 Check RuntimePermission getClassLoader eagerly ! src/java.base/share/classes/java/lang/reflect/Layer.java Changeset: 6ebf0d54f960 Author: alanb Date: 2016-03-04 13:30 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6ebf0d54f960 Fix typo in javadoc ! src/java.base/share/classes/java/lang/module/Configuration.java From lois.foltan at oracle.com Fri Mar 4 13:34:35 2016 From: lois.foltan at oracle.com (lois.foltan at oracle.com) Date: Fri, 04 Mar 2016 13:34:35 +0000 Subject: hg: jigsaw/jake/hotspot: CDS changes based on review comments. Message-ID: <201603041334.u24DYZej021817@aojmv0008.oracle.com> Changeset: a574ffaf90a9 Author: ccheung Date: 2016-03-03 16:01 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a574ffaf90a9 CDS changes based on review comments. Reviewed-by: iklam, lfoltan ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoader.hpp ! src/share/vm/memory/metaspaceShared.cpp From Alan.Bateman at oracle.com Fri Mar 4 13:39:29 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 4 Mar 2016 13:39:29 +0000 Subject: [9-dev] RfR: JDK-8132743: Move netscape.javascript package from jdk.plugin to new module In-Reply-To: <9274C38A-C570-4252-8CC3-22BF27DD64AF@oracle.com> References: <0DB5EFFD-B4B4-45BA-B866-1AC0DCFDBF90@oracle.com> <61E2A789-BFFC-401F-AA15-425A3702F5B7@oracle.com> <56D8CF6F.3030502@oracle.com> <2CC76624-65B0-4CF6-9EF3-98B489DD991C@oracle.com> <034652C8-6B32-4E12-9AB9-02912CD80905@oracle.com> <411EAC9F-CA8C-4A4C-84D1-D87375567EDE@oracle.com> <9274C38A-C570-4252-8CC3-22BF27DD64AF@oracle.com> Message-ID: <56D99011.20503@oracle.com> On 04/03/2016 04:54, Mandy Chung wrote: >> On Mar 3, 2016, at 7:36 PM, David DeHaven wrote: >> >> >> Updated webrev: >> http://cr.openjdk.java.net/~ddehaven/8132743/webrev.1/ >> > Looks fine to me. Thanks for the update. > Just reading the javadoc again and I wonder about this statement in the package description: "The classes in this package were initially specified by Netscape, and are the de facto standard mechanism for calling JavaScript from the Java runtime." Does need to qualify the statement to say when in the web browser? Just thinking about the scripting API as a way to integrate with JavaScript. -Alan From david.dehaven at oracle.com Fri Mar 4 15:31:05 2016 From: david.dehaven at oracle.com (David DeHaven) Date: Fri, 4 Mar 2016 07:31:05 -0800 Subject: [9-dev] RfR: JDK-8132743: Move netscape.javascript package from jdk.plugin to new module In-Reply-To: <56D99011.20503@oracle.com> References: <0DB5EFFD-B4B4-45BA-B866-1AC0DCFDBF90@oracle.com> <61E2A789-BFFC-401F-AA15-425A3702F5B7@oracle.com> <56D8CF6F.3030502@oracle.com> <2CC76624-65B0-4CF6-9EF3-98B489DD991C@oracle.com> <034652C8-6B32-4E12-9AB9-02912CD80905@oracle.com> <411EAC9F-CA8C-4A4C-84D1-D87375567EDE@oracle.com> <9274C38A-C570-4252-8CC3-22BF27DD64AF@oracle.com> <56D99011.20503@oracle.com> Message-ID: <337EE1E3-C52C-4297-A715-BCFF8374E2FE@oracle.com> >>> Updated webrev: >>> http://cr.openjdk.java.net/~ddehaven/8132743/webrev.1/ >>> >> Looks fine to me. Thanks for the update. >> > Just reading the javadoc again and I wonder about this statement in the package description: > > "The classes in this package were initially specified by Netscape, and are the de facto standard mechanism for calling JavaScript from the Java runtime." > > Does need to qualify the statement to say when in the web browser? Just thinking about the scripting API as a way to integrate with JavaScript. The use with JavaScript engines goes beyond just browser use (it can be used by Nashorn) but HTML DOM access is only relevant when using with a browser or with WebKit in JavaFX. It's how JavaFX applications communicate with web sites being rendered in a WebView and, in theory (only because I haven't tried it myself), you should be able to manipulate the HTML DOM directly once you gain access to it. You can do the same from an applet running in an browser via Java plugin. I don't know if that clarifies anything or makes it worse... caffeine hasn't kicked in yet this morning. -DrD- From kevin.rushforth at oracle.com Fri Mar 4 15:44:28 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 04 Mar 2016 07:44:28 -0800 Subject: [9-dev] RfR: JDK-8132743: Move netscape.javascript package from jdk.plugin to new module In-Reply-To: <411EAC9F-CA8C-4A4C-84D1-D87375567EDE@oracle.com> References: <0DB5EFFD-B4B4-45BA-B866-1AC0DCFDBF90@oracle.com> <61E2A789-BFFC-401F-AA15-425A3702F5B7@oracle.com> <56D8CF6F.3030502@oracle.com> <2CC76624-65B0-4CF6-9EF3-98B489DD991C@oracle.com> <034652C8-6B32-4E12-9AB9-02912CD80905@oracle.com> <411EAC9F-CA8C-4A4C-84D1-D87375567EDE@oracle.com> Message-ID: <56D9AD5C.5010002@oracle.com> Looks good to me. -- Kevin David DeHaven wrote: > Updated webrev: > http://cr.openjdk.java.net/~ddehaven/8132743/webrev.1/ > > Added jdk.jsobject to MAIN_MODULES > Made suggested Javadoc changes > Gave JSException a real serialVersionUID > > -DrD- > > > >> On Mar 3, 2016, at 5:06 PM, David DeHaven wrote: >> >> >> Adding it to MAIN_MODULES, I now see it in bootmodules.jimage: >> /jdk.jsobject/jdk/internal/netscape/javascript/spi/JSObjectProvider.class >> /jdk.jsobject/netscape/javascript/JSException.class >> /jdk.jsobject/netscape/javascript/JSObject$ProviderLoader$1.class >> /jdk.jsobject/netscape/javascript/JSObject$ProviderLoader.class >> /jdk.jsobject/netscape/javascript/JSObject.class >> >> -DrD- >> >> >>> jdk9-dev is not the right mailing list. I bcc?ed it and add jigsaw-dev instead. >>> >>> >>> >>>> On Mar 3, 2016, at 3:57 PM, Kevin Rushforth wrote: >>>> >>>> Looks OK to me. I did a quick test build and I can see the new package in the exploded JDK, but not in the images. Maybe I did something wrong? >>>> >>>> >>> Good catch. >>> >>> jdk.jsobject needs to be added in MAIN_MODULES list in make/Images.gmk >>> >>> Mandy >>> >>> >>>> -- Kevin >>>> >>>> >>>> David DeHaven wrote: >>>> >>>>>>> JBS Issue: >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8132743 >>>>>>> >>>>>>> >>>>>>> Code review: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~ddehaven/8132743/webrev.0/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Looks okay. There is no @since - I guess it?s okay because netscape.javascript has been shipped with plugin for long time. >>>>>> >>>>>> >>>>>> >>>>> I can't track down when it was first included. It pre-dates anything I've looked at so far. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> package-info.java >>>>>> "when running in an {@link java.applet.Applet Applet}? - is this true when running with JavaFX webkit? >>>>>> >>>>>> >>>>>> >>>>> Yes, I believe so, assuming you have a JSObject representing the root window object. Maybe that should be reworded, I think just remove the "when running in an Applet" part. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> JSObject.java >>>>>> @throws JSException is missing in the methods >>>>>> >>>>>> Does it throw NPE if the parameter is null? Or JSException - that needs to be specified. >>>>>> >>>>>> Nit: it?d be good to wrap null with {@code null} in the javadoc. >>>>>> >>>>>> >>>>>> >>>>> Ok. I can fix that. >>>>> >>>>> -DrD- >>>>> >>>>> >>>>> >>>>> > > From erik.joelsson at oracle.com Fri Mar 4 16:04:44 2016 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Fri, 04 Mar 2016 16:04:44 +0000 Subject: hg: jigsaw/jake/jdk: Fixed bootcycle builds by correcting merge mistake Message-ID: <201603041604.u24G4iho002549@aojmv0008.oracle.com> Changeset: 2db2becfab6e Author: erikj Date: 2016-03-04 16:34 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2db2becfab6e Fixed bootcycle builds by correcting merge mistake ! make/Tools.gmk From erik.joelsson at oracle.com Fri Mar 4 16:04:54 2016 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Fri, 04 Mar 2016 16:04:54 +0000 Subject: hg: jigsaw/jake/nashorn: Relaxed build dependencies slightly Message-ID: <201603041604.u24G4s0m002704@aojmv0008.oracle.com> Changeset: 3aafb5e2bc1d Author: erikj Date: 2016-03-04 16:34 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/3aafb5e2bc1d Relaxed build dependencies slightly ! make/BuildNashorn.gmk From Alan.Bateman at oracle.com Fri Mar 4 16:47:22 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 4 Mar 2016 16:47:22 +0000 Subject: Project Jigsaw, build 108 on 03-03-2016 (#4576) Message-ID: <56D9BC1A.3020204@oracle.com> jigsaw/jake has been sync'ed up to jdk-9+108 and the EA build [1] has been refreshed. -Alan [1] https://jdk9.java.net/jigsaw/ From jan.lahoda at oracle.com Fri Mar 4 18:16:25 2016 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Fri, 04 Mar 2016 18:16:25 +0000 Subject: hg: jigsaw/jake/langtools: Temporarily deleting module-info.class-es for langtools modules, so that -Xpatch works for the langtools' ant build. Message-ID: <201603041816.u24IGPwS005053@aojmv0008.oracle.com> Changeset: 31254fcb00f2 Author: jlahoda Date: 2016-03-04 19:16 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/31254fcb00f2 Temporarily deleting module-info.class-es for langtools modules, so that -Xpatch works for the langtools' ant build. ! make/build.xml From volker.simonis at gmail.com Fri Mar 4 19:08:56 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 4 Mar 2016 20:08:56 +0100 Subject: Need help testing the EA builds In-Reply-To: <56D7002A.9000509@oracle.com> References: <56D7002A.9000509@oracle.com> Message-ID: Hi Alan, Dmitry, I've tried today to build the jake repository on AIX. Unfortunately that doesn't work because we now have a hard dependency on SA which is required by jcmd: $cat jdk/src/jdk.jcmd/share/classes/module-info.java module jdk.jcmd { requires jdk.attach; requires jdk.jvmstat; requires jdk.hotspot.agent; // until JDK-8059035 is complete } This will break every platform which does not implement the SA. There already exists a bug for this issue: 8059035: Break the (implicit) dependency from jdk.jcmd to jdk.hotspot.agent https://bugs.openjdk.java.net/browse/JDK-8059035 Is there any chance that this will be resolved soon? Or is there an easy way to disable this dependency on AIX? Regards, Volker On Wed, Mar 2, 2016 at 4:00 PM, Alan Bateman wrote: > > We are starting to think through how to bring the module system that is the > monster patch in jigsaw/jake forest into the JDK 9 main line. > > There are many reasons to do this. One reason is to reduce testing effort. > Another is to reduce the cost of sync ups as it takes a lot of effort each > week to merge in the changes from JDK 9. We also have confused some > developers by having two early access (EA) builds, one EA build with Project > Jigsaw, the other without. It should also be obvious that time is moving on > and we don't want to be rushing things right before JDK 9 Feature Complete. > > Merging into the JDK 9 main line will be a big step and there are many > things that need to be done to make this happen. The proposal will most > likely be to take snapshot of what we have in jake and bring it into JDK 9 > after stabilization, testing and of course review. Once it is in JDK 9 then > we'll continue to iterate and work through the many issues that need > attention. > > One thing that would be useful is to get as many people as possible to try > out the EA builds [1]. It really helps confidence when there is confirmation > that existing libraries and applications work as before. If there are bugs > or issues that involve any of the supported interfaces then we want to know. > We know well that there are several compatibility issues and we've attempted > to capture those in the Risks and Assumption section of JEP 261 [2]. > > We also interested in bug reports and issues from those trying out the EA > builds to create their own modules or migrating existing code or libraries > to modules. Bonus points for those brave enough to try out some of the many > new APIs too. > > -Alan > > [1] https://jdk9.java.net/jigsaw/ > [2] http://openjdk.java.net/jeps/261 From philip.race at oracle.com Fri Mar 4 19:14:12 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 04 Mar 2016 11:14:12 -0800 Subject: [9] Review Request: 8151041 Jigsaw-only failure of javax/sound/sampled/spi/AudioFileReader/RecognizeWaveExtensible.java In-Reply-To: <56D9DB12.9020409@oracle.com> References: <56D9DB12.9020409@oracle.com> Message-ID: <56D9DE84.8010601@oracle.com> +1 -phil. On 03/04/2016 10:59 AM, Sergey Bylokhov wrote: > Hello, > Please review the small fix for jdk9-jake. > > In the fix the list in "module java.desktop" is updated, and now it > contains the same data as META-INF.services/javax.sound.xxx of the > current jdk9-dev. > I seems I'll need a sponsor to push it to the jake? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8151041 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/8151041/webrev.00 > From Alan.Bateman at oracle.com Fri Mar 4 21:03:43 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 4 Mar 2016 21:03:43 +0000 Subject: Need help testing the EA builds In-Reply-To: References: <56D7002A.9000509@oracle.com> Message-ID: <56D9F82F.2070300@oracle.com> On 04/03/2016 19:08, Volker Simonis wrote: > Hi Alan, Dmitry, > > I've tried today to build the jake repository on AIX. Unfortunately > that doesn't work because we now have a hard dependency on SA which is > required by jcmd: > > $cat jdk/src/jdk.jcmd/share/classes/module-info.java > module jdk.jcmd { > requires jdk.attach; > requires jdk.jvmstat; > requires jdk.hotspot.agent; // until JDK-8059035 is complete > } > > This will break every platform which does not implement the SA. > > There already exists a bug for this issue: > 8059035: Break the (implicit) dependency from jdk.jcmd to jdk.hotspot.agent > https://bugs.openjdk.java.net/browse/JDK-8059035 > > Is there any chance that this will be resolved soon? > Or is there an easy way to disable this dependency on AIX? > I don't know if Dmitry has short term plans to address that one but thing we could do is drop the "requires jdk.hotspot.agent" and move it: src/jdk.jcmd/$OS/classes/module-info.java.extra where $OS is linux, solaris or the other platforms that SA is supported on. At build time then the .extra files will augment the module-info.java. -Alan. From mandy.chung at oracle.com Fri Mar 4 22:41:59 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 04 Mar 2016 22:41:59 +0000 Subject: hg: jigsaw/jake: Add --disable-keep-packaged-modules configure option Message-ID: <201603042242.u24MfxVl022433@aojmv0008.oracle.com> Changeset: 6fa251220992 Author: mchung Date: 2016-03-04 14:36 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/6fa251220992 Add --disable-keep-packaged-modules configure option ! common/autoconf/configure.ac ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 ! common/autoconf/spec.gmk.in ! make/Images.gmk From jonathan.gibbons at oracle.com Sat Mar 5 00:49:18 2016 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Sat, 05 Mar 2016 00:49:18 +0000 Subject: hg: jigsaw/jake/langtools: fix missing package label in new doclet Message-ID: <201603050049.u250nI9x013353@aojmv0008.oracle.com> Changeset: e6b63f4a002a Author: jjg Date: 2016-03-04 16:49 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/e6b63f4a002a fix missing package label in new doclet ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! test/jdk/javadoc/doclet/testSubTitle/TestSubTitle.java From forax at univ-mlv.fr Sat Mar 5 09:00:53 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 5 Mar 2016 10:00:53 +0100 (CET) Subject: jlink and automatic modules In-Reply-To: <56D94312.2080809@oracle.com> References: <8C206F17-19BB-46E9-9A6B-15FAC4D17F56@luminis.eu> <56D85D56.7030109@oracle.com> <2E18832D-CC36-40FA-AAB0-6F4946C6ECEE@luminis.eu> <56D94312.2080809@oracle.com> Message-ID: <1758537220.4087042.1457168453242.JavaMail.zimbra@u-pem.fr> IMO, the real question is "should automatic modules see classes from the classpath" ? if the answer is yes, then they can not be used with jlink. R?mi ----- Mail original ----- > De: "Alan Bateman" > ?: "Sander Mak" , "jigsaw-dev" > Envoy?: Vendredi 4 Mars 2016 09:10:58 > Objet: Re: jlink and automatic modules > > > > On 03/03/2016 16:04, Sander Mak wrote: > > : > > Thanks, that explains it. > > > > The difference in behavior between the two modulepaths threw me off for a > > bit. Whether it's the right thing to do almost sounds more like a > > philosophical rather than a technical discussion? > > > Automatic modules are for migration and so may have references to types > on the class path. If an automatic module is linked into a run-time > image then it could result in dangling references or maybe a DOA > run-time image unless used with -cp. The other thing is the optimizers > and transformers that execute at link-time as they wouldn't have a > "whole world" view. I think these are the main areas that need to be > pondered before deciding whether to allow this or not. > > -Alan > From alan.bateman at oracle.com Sat Mar 5 09:15:13 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 05 Mar 2016 09:15:13 +0000 Subject: hg: jigsaw/jake/jdk: javax/sound/sampled/spi/AudioFileReader/RecognizeWaveExtensible.java failing Message-ID: <201603050915.u259FEpb019788@aojmv0008.oracle.com> Changeset: 5f757f33fe00 Author: serb Date: 2016-03-05 08:45 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5f757f33fe00 javax/sound/sampled/spi/AudioFileReader/RecognizeWaveExtensible.java failing ! src/java.desktop/share/classes/module-info.java From Alan.Bateman at oracle.com Sat Mar 5 09:21:49 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 5 Mar 2016 09:21:49 +0000 Subject: jlink and automatic modules In-Reply-To: <1758537220.4087042.1457168453242.JavaMail.zimbra@u-pem.fr> References: <8C206F17-19BB-46E9-9A6B-15FAC4D17F56@luminis.eu> <56D85D56.7030109@oracle.com> <2E18832D-CC36-40FA-AAB0-6F4946C6ECEE@luminis.eu> <56D94312.2080809@oracle.com> <1758537220.4087042.1457168453242.JavaMail.zimbra@u-pem.fr> Message-ID: <56DAA52D.8070704@oracle.com> On 05/03/2016 09:00, Remi Forax wrote: > IMO, the real question is "should automatic modules see classes from the classpath" ? > Automatic modules are for bridging to the class path so they have to read the unnamed module (or more specifically, they read all unnamed modules). -Alan. From alan.bateman at oracle.com Sat Mar 5 14:41:33 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 05 Mar 2016 14:41:33 +0000 Subject: hg: jigsaw/jake/hotspot: Add support for early VMStart event Message-ID: <201603051441.u25EfXd3002711@aojmv0008.oracle.com> Changeset: eb282913bc35 Author: sspitsyn Date: 2016-03-05 14:10 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/eb282913bc35 Add support for early VMStart event ! src/share/vm/prims/jvmti.xml ! src/share/vm/prims/jvmti.xsl ! src/share/vm/prims/jvmtiEnter.xsl ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiEnvBase.hpp ! src/share/vm/prims/jvmtiEventController.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiH.xsl ! src/share/vm/prims/jvmtiLib.xsl ! src/share/vm/prims/jvmtiManageCapabilities.cpp ! src/share/vm/runtime/thread.cpp From alan.bateman at oracle.com Sat Mar 5 14:41:53 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 05 Mar 2016 14:41:53 +0000 Subject: hg: jigsaw/jake/jdk: Add support for early VMStart event Message-ID: <201603051441.u25EfrLu002843@aojmv0008.oracle.com> Changeset: 64e1d96b83a4 Author: sspitsyn Date: 2016-03-05 14:11 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/64e1d96b83a4 Add support for early VMStart event ! src/java.base/share/native/include/jvmti.h From alan.bateman at oracle.com Sat Mar 5 17:57:05 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 05 Mar 2016 17:57:05 +0000 Subject: hg: jigsaw/jake/jdk: 4 new changesets Message-ID: <201603051757.u25Hv5Ph013564@aojmv0008.oracle.com> Changeset: cc21247fa902 Author: alanb Date: 2016-03-05 10:29 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/cc21247fa902 Change -Xpatch to emit warning if module-info.class found in patch ! src/java.base/share/classes/jdk/internal/module/ModulePatcher.java Changeset: 8ca0923e9d39 Author: alanb Date: 2016-03-05 15:11 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8ca0923e9d39 Rename ModuleFinder.ofInstalled to ofSystem ! make/src/classes/build/tools/jigsaw/GenGraphs.java ! make/src/classes/build/tools/jigsaw/ModuleSummary.java ! src/java.base/share/classes/java/lang/module/ModuleFinder.java ! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java ! test/jdk/jigsaw/etc/JdkModules.java ! test/jdk/jigsaw/module/ModuleFinderTest.java ! test/jdk/jigsaw/tools/jlink/plugins/InstalledModuleDescriptors/InstalledModulesTest.java Changeset: cdb917207eaa Author: alanb Date: 2016-03-05 17:41 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/cdb917207eaa Update Exports.targets to return Set ! make/src/classes/build/tools/jigsaw/ModuleSummary.java ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java ! src/java.base/share/classes/java/lang/module/Resolver.java ! src/java.base/share/classes/java/lang/reflect/Module.java ! src/java.base/share/classes/jdk/internal/loader/Loader.java ! src/java.base/share/classes/jdk/internal/module/ClassFileAttributes.java ! src/java.base/share/classes/sun/launcher/LauncherHelper.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/InstalledModuleDescriptorPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/asm/AsmPoolImpl.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/asm/AsmPools.java ! test/jdk/jigsaw/module/ModuleDescriptorTest.java ! test/jdk/jigsaw/reflect/Layer/BasicLayerTest.java ! test/jdk/jigsaw/reflect/Module/BasicModuleTest.java Changeset: b54c57700257 Author: alanb Date: 2016-03-05 17:54 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b54c57700257 Merge From alan.bateman at oracle.com Sat Mar 5 17:57:12 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 05 Mar 2016 17:57:12 +0000 Subject: hg: jigsaw/jake/langtools: 2 new changesets Message-ID: <201603051757.u25HvCAb013623@aojmv0008.oracle.com> Changeset: 7d58ddf15811 Author: alanb Date: 2016-03-05 15:12 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/7d58ddf15811 Rename ModuleFinder.ofInstalled to ofSystem ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/ModuleWrappers.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleAnalyzer.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModulePaths.java Changeset: 0761ffb02c59 Author: alanb Date: 2016-03-05 17:55 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/0761ffb02c59 Update Exports.targets to return Set ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleAnalyzer.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModulePaths.java From david.dehaven at oracle.com Sat Mar 5 18:54:43 2016 From: david.dehaven at oracle.com (David DeHaven) Date: Sat, 5 Mar 2016 10:54:43 -0800 Subject: [9-dev] RfR: JDK-8132743: Move netscape.javascript package from jdk.plugin to new module In-Reply-To: <56D9AD5C.5010002@oracle.com> References: <0DB5EFFD-B4B4-45BA-B866-1AC0DCFDBF90@oracle.com> <61E2A789-BFFC-401F-AA15-425A3702F5B7@oracle.com> <56D8CF6F.3030502@oracle.com> <2CC76624-65B0-4CF6-9EF3-98B489DD991C@oracle.com> <034652C8-6B32-4E12-9AB9-02912CD80905@oracle.com> <411EAC9F-CA8C-4A4C-84D1-D87375567EDE@oracle.com> <56D9AD5C.5010002@oracle.com> Message-ID: I've updated the webrev, hopefully one last time with feedback from Joe Darcy. http://cr.openjdk.java.net/~ddehaven/8132743/webrev.2/ - Relocated package Javadoc to above the package declaration in package-info.java - Reworded the Javadoc on the default JSObject ctor A point was brought up that the default ctor could probably be package-private, but there's no time to investigate what the impact would be so I will file a follow-up issue to investigate doing that at a later date. -DrD- > On Mar 4, 2016, at 7:44 AM, Kevin Rushforth wrote: > > Looks good to me. > > -- Kevin > > > David DeHaven wrote: >> Updated webrev: >> >> http://cr.openjdk.java.net/~ddehaven/8132743/webrev.1/ >> >> >> Added jdk.jsobject to MAIN_MODULES >> Made suggested Javadoc changes >> Gave JSException a real serialVersionUID >> >> -DrD- >> >> >> >> >>> On Mar 3, 2016, at 5:06 PM, David DeHaven >>> wrote: >>> >>> >>> Adding it to MAIN_MODULES, I now see it in bootmodules.jimage: >>> /jdk.jsobject/jdk/internal/netscape/javascript/spi/JSObjectProvider.class >>> /jdk.jsobject/netscape/javascript/JSException.class >>> /jdk.jsobject/netscape/javascript/JSObject$ProviderLoader$1.class >>> /jdk.jsobject/netscape/javascript/JSObject$ProviderLoader.class >>> /jdk.jsobject/netscape/javascript/JSObject.class >>> >>> -DrD- >>> >>> >>> >>>> jdk9-dev is not the right mailing list. I bcc?ed it and add jigsaw-dev instead. >>>> >>>> >>>> >>>> >>>>> On Mar 3, 2016, at 3:57 PM, Kevin Rushforth >>>>> wrote: >>>>> >>>>> Looks OK to me. I did a quick test build and I can see the new package in the exploded JDK, but not in the images. Maybe I did something wrong? >>>>> >>>>> >>>>> >>>> Good catch. >>>> >>>> jdk.jsobject needs to be added in MAIN_MODULES list in make/Images.gmk >>>> >>>> Mandy >>>> >>>> >>>> >>>>> -- Kevin >>>>> >>>>> >>>>> David DeHaven wrote: >>>>> >>>>> >>>>>>>> JBS Issue: >>>>>>>> >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8132743 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Code review: >>>>>>>> >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ddehaven/8132743/webrev.0/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Looks okay. There is no @since - I guess it?s okay because netscape.javascript has been shipped with plugin for long time. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> I can't track down when it was first included. It pre-dates anything I've looked at so far. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> package-info.java >>>>>>> "when running in an {@link java.applet.Applet Applet}? - is this true when running with JavaFX webkit? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Yes, I believe so, assuming you have a JSObject representing the root window object. Maybe that should be reworded, I think just remove the "when running in an Applet" part. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> JSObject.java >>>>>>> @throws JSException is missing in the methods >>>>>>> >>>>>>> Does it throw NPE if the parameter is null? Or JSException - that needs to be specified. >>>>>>> >>>>>>> Nit: it?d be good to wrap null with {@code null} in the javadoc. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Ok. I can fix that. >>>>>> >>>>>> -DrD- >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >> >> >> From forax at univ-mlv.fr Sat Mar 5 19:50:22 2016 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Sat, 5 Mar 2016 20:50:22 +0100 (CET) Subject: jlink and automatic modules In-Reply-To: <56DAA52D.8070704@oracle.com> References: <8C206F17-19BB-46E9-9A6B-15FAC4D17F56@luminis.eu> <56D85D56.7030109@oracle.com> <2E18832D-CC36-40FA-AAB0-6F4946C6ECEE@luminis.eu> <56D94312.2080809@oracle.com> <1758537220.4087042.1457168453242.JavaMail.zimbra@u-pem.fr> <56DAA52D.8070704@oracle.com> Message-ID: <1817412191.4299173.1457207422291.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Alan Bateman" > ?: "Remi Forax" > Cc: "Sander Mak" , "jigsaw-dev" > Envoy?: Samedi 5 Mars 2016 10:21:49 > Objet: Re: jlink and automatic modules > > > On 05/03/2016 09:00, Remi Forax wrote: > > IMO, the real question is "should automatic modules see classes from the > > classpath" ? > > > Automatic modules are for bridging to the class path so they have to > read the unnamed module (or more specifically, they read all unnamed > modules). if there are jars (with no module metadata) in the modulepath and in the classpath, what about having everything in the modulepath (module and jars), nothing in the classpath and use the unamed modules only in scenarios where currently we use default package. at least it will make the rules between the different parts of the code simpler. > > -Alan. > R?mi From mandy.chung at oracle.com Sat Mar 5 20:19:22 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Sat, 5 Mar 2016 12:19:22 -0800 Subject: [9-dev] RfR: JDK-8132743: Move netscape.javascript package from jdk.plugin to new module In-Reply-To: References: <0DB5EFFD-B4B4-45BA-B866-1AC0DCFDBF90@oracle.com> <61E2A789-BFFC-401F-AA15-425A3702F5B7@oracle.com> <56D8CF6F.3030502@oracle.com> <2CC76624-65B0-4CF6-9EF3-98B489DD991C@oracle.com> <034652C8-6B32-4E12-9AB9-02912CD80905@oracle.com> <411EAC9F-CA8C-4A4C-84D1-D87375567EDE@oracle.com> <56D9AD5C.5010002@oracle.com> Message-ID: <87FF94CE-FE1A-43AE-8340-F4CC727E9923@oracle.com> On Mar 5, 2016, at 10:54 AM, David DeHaven wrote: > > > I've updated the webrev, hopefully one last time with feedback from Joe Darcy. > http://cr.openjdk.java.net/~ddehaven/8132743/webrev.2/ > > - Relocated package Javadoc to above the package declaration in package-info.java > - Reworded the Javadoc on the default JSObject ctor > Looks fine. Mandy > A point was brought up that the default ctor could probably be package-private, but there's no time to investigate what the impact would be so I will file a follow-up issue to investigate doing that at a later date. > > -DrD- > >> On Mar 4, 2016, at 7:44 AM, Kevin Rushforth wrote: >> >> Looks good to me. >> >> -- Kevin >> >> >> David DeHaven wrote: >>> Updated webrev: >>> >>> http://cr.openjdk.java.net/~ddehaven/8132743/webrev.1/ >>> >>> >>> Added jdk.jsobject to MAIN_MODULES >>> Made suggested Javadoc changes >>> Gave JSException a real serialVersionUID >>> >>> -DrD- >>> >>> >>> >>> >>>> On Mar 3, 2016, at 5:06 PM, David DeHaven >>>> wrote: >>>> >>>> >>>> Adding it to MAIN_MODULES, I now see it in bootmodules.jimage: >>>> /jdk.jsobject/jdk/internal/netscape/javascript/spi/JSObjectProvider.class >>>> /jdk.jsobject/netscape/javascript/JSException.class >>>> /jdk.jsobject/netscape/javascript/JSObject$ProviderLoader$1.class >>>> /jdk.jsobject/netscape/javascript/JSObject$ProviderLoader.class >>>> /jdk.jsobject/netscape/javascript/JSObject.class >>>> >>>> -DrD- >>>> >>>> >>>> >>>>> jdk9-dev is not the right mailing list. I bcc?ed it and add jigsaw-dev instead. >>>>> >>>>> >>>>> >>>>> >>>>>> On Mar 3, 2016, at 3:57 PM, Kevin Rushforth >>>>>> wrote: >>>>>> >>>>>> Looks OK to me. I did a quick test build and I can see the new package in the exploded JDK, but not in the images. Maybe I did something wrong? >>>>> Good catch. >>>>> >>>>> jdk.jsobject needs to be added in MAIN_MODULES list in make/Images.gmk >>>>> >>>>> Mandy >>>>> >>>>> >>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> David DeHaven wrote: >>>>>> >>>>>> >>>>>>>>> JBS Issue: >>>>>>>>> >>>>>>>>> >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8132743 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Code review: >>>>>>>>> >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ddehaven/8132743/webrev.0/ >>>>>>>> Looks okay. There is no @since - I guess it?s okay because netscape.javascript has been shipped with plugin for long time. >>>>>>> I can't track down when it was first included. It pre-dates anything I've looked at so far. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> package-info.java >>>>>>>> "when running in an {@link java.applet.Applet Applet}? - is this true when running with JavaFX webkit? >>>>>>> Yes, I believe so, assuming you have a JSObject representing the root window object. Maybe that should be reworded, I think just remove the "when running in an Applet" part. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> JSObject.java >>>>>>>> @throws JSException is missing in the methods >>>>>>>> >>>>>>>> Does it throw NPE if the parameter is null? Or JSException - that needs to be specified. >>>>>>>> >>>>>>>> Nit: it?d be good to wrap null with {@code null} in the javadoc. >>>>>>> Ok. I can fix that. >>>>>>> >>>>>>> -DrD- > From kevin.rushforth at oracle.com Sat Mar 5 22:26:01 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 05 Mar 2016 14:26:01 -0800 Subject: [9-dev] RfR: JDK-8132743: Move netscape.javascript package from jdk.plugin to new module In-Reply-To: References: <0DB5EFFD-B4B4-45BA-B866-1AC0DCFDBF90@oracle.com> <61E2A789-BFFC-401F-AA15-425A3702F5B7@oracle.com> <56D8CF6F.3030502@oracle.com> <2CC76624-65B0-4CF6-9EF3-98B489DD991C@oracle.com> <034652C8-6B32-4E12-9AB9-02912CD80905@oracle.com> <411EAC9F-CA8C-4A4C-84D1-D87375567EDE@oracle.com> <56D9AD5C.5010002@oracle.com> Message-ID: <56DB5CF9.2080604@oracle.com> Looks good. -- Kevin David DeHaven wrote: > I've updated the webrev, hopefully one last time with feedback from Joe Darcy. > http://cr.openjdk.java.net/~ddehaven/8132743/webrev.2/ > > - Relocated package Javadoc to above the package declaration in package-info.java > - Reworded the Javadoc on the default JSObject ctor > > A point was brought up that the default ctor could probably be package-private, but there's no time to investigate what the impact would be so I will file a follow-up issue to investigate doing that at a later date. > > -DrD- > > >> On Mar 4, 2016, at 7:44 AM, Kevin Rushforth wrote: >> >> Looks good to me. >> >> -- Kevin >> >> >> David DeHaven wrote: >> >>> Updated webrev: >>> >>> http://cr.openjdk.java.net/~ddehaven/8132743/webrev.1/ >>> >>> >>> Added jdk.jsobject to MAIN_MODULES >>> Made suggested Javadoc changes >>> Gave JSException a real serialVersionUID >>> >>> -DrD- >>> >>> >>> >>> >>> >>>> On Mar 3, 2016, at 5:06 PM, David DeHaven >>>> wrote: >>>> >>>> >>>> Adding it to MAIN_MODULES, I now see it in bootmodules.jimage: >>>> /jdk.jsobject/jdk/internal/netscape/javascript/spi/JSObjectProvider.class >>>> /jdk.jsobject/netscape/javascript/JSException.class >>>> /jdk.jsobject/netscape/javascript/JSObject$ProviderLoader$1.class >>>> /jdk.jsobject/netscape/javascript/JSObject$ProviderLoader.class >>>> /jdk.jsobject/netscape/javascript/JSObject.class >>>> >>>> -DrD- >>>> >>>> >>>> >>>> >>>>> jdk9-dev is not the right mailing list. I bcc?ed it and add jigsaw-dev instead. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> On Mar 3, 2016, at 3:57 PM, Kevin Rushforth >>>>>> wrote: >>>>>> >>>>>> Looks OK to me. I did a quick test build and I can see the new package in the exploded JDK, but not in the images. Maybe I did something wrong? >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Good catch. >>>>> >>>>> jdk.jsobject needs to be added in MAIN_MODULES list in make/Images.gmk >>>>> >>>>> Mandy >>>>> >>>>> >>>>> >>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> David DeHaven wrote: >>>>>> >>>>>> >>>>>> >>>>>>>>> JBS Issue: >>>>>>>>> >>>>>>>>> >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8132743 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Code review: >>>>>>>>> >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ddehaven/8132743/webrev.0/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Looks okay. There is no @since - I guess it?s okay because netscape.javascript has been shipped with plugin for long time. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> I can't track down when it was first included. It pre-dates anything I've looked at so far. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> package-info.java >>>>>>>> "when running in an {@link java.applet.Applet Applet}? - is this true when running with JavaFX webkit? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Yes, I believe so, assuming you have a JSObject representing the root window object. Maybe that should be reworded, I think just remove the "when running in an Applet" part. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> JSObject.java >>>>>>>> @throws JSException is missing in the methods >>>>>>>> >>>>>>>> Does it throw NPE if the parameter is null? Or JSException - that needs to be specified. >>>>>>>> >>>>>>>> Nit: it?d be good to wrap null with {@code null} in the javadoc. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Ok. I can fix that. >>>>>>> >>>>>>> -DrD- >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>> >>> >>> > > From kevin.rushforth at oracle.com Sat Mar 5 23:31:02 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 05 Mar 2016 15:31:02 -0800 Subject: [9-jake] Review request: 8151320: Remove unnecessary addReads from JavaFX Message-ID: <56DB6C36.9050904@oracle.com> Please review the following: https://bugs.openjdk.java.net/browse/JDK-8151320 http://cr.openjdk.java.net/~kcr/8151320/webrev.00/ Now that addReads are no longer necessary in cases where we use core reflection [1] we will eliminate these unneeded calls in the FX jake repo. -- Kevin [1] http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-March/000231.html From Alan.Bateman at oracle.com Sun Mar 6 09:49:23 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 6 Mar 2016 09:49:23 +0000 Subject: jlink and automatic modules In-Reply-To: <1817412191.4299173.1457207422291.JavaMail.zimbra@u-pem.fr> References: <8C206F17-19BB-46E9-9A6B-15FAC4D17F56@luminis.eu> <56D85D56.7030109@oracle.com> <2E18832D-CC36-40FA-AAB0-6F4946C6ECEE@luminis.eu> <56D94312.2080809@oracle.com> <1758537220.4087042.1457168453242.JavaMail.zimbra@u-pem.fr> <56DAA52D.8070704@oracle.com> <1817412191.4299173.1457207422291.JavaMail.zimbra@u-pem.fr> Message-ID: <56DBFD23.8070703@oracle.com> On 05/03/2016 19:50, forax at univ-mlv.fr wrote: > : > if there are jars (with no module metadata) in the modulepath and in the classpath, > what about having everything in the modulepath (module and jars), nothing in the classpath and use the unamed modules only in scenarios where currently we use default package. > It may not be possible to move all JAR files from the class path to the module path. Split packages will the biggest issue. The main advantage of automatic modules is that you can make progress on migration to modules while leaving significant chaos on the class path. -Alan. From Alan.Bateman at oracle.com Sun Mar 6 10:25:01 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 6 Mar 2016 10:25:01 +0000 Subject: [9-dev] RfR: JDK-8132743: Move netscape.javascript package from jdk.plugin to new module In-Reply-To: References: <0DB5EFFD-B4B4-45BA-B866-1AC0DCFDBF90@oracle.com> <61E2A789-BFFC-401F-AA15-425A3702F5B7@oracle.com> <56D8CF6F.3030502@oracle.com> <2CC76624-65B0-4CF6-9EF3-98B489DD991C@oracle.com> <034652C8-6B32-4E12-9AB9-02912CD80905@oracle.com> <411EAC9F-CA8C-4A4C-84D1-D87375567EDE@oracle.com> <56D9AD5C.5010002@oracle.com> Message-ID: <56DC057D.3060608@oracle.com> On 05/03/2016 18:54, David DeHaven wrote: > I've updated the webrev, hopefully one last time with feedback from Joe Darcy. > http://cr.openjdk.java.net/~ddehaven/8132743/webrev.2/ > > - Relocated package Javadoc to above the package declaration in package-info.java > - Reworded the Javadoc on the default JSObject ctor > > A point was brought up that the default ctor could probably be package-private, but there's no time to investigate what the impact would be so I will file a follow-up issue to investigate doing that at a later date. > This looks okay. Also I assume ServiceLoader.loadInstalled is what you want as you only want to find implementations in the run-time image. -Alan From forax at univ-mlv.fr Sun Mar 6 11:59:10 2016 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sun, 06 Mar 2016 11:59:10 +0000 Subject: jlink and automatic modules In-Reply-To: <56DBFD23.8070703@oracle.com> References: <8C206F17-19BB-46E9-9A6B-15FAC4D17F56@luminis.eu> <56D85D56.7030109@oracle.com> <2E18832D-CC36-40FA-AAB0-6F4946C6ECEE@luminis.eu> <56D94312.2080809@oracle.com> <1758537220.4087042.1457168453242.JavaMail.zimbra@u-pem.fr> <56DAA52D.8070704@oracle.com> <1817412191.4299173.1457207422291.JavaMail.zimbra@u-pem.fr> <56DBFD23.8070703@oracle.com> Message-ID: Right, i've forgotten the case of split packages. R?mi Le 6 mars 2016 10:49:23 CET, Alan Bateman a ?crit : > >On 05/03/2016 19:50, forax at univ-mlv.fr wrote: >> : >> if there are jars (with no module metadata) in the modulepath and in >the classpath, >> what about having everything in the modulepath (module and jars), >nothing in the classpath and use the unamed modules only in scenarios >where currently we use default package. >> >It may not be possible to move all JAR files from the class path to the > >module path. Split packages will the biggest issue. The main advantage >of automatic modules is that you can make progress on migration to >modules while leaving significant chaos on the class path. > >-Alan. From rfscholte at apache.org Sun Mar 6 14:01:35 2016 From: rfscholte at apache.org (Robert Scholte) Date: Sun, 06 Mar 2016 15:01:35 +0100 Subject: modulepath and classpath mixture In-Reply-To: <56D1C726.8020508@oracle.com> References: <56CBAD62.3010508@oracle.com> <56D1C726.8020508@oracle.com> Message-ID: Hi, I've asked for some feedback and there seems to be concerns with split packages when there are two or more modules on the module path that export the same package. Unless I misunderstand the issue, I'd say you have the same problem with -addmods. If you add mod1 and mod2, which both export the same package, you have exactly the same issue, right? When talking about exports it made me realize there's probably another issue: only the exported packages of the "main"-module are accessible, right? Since src/test/java has no module-info, the -Xpatch is useless. An idea that comes to my mind is something like -mainModule , where are either a jar or directory containing module-info. All its classes can be accessed by the classes on the classpath, all other modules keep their package access restrictions. thanks, Robert On Sat, 27 Feb 2016 16:56:22 +0100, Jonathan Gibbons wrote: > At the risk of opening bikesheds, if we go that way, I would suggest > just -ALL- or just a new option -addallmods. > > -- Jon > > > On 02/27/2016 03:25 AM, Robert Scholte wrote: >> Hi, >> >> I noticed[1] that -addmods already has a special option: ALL-SYSTEM >> What I'm looking for is something like ALL-MP or ALL-MODULEPATH, which >> simply exposes all modules on the modulepath to the classpath. The set >> of moduleEntries on the modulePath are already chosen with care and are >> in the end all required to be able to compile the test-classes without >> the need of knowing the name of the module being used to compile with. >> >> thanks, >> Robert >> >> [1] http://openjdk.java.net/jeps/261 >> >> >> On Tue, 23 Feb 2016 01:52:50 +0100, Jonathan Gibbons >> wrote: >> >>> >>> >>> On 02/22/2016 12:44 PM, Robert Scholte wrote: >>>> Hi, >>>> >>>> first of all I'd like to say that I'm very pleased with the new -mp >>>> options, these matches better with the way Apache Maven would like to >>>> work with jars and class-folders. >>>> >>>> Here's my use case: I noticed that if I add a module-info to >>>> src/main/java and put all compile-scoped dependencies to the module >>>> path, all compiles fines. >>>> I assume that developers are less interested in adding a >>>> module-info.java file to src/test/java, so that's what I'm doing >>>> right now too. >>>> Now it seems that I *must* add compile + test scoped to the >>>> *classpath* to be able to compile the test classes. >>>> My first approach was to leave the compile-scoped dependencies on the >>>> modulepath and all test-scoped dependencies on the classpath, so the >>>> modules keeps their inner related structure, but it seems that the >>>> classpath classes cannot access the modulepath classes. >>>> >>>> I'm looking for the confirmation that putting all dependencies on the >>>> classpath is indeed the right approach in this case. >>>> >>>> thanks, >>>> Robert >>> >>> Robert, >>> >>> We definitely need some more detailed notes on setting up javac >>> compilations (note to self!) but one thing to note is that by default, >>> the unnamed module (i.e. code on the classpath) only has observability >>> of the modules in the system image. To make modules on the module path >>> observable, you need to use the -addmods option. >>> >>> -- Jon >> >> > -- Using Opera's mail client: http://www.opera.com/mail/ From mandy.chung at oracle.com Mon Mar 7 05:31:01 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Mon, 07 Mar 2016 05:31:01 +0000 Subject: hg: jigsaw/jake/jdk: Minor cleanup to ResourceBundle::getBundle security permission Message-ID: <201603070531.u275V1Qr010471@aojmv0008.oracle.com> Changeset: 9f33d93c2a13 Author: mchung Date: 2016-03-06 21:30 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9f33d93c2a13 Minor cleanup to ResourceBundle::getBundle security permission ! src/java.base/share/classes/java/util/ResourceBundle.java ! src/java.logging/share/classes/java/util/logging/Logger.java From dmitry.samersoff at oracle.com Mon Mar 7 09:38:08 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 7 Mar 2016 12:38:08 +0300 Subject: Need help testing the EA builds In-Reply-To: References: <56D7002A.9000509@oracle.com> Message-ID: <56DD4C00.7010908@oracle.com> Volker, Currently tmtools (jstack, jmap, jinfo, ... ) has two modes of operations - one is cooperative (attach API based) other one is non-cooperative (SA based). Long term plan is completely separate these two modes, with jhsdb as the only entry point to SA. This work is partially done - SA based mode is accessible via jhsdb. But removal of SA based functions from existing tools has huge compatibility impact (e.g. no more mixed stacktrace from jstack etc) and can't be done at one shot. Nothing besides tmtools depends to SA i.e. jcmd it self doesn't depend to SA. -Dmitry On 2016-03-04 22:08, Volker Simonis wrote: > Hi Alan, Dmitry, > > I've tried today to build the jake repository on AIX. Unfortunately > that doesn't work because we now have a hard dependency on SA which is > required by jcmd: > > $cat jdk/src/jdk.jcmd/share/classes/module-info.java > module jdk.jcmd { > requires jdk.attach; > requires jdk.jvmstat; > requires jdk.hotspot.agent; // until JDK-8059035 is complete > } > > This will break every platform which does not implement the SA. > > There already exists a bug for this issue: > 8059035: Break the (implicit) dependency from jdk.jcmd to jdk.hotspot.agent > https://bugs.openjdk.java.net/browse/JDK-8059035 > > Is there any chance that this will be resolved soon? > Or is there an easy way to disable this dependency on AIX? > > Regards, > Volker > > > On Wed, Mar 2, 2016 at 4:00 PM, Alan Bateman wrote: >> >> We are starting to think through how to bring the module system that is the >> monster patch in jigsaw/jake forest into the JDK 9 main line. >> >> There are many reasons to do this. One reason is to reduce testing effort. >> Another is to reduce the cost of sync ups as it takes a lot of effort each >> week to merge in the changes from JDK 9. We also have confused some >> developers by having two early access (EA) builds, one EA build with Project >> Jigsaw, the other without. It should also be obvious that time is moving on >> and we don't want to be rushing things right before JDK 9 Feature Complete. >> >> Merging into the JDK 9 main line will be a big step and there are many >> things that need to be done to make this happen. The proposal will most >> likely be to take snapshot of what we have in jake and bring it into JDK 9 >> after stabilization, testing and of course review. Once it is in JDK 9 then >> we'll continue to iterate and work through the many issues that need >> attention. >> >> One thing that would be useful is to get as many people as possible to try >> out the EA builds [1]. It really helps confidence when there is confirmation >> that existing libraries and applications work as before. If there are bugs >> or issues that involve any of the supported interfaces then we want to know. >> We know well that there are several compatibility issues and we've attempted >> to capture those in the Risks and Assumption section of JEP 261 [2]. >> >> We also interested in bug reports and issues from those trying out the EA >> builds to create their own modules or migrating existing code or libraries >> to modules. Bonus points for those brave enough to try out some of the many >> new APIs too. >> >> -Alan >> >> [1] https://jdk9.java.net/jigsaw/ >> [2] http://openjdk.java.net/jeps/261 -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From erik.joelsson at oracle.com Mon Mar 7 10:25:34 2016 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Mon, 07 Mar 2016 10:25:34 +0000 Subject: hg: jigsaw/jake: Build cleanup Message-ID: <201603071025.u27APYDi013121@aojmv0008.oracle.com> Changeset: deba19bdeddf Author: erikj Date: 2016-03-07 11:25 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/deba19bdeddf Build cleanup ! common/autoconf/boot-jdk.m4 ! common/autoconf/generated-configure.sh ! make/CompileJavaModules.gmk ! make/Main.gmk ! make/common/JavaCompilation.gmk ! make/common/MakeBase.gmk From erik.joelsson at oracle.com Mon Mar 7 10:26:32 2016 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Mon, 07 Mar 2016 10:26:32 +0000 Subject: hg: jigsaw/jake/jdk: Build cleanup Message-ID: <201603071026.u27AQWaW013608@aojmv0008.oracle.com> Changeset: a0071ded705e Author: erikj Date: 2016-03-07 11:25 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a0071ded705e Build cleanup ! make/launcher/LauncherCommon.gmk From Alan.Bateman at oracle.com Mon Mar 7 11:17:56 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 7 Mar 2016 11:17:56 +0000 Subject: Need help testing the EA builds In-Reply-To: <56DD4C00.7010908@oracle.com> References: <56D7002A.9000509@oracle.com> <56DD4C00.7010908@oracle.com> Message-ID: <56DD6364.4060101@oracle.com> On 07/03/2016 09:38, Dmitry Samersoff wrote: > Volker, > > Currently tmtools (jstack, jmap, jinfo, ... ) has two modes of > operations - one is cooperative (attach API based) other one is > non-cooperative (SA based). > > Long term plan is completely separate these two modes, with jhsdb as the > only entry point to SA. > > This work is partially done - SA based mode is accessible via jhsdb. > > But removal of SA based functions from existing tools has huge > compatibility impact (e.g. no more mixed stacktrace from jstack etc) and > can't be done at one shot. > > Nothing besides tmtools depends to SA i.e. jcmd it self doesn't depend > to SA. > We can address the AIX build issue by moving the `requires` to a module-info.java.extra file so that the module declaration is augmented in the build on platforms that have SA. This build tool is mostly for adding qualified exports and providers so we'll need to double check that it works with `requires`. If there is an issue then a workaround is to remove the requires and change the launcher builds to generate the launchers with -addmods ALL-SYSTEM. That said, I think we need to push ahead on the separation. The legacy tools have always been documented as experimental and unsupported and it shouldn't be a huge transition for someone using `jstack -m ` to use the jhsdb equivalent. I don't know what tmtools is, where is the code for this? -Alan. From Alan.Bateman at oracle.com Mon Mar 7 12:13:38 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 7 Mar 2016 12:13:38 +0000 Subject: modulepath and classpath mixture In-Reply-To: References: <56CBAD62.3010508@oracle.com> <56D1C726.8020508@oracle.com> Message-ID: <56DD7072.7060009@oracle.com> On 06/03/2016 14:01, Robert Scholte wrote: > Hi, > > I've asked for some feedback and there seems to be concerns with split > packages when there are two or more modules on the module path that > export the same package. > Unless I misunderstand the issue, I'd say you have the same problem > with -addmods. If you add mod1 and mod2, which both export the same > package, you have exactly the same issue, right? Yes, although at least if you specify the module names to -addmods then you are being explicit as to the additional modules to resolve. The issue with -addmods ALL-NAMED (or what the token is) is that it will resolve all modules that can be found via the application module path and so would need to be used with great care. > > When talking about exports it made me realize there's probably another > issue: only the exported packages of the "main"-module are accessible, > right? Since src/test/java has no module-info, the -Xpatch is useless. > An idea that comes to my mind is something like -mainModule , > where are either a jar or directory containing module-info. All its > classes can be accessed by the classes on the classpath, all other > modules keep their package access restrictions. I don't think I understand the issue here. Using -Xpatch doesn't change the module declaration or export. It can be used to override or augment the module content, it just can't override the module declaration. It can be used in conjunction with -XaddReads and -XaddExports to read additional modules or export additional packages. For example, if a patch adds types to a new package then you could export that package with -XaddExports. If the patch injects tests into an existing package then those tests might have new dependences and requires compiling or running with -XaddReads:$MODULE=junit for example. -Alan From sander.mak at luminis.eu Mon Mar 7 13:53:28 2016 From: sander.mak at luminis.eu (Sander Mak) Date: Mon, 7 Mar 2016 13:53:28 +0000 Subject: modulepath and classpath mixture In-Reply-To: <56DD7072.7060009@oracle.com> References: <56CBAD62.3010508@oracle.com> <56D1C726.8020508@oracle.com> <56DD7072.7060009@oracle.com> Message-ID: <24463131-7A64-4E23-AECE-F3DC729CA886@luminis.eu> > I don't think I understand the issue here. Using -Xpatch doesn't change the module declaration or export. It can be used to override or augment the module content, it just can't override the module declaration. It can be used in conjunction with -XaddReads and -XaddExports to read additional modules or export additional packages. For example, if a patch adds types to a new package then you could export that package with -XaddExports. If the patch injects tests into an existing package then those tests might have new dependences and requires compiling or running with -XaddReads:$MODULE=junit for example. I was playing around with exactly this yesterday, and this is what I ended up with: javac -Xmodule:javamodularity.easytext.algorithm.naivesyllablecounter \ -XaddReads:javamodularity.easytext.algorithm.naivesyllablecounter=org.junit \ -mp mods:lib-test \ -d mods-test/javamodularity.easytext.algorithm.naivesyllablecounter $(find src-test -name '*.java') java -Xpatch:mods-test \ -XaddReads:javamodularity.easytext.algorithm.naivesyllablecounter=org.junit \ -XaddExports:javamodularity.easytext.algorithm.naivesyllablecounter/javamodularity.easytext.algorithm.naivesyllablecounter=org.junit \ -mp mods:lib-test \ -addmods javamodularity.easytext.algorithm.naivesyllablecounter,hamcrestcore \ -m org.junit/org.junit.runner.JUnitCore javamodularity.easytext.algorithm.naivesyllablecounter.NaiveSyllableCounterTest Which patches my application module to contain a unit test, and then exposes my application module to junit at runtime (which is used as automatic module here). This works as expected. -- Sander From volker.simonis at gmail.com Mon Mar 7 13:53:36 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 7 Mar 2016 14:53:36 +0100 Subject: Need help testing the EA builds In-Reply-To: <56DD6364.4060101@oracle.com> References: <56D7002A.9000509@oracle.com> <56DD4C00.7010908@oracle.com> <56DD6364.4060101@oracle.com> Message-ID: Hi Alan, Dmitry, thanks a lot for your help. Alan's suggestion to move the dependency from src/jdk.jcmd/share/classes/module-info.java to src/jdk.jcmd/$OS/classes/module-info.java.extra works fine. After doing that change I could successfully build on AIX. I'll open a bug for this and post a webrev later today. As I'm not a jigsaw committer I'll probably need a sponsor though :) Regards, Volker On Mon, Mar 7, 2016 at 12:17 PM, Alan Bateman wrote: > On 07/03/2016 09:38, Dmitry Samersoff wrote: >> >> Volker, >> >> Currently tmtools (jstack, jmap, jinfo, ... ) has two modes of >> operations - one is cooperative (attach API based) other one is >> non-cooperative (SA based). >> >> Long term plan is completely separate these two modes, with jhsdb as the >> only entry point to SA. >> >> This work is partially done - SA based mode is accessible via jhsdb. >> >> But removal of SA based functions from existing tools has huge >> compatibility impact (e.g. no more mixed stacktrace from jstack etc) and >> can't be done at one shot. >> >> Nothing besides tmtools depends to SA i.e. jcmd it self doesn't depend >> to SA. >> > We can address the AIX build issue by moving the `requires` to a > module-info.java.extra file so that the module declaration is augmented in > the build on platforms that have SA. This build tool is mostly for adding > qualified exports and providers so we'll need to double check that it works > with `requires`. If there is an issue then a workaround is to remove the > requires and change the launcher builds to generate the launchers with > -addmods ALL-SYSTEM. > > That said, I think we need to push ahead on the separation. The legacy tools > have always been documented as experimental and unsupported and it shouldn't > be a huge transition for someone using `jstack -m ` to use the jhsdb > equivalent. I don't know what tmtools is, where is the code for this? > > -Alan. From Alan.Bateman at oracle.com Mon Mar 7 14:00:47 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 7 Mar 2016 14:00:47 +0000 Subject: Need help testing the EA builds In-Reply-To: References: <56D7002A.9000509@oracle.com> <56DD4C00.7010908@oracle.com> <56DD6364.4060101@oracle.com> Message-ID: <56DD898F.4050505@oracle.com> On 07/03/2016 13:53, Volker Simonis wrote: > Hi Alan, Dmitry, > > thanks a lot for your help. Alan's suggestion to move the dependency > from src/jdk.jcmd/share/classes/module-info.java to > src/jdk.jcmd/$OS/classes/module-info.java.extra works fine. After > doing that change I could successfully build on AIX. I'll open a bug > for this and post a webrev later today. As I'm not a jigsaw committer > I'll probably need a sponsor though :) > I reminded myself today that the build tool to augment module declarations from .extra files doesn't work for `requires`. So while it might help then I assume the generated module-info.java is incomplete for platforms that do support SA. These tools are begging to be refactored but from Dmitry's mail then it sounds like the split will take time. We might have to refactor them to use services or as a very short term workaround then we can build their launchers with `-addmods ALL-SYSTEM`. -Alan. From Alan.Bateman at oracle.com Mon Mar 7 14:20:46 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 7 Mar 2016 14:20:46 +0000 Subject: modulepath and classpath mixture In-Reply-To: <24463131-7A64-4E23-AECE-F3DC729CA886@luminis.eu> References: <56CBAD62.3010508@oracle.com> <56D1C726.8020508@oracle.com> <56DD7072.7060009@oracle.com> <24463131-7A64-4E23-AECE-F3DC729CA886@luminis.eu> Message-ID: <56DD8E3E.8010602@oracle.com> On 07/03/2016 13:53, Sander Mak wrote: > : > I was playing around with exactly this yesterday, and this is what I ended up with: > > javac -Xmodule:javamodularity.easytext.algorithm.naivesyllablecounter \ > -XaddReads:javamodularity.easytext.algorithm.naivesyllablecounter=org.junit \ > -mp mods:lib-test \ > -d mods-test/javamodularity.easytext.algorithm.naivesyllablecounter $(find src-test -name '*.java') > > java -Xpatch:mods-test \ > -XaddReads:javamodularity.easytext.algorithm.naivesyllablecounter=org.junit \ > -XaddExports:javamodularity.easytext.algorithm.naivesyllablecounter/javamodularity.easytext.algorithm.naivesyllablecounter=org.junit \ > -mp mods:lib-test \ > -addmods javamodularity.easytext.algorithm.naivesyllablecounter,hamcrestcore \ > -m org.junit/org.junit.runner.JUnitCore javamodularity.easytext.algorithm.naivesyllablecounter.NaiveSyllableCounterTest > > Which patches my application module to contain a unit test, and then exposes my application module to junit at runtime (which is used as automatic module here). This works as expected. > Good to see you got this working. Injecting tests into existing modules and augmenting the module declaration so that the module reads the test framework will be a bit advanced for many developers. I hope in time that the IDEs and other tools will make this easy. -Alan From sundararajan.athijegannathan at oracle.com Mon Mar 7 14:34:43 2016 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Mon, 07 Mar 2016 14:34:43 +0000 Subject: hg: jigsaw/jake/nashorn: nasgen class writer getCommonSuperClass should use isScriptClass check to return ScriptObject as type. Message-ID: <201603071434.u27EYiEd003916@aojmv0008.oracle.com> Changeset: 4ec6dc731b3a Author: sundar Date: 2016-03-07 20:00 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/4ec6dc731b3a nasgen class writer getCommonSuperClass should use isScriptClass check to return ScriptObject as type. ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ClassGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/MemberInfo.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/StringConstants.java From alan.bateman at oracle.com Mon Mar 7 15:14:03 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 07 Mar 2016 15:14:03 +0000 Subject: hg: jigsaw/jake/hotspot: Update spec for JVM TI VMStart event Message-ID: <201603071514.u27FE48t018109@aojmv0008.oracle.com> Changeset: 9a29ce81be87 Author: alanb Date: 2016-03-07 15:10 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9a29ce81be87 Update spec for JVM TI VMStart event ! src/share/vm/prims/jvmti.xml From kevin.rushforth at oracle.com Mon Mar 7 15:52:34 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 07 Mar 2016 07:52:34 -0800 Subject: [9-dev] RfR: JDK-8132743: Move netscape.javascript package from jdk.plugin to new module In-Reply-To: <56DC057D.3060608@oracle.com> References: <0DB5EFFD-B4B4-45BA-B866-1AC0DCFDBF90@oracle.com> <61E2A789-BFFC-401F-AA15-425A3702F5B7@oracle.com> <56D8CF6F.3030502@oracle.com> <2CC76624-65B0-4CF6-9EF3-98B489DD991C@oracle.com> <034652C8-6B32-4E12-9AB9-02912CD80905@oracle.com> <411EAC9F-CA8C-4A4C-84D1-D87375567EDE@oracle.com> <56D9AD5C.5010002@oracle.com> <56DC057D.3060608@oracle.com> Message-ID: <56DDA3C2.8000806@oracle.com> Dave, Just to tie up the loose end about the default JSObject constructor: No it cannot be package private. JavaFX WebView extends this class. -- Kevin Alan Bateman wrote: > > > On 05/03/2016 18:54, David DeHaven wrote: >> I've updated the webrev, hopefully one last time with feedback from >> Joe Darcy. >> http://cr.openjdk.java.net/~ddehaven/8132743/webrev.2/ >> >> - Relocated package Javadoc to above the package declaration in >> package-info.java >> - Reworded the Javadoc on the default JSObject ctor >> >> A point was brought up that the default ctor could probably be >> package-private, but there's no time to investigate what the impact >> would be so I will file a follow-up issue to investigate doing that >> at a later date. >> > This looks okay. Also I assume ServiceLoader.loadInstalled is what you > want as you only want to find implementations in the run-time image. > > -Alan From sundararajan.athijegannathan at oracle.com Mon Mar 7 16:28:34 2016 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Mon, 07 Mar 2016 16:28:34 +0000 Subject: hg: jigsaw/jake/nashorn: Uncommented invokeNoPermissions method of JavaAdapterServices. Message-ID: <201603071628.u27GSYf1015720@aojmv0008.oracle.com> Changeset: d8989b28c7fe Author: sundar Date: 2016-03-07 21:58 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/d8989b28c7fe Uncommented invokeNoPermissions method of JavaAdapterServices. ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaAdapterServices.java From stephen.felts at oracle.com Mon Mar 7 16:41:18 2016 From: stephen.felts at oracle.com (Stephen Felts) Date: Mon, 7 Mar 2016 08:41:18 -0800 (PST) Subject: Ant break In-Reply-To: <24463131-7A64-4E23-AECE-F3DC729CA886@luminis.eu> References: <56CBAD62.3010508@oracle.com> <56D1C726.8020508@oracle.com> <56DD7072.7060009@oracle.com> <24463131-7A64-4E23-AECE-F3DC729CA886@luminis.eu> Message-ID: <5c42e771-9bcc-4db2-bdf3-44d35f3b7cce@default> I'm seeing a problem using ant that I suspect is related to the classloading. I think it came in build 107 or 108. The following Is failing with /mydir/build.xml:27: taskdef class "ignore"/> cannot be found using the classloader AntClassLoader[/mydir_build/ant-contrib-1.0b3.jar] This would seem like a pretty common use case. If I comment that out, then I get the following. The named class is in the specified jar file. /mydir/build.xml:578: typedef class name="p4versionstring" classname="weblogic.ant.taskdefs.perforce.P4VersionString"/> cannot be found using the classloader AntClassLoader[/mydir2/weblogic.ant.taskdefs.perforce_1.1.0.0.jar] at org.apache.tools.ant.taskdefs.Definer.addDefinition(Definer.java:607) at org.apache.tools.ant.taskdefs.Definer.loadProperties(Definer.java:408) at org.apache.tools.ant.taskdefs.Definer.execute(Definer.java:264) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292) at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9-ea/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(java.base at 9-ea/Method.java:531) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:435) at org.apache.tools.ant.Target.performTasks(Target.java:456) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1393) at org.apache.tools.ant.Project.executeTarget(Project.java:1364) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) at org.apache.tools.ant.Project.executeTargets(Project.java:1248) at org.apache.tools.ant.Main.runBuild(Main.java:851) at org.apache.tools.ant.Main.startAnt(Main.java:235) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109) Caused by: java.lang.ClassNotFoundException: name="p4versionstring" classname="weblogic.ant.taskdefs.perforce.P4VersionString"/> at java.lang.Class.forName0(java.base at 9-ea/Native Method) at java.lang.Class.forName(java.base at 9-ea/Class.java:378) at org.apache.tools.ant.taskdefs.Definer.addDefinition(Definer.java:579) ... 18 more From Alan.Bateman at oracle.com Mon Mar 7 16:59:58 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 7 Mar 2016 16:59:58 +0000 Subject: Ant break In-Reply-To: <5c42e771-9bcc-4db2-bdf3-44d35f3b7cce@default> References: <56CBAD62.3010508@oracle.com> <56D1C726.8020508@oracle.com> <56DD7072.7060009@oracle.com> <24463131-7A64-4E23-AECE-F3DC729CA886@luminis.eu> <5c42e771-9bcc-4db2-bdf3-44d35f3b7cce@default> Message-ID: <56DDB38E.2090708@oracle.com> On 07/03/2016 16:41, Stephen Felts wrote: > I'm seeing a problem using ant that I suspect is related to the classloading. I think it came in build 107 or 108. > > This may be issue caused by the Multi-Release JAR file support that went into jdk-9+108. Uwe Schindler brought this up on core-libs-dev over the week and is currently tracked as JDK-8151339 [1]. Assuming you are seeing the same issue then the proposal is to disable or revert the change MR JAR support until the issues with URLs can be resolved. This may happen today in order to make it into jdk-9+109. -Alan [1] https://bugs.openjdk.java.net/browse/JDK-8151339 From david.dehaven at oracle.com Mon Mar 7 17:10:27 2016 From: david.dehaven at oracle.com (David DeHaven) Date: Mon, 7 Mar 2016 09:10:27 -0800 Subject: [9-dev] RfR: JDK-8132743: Move netscape.javascript package from jdk.plugin to new module In-Reply-To: <56DC057D.3060608@oracle.com> References: <0DB5EFFD-B4B4-45BA-B866-1AC0DCFDBF90@oracle.com> <61E2A789-BFFC-401F-AA15-425A3702F5B7@oracle.com> <56D8CF6F.3030502@oracle.com> <2CC76624-65B0-4CF6-9EF3-98B489DD991C@oracle.com> <034652C8-6B32-4E12-9AB9-02912CD80905@oracle.com> <411EAC9F-CA8C-4A4C-84D1-D87375567EDE@oracle.com> <56D9AD5C.5010002@oracle.com> <56DC057D.3060608@oracle.com> Message-ID: >> I've updated the webrev, hopefully one last time with feedback from Joe Darcy. >> http://cr.openjdk.java.net/~ddehaven/8132743/webrev.2/ >> >> - Relocated package Javadoc to above the package declaration in package-info.java >> - Reworded the Javadoc on the default JSObject ctor >> >> A point was brought up that the default ctor could probably be package-private, but there's no time to investigate what the impact would be so I will file a follow-up issue to investigate doing that at a later date. >> > This looks okay. Also I assume ServiceLoader.loadInstalled is what you want as you only want to find implementations in the run-time image. Correct. -DrD- From sundararajan.athijegannathan at oracle.com Mon Mar 7 17:11:44 2016 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Mon, 07 Mar 2016 17:11:44 +0000 Subject: hg: jigsaw/jake/nashorn: adding missing @modules declaration for 3 jtreg tests. Message-ID: <201603071711.u27HBiTc003966@aojmv0008.oracle.com> Changeset: da3c0f81ef3d Author: sundar Date: 2016-03-07 22:41 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/da3c0f81ef3d adding missing @modules declaration for 3 jtreg tests. ! test/src/jdk/nashorn/internal/runtime/doubleconv/test/BignumTest.java ! test/src/jdk/nashorn/internal/runtime/doubleconv/test/DiyFpTest.java ! test/src/jdk/nashorn/internal/runtime/test/JDK_8078414_Test.java From lois.foltan at oracle.com Mon Mar 7 17:25:08 2016 From: lois.foltan at oracle.com (lois.foltan at oracle.com) Date: Mon, 07 Mar 2016 17:25:08 +0000 Subject: hg: jigsaw/jake/jdk: JDK-8144730, make jdk.boot.class.path.append and internal system property. Message-ID: <201603071725.u27HP8ix008501@aojmv0008.oracle.com> Changeset: 22820da90ee1 Author: lfoltan Date: 2016-03-07 11:58 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/22820da90ee1 JDK-8144730, make jdk.boot.class.path.append and internal system property. ! src/java.base/share/classes/jdk/internal/loader/ClassLoaders.java ! src/java.base/share/classes/jdk/internal/misc/VM.java From lois.foltan at oracle.com Mon Mar 7 17:27:03 2016 From: lois.foltan at oracle.com (lois.foltan at oracle.com) Date: Mon, 07 Mar 2016 17:27:03 +0000 Subject: hg: jigsaw/jake/hotspot: JDK-8144730, make jdk.boot.class.path.append an internal system property and remove sun.boot.class.path support. Message-ID: <201603071727.u27HR3Fr009394@aojmv0008.oracle.com> Changeset: 7fc12c5280a2 Author: lfoltan Date: 2016-03-07 11:59 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7fc12c5280a2 JDK-8144730, make jdk.boot.class.path.append an internal system property and remove sun.boot.class.path support. ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/sharedPathsMiscInfo.cpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! test/runtime/BootClassAppendProp/BootClassPathAppendProp.java From volker.simonis at gmail.com Mon Mar 7 18:23:40 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 7 Mar 2016 19:23:40 +0100 Subject: Need help testing the EA builds In-Reply-To: <56DD898F.4050505@oracle.com> References: <56D7002A.9000509@oracle.com> <56DD4C00.7010908@oracle.com> <56DD6364.4060101@oracle.com> <56DD898F.4050505@oracle.com> Message-ID: Hi Alan, I think you're right. Although I'm not familiar with the module system at all, I can see the following: - default build with jdk.hotspot.agent dependency in module-info.java ./images/jdk/bin/jdeps -m jdk.jcmd module jdk.jcmd requires java.base requires jdk.attach requires jdk.hotspot.agent requires jdk.jvmstat - moving the jdk.hotspot.agent dependency to src/jdk.jcmd/$OS/classes/module-info.java.extra ./images/jdk/bin/jdeps -m jdk.jcmd module jdk.jcmd requires java.base requires jdk.attach requires jdk.jvmstat Tools like 'jstack' are still working, but in the default case I get: ./images/jdk/bin/jstack Usage: jstack [-l] (to connect to running process) jstack -F [-m] [-l] (to connect to a hung process) jstack [-m] [-l] (to connect to a core file) jstack [-m] [-l] [server_id@] (to connect to a remote debug server) while in the case where I've moved the dependency to module-info.java.extra I only see: ./images/jdk/bin/jstack Usage: jstack [-l] (to connect to running process) i.e. the options which require the SA are not available. So while the tools are not being refactored, how can we fix the build on non-SA platforms if moving the SA dependency to module-info.java.extra is no viable solution? I've tried your suggestion to add `-addmods ALL-SYSTEM` to the jcmd launchers. It seems to work. I still don't see the jdk.hotspot.agent dependency displayed by jdeps (is this expected ?), but the resulting tools (i.e. jstack) now display all the options, also the ones whoch require the SA. Can you please have a quick look at my changes: http://cr.openjdk.java.net/~simonis/webrevs/2016/8151378_jdk/ http://cr.openjdk.java.net/~simonis/webrevs/2016/8151378_toplevel/ If you think they are OK, I'll resend a formal RFR to the mailing list. Please notice that unfortunately we also need a top-level change because for some reason we didn't define REQUIRED_OS_NAME and REQUIRED_OS_VERSION until now and this didn't do any harm. But for the jigsaw build it is needed. I'm also not sure about the new src/jdk.jcmd/$OS/classes/module-info.java.extra files. Should I leave them in the change or should they be only introduced with the change which actually makes them really work? Thank you and best regards, Volker On Mon, Mar 7, 2016 at 3:00 PM, Alan Bateman wrote: > On 07/03/2016 13:53, Volker Simonis wrote: >> >> Hi Alan, Dmitry, >> >> thanks a lot for your help. Alan's suggestion to move the dependency >> from src/jdk.jcmd/share/classes/module-info.java to >> src/jdk.jcmd/$OS/classes/module-info.java.extra works fine. After >> doing that change I could successfully build on AIX. I'll open a bug >> for this and post a webrev later today. As I'm not a jigsaw committer >> I'll probably need a sponsor though :) >> > I reminded myself today that the build tool to augment module declarations > from .extra files doesn't work for `requires`. So while it might help then I > assume the generated module-info.java is incomplete for platforms that do > support SA. These tools are begging to be refactored but from Dmitry's mail > then it sounds like the split will take time. We might have to refactor them > to use services or as a very short term workaround then we can build their > launchers with `-addmods ALL-SYSTEM`. > > -Alan. From Alan.Bateman at oracle.com Mon Mar 7 19:58:01 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 7 Mar 2016 19:58:01 +0000 Subject: Need help testing the EA builds In-Reply-To: References: <56D7002A.9000509@oracle.com> <56DD4C00.7010908@oracle.com> <56DD6364.4060101@oracle.com> <56DD898F.4050505@oracle.com> Message-ID: <56DDDD49.5020309@oracle.com> On 07/03/2016 18:23, Volker Simonis wrote: > : > > So while the tools are not being refactored, how can we fix the build > on non-SA platforms if moving the SA dependency to > module-info.java.extra is no viable solution? I've tried your > suggestion to add `-addmods ALL-SYSTEM` to the jcmd launchers. It > seems to work. I still don't see the jdk.hotspot.agent dependency > displayed by jdeps (is this expected ?), but the resulting tools (i.e. > jstack) now display all the options, also the ones whoch require the > SA. These tools access SA using core reflection so the jdeps doesn't see the dependency. Dropping the `requires jdk.htospot.agent and using `-addmods ALL-SYSTEM` as workaround will resolve it but I'd prefer to avoid this if we can. Erik suggested a build solution to this and may have a patch soon. -Alan. From mandy.chung at oracle.com Mon Mar 7 21:22:03 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Mon, 07 Mar 2016 21:22:03 +0000 Subject: hg: jigsaw/jake/jdk: Clarify spec for Class::forName Message-ID: <201603072122.u27LM34W014022@aojmv0008.oracle.com> Changeset: 0403537f7032 Author: mchung Date: 2016-03-07 13:22 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0403537f7032 Clarify spec for Class::forName ! src/java.base/share/classes/java/lang/Class.java From alan.bateman at oracle.com Mon Mar 7 21:25:59 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 07 Mar 2016 21:25:59 +0000 Subject: hg: jigsaw/jake/jdk: 4 new changesets Message-ID: <201603072125.u27LPxXM015573@aojmv0008.oracle.com> Changeset: 077b8ac4a27a Author: alanb Date: 2016-03-07 12:29 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/077b8ac4a27a Clean-up to ModuleReader javadoc ! src/java.base/share/classes/java/lang/module/ModuleReader.java Changeset: 0ac544460a1a Author: sdrach Date: 2016-03-07 19:37 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0ac544460a1a 8151339: Adding fragment to JAR URLs breaks ant Reviewed-by: alanb ! src/java.base/share/classes/sun/misc/URLClassPath.java Changeset: 593ee61fd5ae Author: alanb Date: 2016-03-07 21:25 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/593ee61fd5ae Fix typo in ModuleReader javadoc ! src/java.base/share/classes/java/lang/module/ModuleReader.java Changeset: 1e7247ea70e1 Author: alanb Date: 2016-03-07 21:25 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1e7247ea70e1 Merge From mandy.chung at oracle.com Mon Mar 7 21:56:35 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Mon, 07 Mar 2016 21:56:35 +0000 Subject: hg: jigsaw/jake/hotspot: Fix merge issue for JDK-8144996 and JDK-8067194 Message-ID: <201603072156.u27LuZ3I028681@aojmv0008.oracle.com> Changeset: c7d5a9549f3b Author: mchung Date: 2016-03-07 13:56 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c7d5a9549f3b Fix merge issue for JDK-8144996 and JDK-8067194 - src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/HeapRegionSetCount.java From mandy.chung at oracle.com Mon Mar 7 22:44:55 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Mon, 07 Mar 2016 22:44:55 +0000 Subject: hg: jigsaw/jake/hotspot: Fix typo Message-ID: <201603072244.u27Mitlp018654@aojmv0008.oracle.com> Changeset: ada509821490 Author: mchung Date: 2016-03-07 14:44 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ada509821490 Fix typo ! src/share/vm/prims/jvmti.xml From mandy.chung at oracle.com Mon Mar 7 23:16:32 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Mon, 07 Mar 2016 23:16:32 +0000 Subject: hg: jigsaw/jake/jdk: Minor test cleanup Message-ID: <201603072316.u27NGWGG029737@aojmv0008.oracle.com> Changeset: 19a309a4477e Author: mchung Date: 2016-03-07 15:16 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/19a309a4477e Minor test cleanup ! test/jdk/jigsaw/etc/JdkModules.java From mandy.chung at oracle.com Mon Mar 7 23:52:26 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 7 Mar 2016 15:52:26 -0800 Subject: [9-jake] Review request: 8151320: Remove unnecessary addReads from JavaFX In-Reply-To: <56DB6C36.9050904@oracle.com> References: <56DB6C36.9050904@oracle.com> Message-ID: > On Mar 5, 2016, at 3:31 PM, Kevin Rushforth wrote: > > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8151320 > http://cr.openjdk.java.net/~kcr/8151320/webrev.00/ > > Now that addReads are no longer necessary in cases where we use core reflection [1] we will eliminate these unneeded calls in the FX jake repo. > The patch looks fine to me. There are some FIXME comments that I assume you will clean up separately. Mandy > -- Kevin > > [1] http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-March/000231.html > From kevin.rushforth at oracle.com Tue Mar 8 00:10:48 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 07 Mar 2016 16:10:48 -0800 Subject: [9-jake] Review request: 8151320: Remove unnecessary addReads from JavaFX In-Reply-To: References: <56DB6C36.9050904@oracle.com> Message-ID: <56DE1888.7010600@oracle.com> Yes, I'll deal with all of the "FIXME" comments (and not just the ones you see in the webrev) separately. Thanks. -- Kevin Mandy Chung wrote: >> On Mar 5, 2016, at 3:31 PM, Kevin Rushforth wrote: >> >> Please review the following: >> >> https://bugs.openjdk.java.net/browse/JDK-8151320 >> http://cr.openjdk.java.net/~kcr/8151320/webrev.00/ >> >> Now that addReads are no longer necessary in cases where we use core reflection [1] we will eliminate these unneeded calls in the FX jake repo. >> >> > > The patch looks fine to me. There are some FIXME comments that I assume you will clean up separately. > > Mandy > > >> -- Kevin >> >> [1] http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-March/000231.html >> >> > > From mandy.chung at oracle.com Tue Mar 8 00:15:45 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 7 Mar 2016 16:15:45 -0800 Subject: Initial webrev with changes for JDK 9 In-Reply-To: <56D84C7D.9020006@oracle.com> References: <56D84C7D.9020006@oracle.com> Message-ID: > On Mar 3, 2016, at 6:38 AM, Alan Bateman wrote: > > I've pushed webrevs with the initial changes for JDK 9 here: > http://cr.openjdk.java.net/~alanb/8142968/0/ I have reviewed changes for java.management and java.logging module. src/java.management/share/classes/sun/management/ThreadInfoCompositeData.java 197 private static final String[] threadInfoV9Attributes = { 198 DAEMON, 199 PRIORITY, 200 MODULE_NAME, 201 MODULE_VERSION, Are line 200-201 left over from some earlier prototype? I think they should be removed. src/java.management/share/classes/sun/management/TypeVersionMapper.java Formatting nit: throws in several method signature better to be indented. I also reviewed the removal of the service config files in the following modules: jdk.attach jdk.jvmstat jdk.jvmstat.rmi Mandy From volker.simonis at gmail.com Tue Mar 8 07:45:25 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 8 Mar 2016 08:45:25 +0100 Subject: Need help testing the EA builds In-Reply-To: <56DDDD49.5020309@oracle.com> References: <56D7002A.9000509@oracle.com> <56DD4C00.7010908@oracle.com> <56DD6364.4060101@oracle.com> <56DD898F.4050505@oracle.com> <56DDDD49.5020309@oracle.com> Message-ID: On Mon, Mar 7, 2016 at 8:58 PM, Alan Bateman wrote: > > On 07/03/2016 18:23, Volker Simonis wrote: >> >> : >> >> So while the tools are not being refactored, how can we fix the build >> on non-SA platforms if moving the SA dependency to >> module-info.java.extra is no viable solution? I've tried your >> suggestion to add `-addmods ALL-SYSTEM` to the jcmd launchers. It >> seems to work. I still don't see the jdk.hotspot.agent dependency >> displayed by jdeps (is this expected ?), but the resulting tools (i.e. >> jstack) now display all the options, also the ones whoch require the >> SA. > > These tools access SA using core reflection so the jdeps doesn't see the > dependency. Dropping the `requires jdk.htospot.agent and using `-addmods > ALL-SYSTEM` as workaround will resolve it but I'd prefer to avoid this if we > can. > > Erik suggested a build solution to this and may have a patch soon. > OK, that would be fine. This problem isn't very urgent but it would be good if we could resolve it before the big jake integration into jdk9-dev. Regards, Volker > -Alan. From sundararajan.athijegannathan at oracle.com Tue Mar 8 13:13:14 2016 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Tue, 08 Mar 2016 13:13:14 +0000 Subject: hg: jigsaw/jake/nashorn: 2 new changesets Message-ID: <201603081313.u28DDEO6020307@aojmv0008.oracle.com> Changeset: 3218d2a00785 Author: hannesw Date: 2016-03-07 13:28 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/3218d2a00785 8148148: Remove pluggable CodeStore API Reviewed-by: attila, mhaupt ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/CodeStore.java Changeset: aa35193cc240 Author: sundar Date: 2016-03-08 18:42 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/aa35193cc240 8151388: Nashorn no longer uses CodeStore SPI ! src/jdk.scripting.nashorn/share/classes/module-info.java From Alan.Bateman at oracle.com Tue Mar 8 14:08:45 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 8 Mar 2016 14:08:45 +0000 Subject: Need help testing the EA builds In-Reply-To: References: <56D7002A.9000509@oracle.com> <56DD4C00.7010908@oracle.com> <56DD6364.4060101@oracle.com> <56DD898F.4050505@oracle.com> <56DDDD49.5020309@oracle.com> Message-ID: <56DEDCED.5040007@oracle.com> On 08/03/2016 07:45, Volker Simonis wrote: > : > OK, that would be fine. This problem isn't very urgent but it would be > good if we could resolve it before the big jake integration into > jdk9-dev. > > In order, then my preferences for resolving this are: 1. Compete the tool separation, meaning JDK-8059035. 2. Change these tools to use services so that the SA backend is a service provider. 3. Build-time solution. 4. Drop the dependency but compile the launchers for the tools on platforms that support SA with -addmods jdk.hotspot.agent or ALL-SYSTEM. I agree we need to address this soon. -Alan. From alan.bateman at oracle.com Tue Mar 8 14:16:25 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 08 Mar 2016 14:16:25 +0000 Subject: hg: jigsaw/jake/jdk: 3 new changesets Message-ID: <201603081416.u28EGQ8T010645@aojmv0008.oracle.com> Changeset: a9f1485296c7 Author: alanb Date: 2016-03-08 11:19 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a9f1485296c7 pack200 review comments ! src/java.base/share/classes/com/sun/java/util/jar/pack/intrinsic.properties ! test/tools/pack200/ModuleAttributes.java Changeset: 47488e198f22 Author: alanb Date: 2016-03-08 12:39 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/47488e198f22 Improve post-resolution checks to include uses/provides ! src/java.base/share/classes/java/lang/module/Configuration.java ! src/java.base/share/classes/java/lang/module/Resolver.java ! test/jdk/jigsaw/module/ConfigurationTest.java Changeset: a562e16994cc Author: alanb Date: 2016-03-08 13:58 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a562e16994cc Expand builder to Requires/Exports/Provides/Version ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java ! test/jdk/jigsaw/module/ModuleDescriptorTest.java From volker.simonis at gmail.com Tue Mar 8 14:56:02 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 8 Mar 2016 15:56:02 +0100 Subject: Need help testing the EA builds In-Reply-To: <56DEDCED.5040007@oracle.com> References: <56D7002A.9000509@oracle.com> <56DD4C00.7010908@oracle.com> <56DD6364.4060101@oracle.com> <56DD898F.4050505@oracle.com> <56DDDD49.5020309@oracle.com> <56DEDCED.5040007@oracle.com> Message-ID: On Tue, Mar 8, 2016 at 3:08 PM, Alan Bateman wrote: > > On 08/03/2016 07:45, Volker Simonis wrote: >> >> : >> OK, that would be fine. This problem isn't very urgent but it would be >> good if we could resolve it before the big jake integration into >> jdk9-dev. >> >> > In order, then my preferences for resolving this are: > > 1. Compete the tool separation, meaning JDK-8059035. > > 2. Change these tools to use services so that the SA backend is a service > provider. > > 3. Build-time solution. > > 4. Drop the dependency but compile the launchers for the tools on platforms > that support SA with -addmods jdk.hotspot.agent or ALL-SYSTEM. > What exactly do you mean by "3. Build-time solution"? Is it the implementation of your initial proposal of using src/jdk.jcmd/$OS/classes/module-info.java.extra? Currently for me it's no difference which solution we choose - I just don't want that we break the AIX build in jdk9. So I'll give others a chance to come up with a solution for 1 to 3 but if this will not happen until the jake integration into jdk9 I'll propose my implementation of 4 for review: https://bugs.openjdk.java.net/browse/JDK-8151378 http://cr.openjdk.java.net/~simonis/webrevs/2016/8151378_jdk/ http://cr.openjdk.java.net/~simonis/webrevs/2016/8151378_toplevel/ Thanks, Volker > I agree we need to address this soon. > > -Alan. From Alan.Bateman at oracle.com Tue Mar 8 15:48:23 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 8 Mar 2016 15:48:23 +0000 Subject: Initial webrev with changes for JDK 9 In-Reply-To: <56D84C7D.9020006@oracle.com> References: <56D84C7D.9020006@oracle.com> Message-ID: <56DEF447.4000309@oracle.com> I've refreshed the webrevs here: http://cr.openjdk.java.net/~alanb/8142968/1 so that we have a snapshot of what is currently in the jigsaw/jake forest. The webrves are against jdk-9+108. I plan to send mail to jdk9-dev soon proposing that we integrate a snapshot into JDK 9 before the end of March. -Alan. From jan.lahoda at oracle.com Tue Mar 8 16:44:22 2016 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Tue, 08 Mar 2016 16:44:22 +0000 Subject: hg: jigsaw/jake/langtools: Changing ModuleSymbol.visiblePackage from Set to Map, to avoid linear search in lookupPackage, as noted by mcimadamore. Message-ID: <201603081644.u28GiMs0027566@aojmv0008.oracle.com> Changeset: ceb8dfa70331 Author: jlahoda Date: 2016-03-08 17:41 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/ceb8dfa70331 Changing ModuleSymbol.visiblePackage from Set to Map, to avoid linear search in lookupPackage, as noted by mcimadamore. ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java From mark.reinhold at oracle.com Tue Mar 8 16:47:39 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 8 Mar 2016 08:47:39 -0800 (PST) Subject: The State of the Module System: Automatic Edition Message-ID: <20160308164739.072139DEA4@eggemoggin.niobe.net> I've posted an update to the State of the Module System document [1]. The main change in this edition is the introduction of material on compatibility and migration, including automatic modules [2]. This update also revises the description of reflective readability [3], reorders the text to improve the flow of the narrative, and is organized into a two-level hierarchy of sections and subsections for easier navigation. Comments and discussion are welcome here on jigsaw-dev but, as usual, the best way to ensure that the EG sees any specific comment is to send it to the EG's "suggestion box" list, jpms-spec-comments [4]. - Mark [1] http://openjdk.java.net/projects/jigsaw/spec/sotms/ [2] http://openjdk.java.net/projects/jigsaw/spec/sotms/#compatibility--migration [3] http://openjdk.java.net/projects/jigsaw/spec/sotms/#reflective-readability [4] http://mail.openjdk.java.net/mailman/listinfo/jpms-spec-comments From sundararajan.athijegannathan at oracle.com Tue Mar 8 16:47:45 2016 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Tue, 08 Mar 2016 16:47:45 +0000 Subject: hg: jigsaw/jake/nashorn: CodeStoreAndPathTest used to fail with NPE. Fixed and re-enabled the test. Message-ID: <201603081647.u28GljUb028898@aojmv0008.oracle.com> Changeset: 64f3ca334b12 Author: sundar Date: 2016-03-08 22:17 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/64f3ca334b12 CodeStoreAndPathTest used to fail with NPE. Fixed and re-enabled the test. ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/OptimisticTypesPersistence.java ! test/src/jdk/nashorn/internal/runtime/test/CodeStoreAndPathTest.java From mandy.chung at oracle.com Tue Mar 8 17:06:58 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 08 Mar 2016 17:06:58 +0000 Subject: hg: jigsaw/jake/jdk: 2 new changesets Message-ID: <201603081706.u28H6w8c004504@aojmv0008.oracle.com> Changeset: cb0ba4c602a8 Author: mchung Date: 2016-03-08 09:05 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/cb0ba4c602a8 Fix formatting nit ! src/java.management/share/classes/sun/management/TypeVersionMapper.java Changeset: 5b9dfdb08517 Author: mchung Date: 2016-03-08 09:06 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5b9dfdb08517 ResourceBundle::getBundle throws ServiceConfigurationError ! src/java.base/share/classes/java/util/ResourceBundle.java ! test/ProblemList.jake.txt From Alan.Bateman at oracle.com Tue Mar 8 17:26:39 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 8 Mar 2016 17:26:39 +0000 Subject: Initial webrev with changes for JDK 9 In-Reply-To: References: <56D84C7D.9020006@oracle.com> Message-ID: <56DF0B4F.9070409@oracle.com> On 08/03/2016 00:15, Mandy Chung wrote: > : > > src/java.management/share/classes/sun/management/ThreadInfoCompositeData.java > 197 private static final String[] threadInfoV9Attributes = { > 198 DAEMON, > 199 PRIORITY, > 200 MODULE_NAME, > 201 MODULE_VERSION, > > Are line 200-201 left over from some earlier prototype? I think they should be removed. > > I think you are right, these should not be needed. There is a compatibility test for this and I assume it will continue to pass if these are removed. -Alan From Roger.Riggs at Oracle.com Tue Mar 8 18:07:42 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 8 Mar 2016 13:07:42 -0500 Subject: Initial webrev with changes for JDK 9 - jimage In-Reply-To: <56D84C7D.9020006@oracle.com> References: <56D84C7D.9020006@oracle.com> Message-ID: <56DF14EE.1050102@Oracle.com> Hi, Review comments for the jimage code in java.base, mostly cleanup but perhaps a bug or two. General: inconsistent style and not following guidelines, copyright dates may need an update. Use of assert for error checking is not going to catch or help isolate errors in production builds. dir: jdk/src/java.base/share/classes/jdk/internal/jimage/ BasicImageReader: - readHeader() exception message should say not a jimage or wrong version Other IOExceptions can occur if the file is corrupted or is too small, array index out of bounds, etc. - findLocation() should use a more explicit computation for the redirection than rehashing; this would allow the hash seed to be encapsulated. - slice() synchronizes on the ByteBuffer; does every other access? - getAllLocations() is unused and does not respect its sorted argument; Best to remove the method for now. - getResourceBuffer(): unused - remove - getResourceStream(): unused - remove ImageStringsReader: - Is Modified UTF-8 really needed here; using normal UTF-8 would allow re-use and better performance. Alternatively, Modifed UTF-8 should be added as a supported encoding. - The ImageStringsReader.hashCode() should be defined so it can take advantage of 32 or 64 bit accesses; since it is used frequently. And it needs to be stable across revisions that may be accessing jimages from different JDK versions. - stringFromMUTF8(byte[]) - there may be some optimization to avoid expanding ascii to chars and then re-encoding in String. - charsFromByteBufferLength/charsFromByteBuffer should throw an exception if no terminating null, not just when assertions are enabled - inconsistent assert errors vs exceptions for malformed mutf8. Use of assert will not detect errors in production builds - mutf8FromChars allocates a new working buffer (byte[8]) potentially for every UNICODE char. - mutf8FromString: should take advantage of new String(bytes, offset, length, charsetName) to avoid extra allocations. (would need a Modified utf-8 charset). - hashCode(byte[0, seed) should be private; the hashcode algorithm should not be variable. ImageLocation: - Merge ImageLocation functions into ImageLocationBase and rename. ImageLocation does not have enough unique functionality to be a separate class. - It is a poor design to create an instance that may not be valid. It would be better to have an ImageLocation factory method that encapsulated the creation and checking ImageLocationBase: - Failing asserts will not cause a runtime error in production. But will degenerate into unpredictable other exceptions ImageStream: - compress(): Too heavyweight an object to be used and discarded just for compress / decompress of small values. ImageBufferCache: - Comments on each method would make the intent clear - getBuffer: mixing for loop and explicit indexes is fragile - releaseBuffer: check buffer.capacity before threadLocal.get() for early return - Logic of i,j is flawed, i is never changed; j is/becomes 0 The first buffer is removed if there are more than max Its not clear what algorithm was intended. A buffer that is in use can be removed. - ImageBufferCache constructor: the isUsed flag should be set in getBuffer() when it is added to the list (not in the constructor) It keeps it consistent with when it is set for a re-used buffer. ImageHeader: - BADMAGIC is not used - readFrom could throw BufferUnderflowException - undocumented ImageModuleData: - ImageModuleData seems to be unused; allModuleNames() is unreferenced ImageReader: - ImageReader(path): unused - remove - Use of assert is non-reassuring, ineffective in production builds - In a long running application the per thread buffers will get to the point wehere they are unused and should be released. There is no support for soft or weak references to handle that case. Alternatively, if the buffers were not per thread then they would have a lesser impact. Also, why should there be more than one buffer per thread? ImageReader.Resource: - unused create method - unused parent argument (0) in Resource constructor (dir, loc, attr) ImageReader.LinkNode: - constructor has unused parent arg decompress/CompressIndexes: - readInt: wasteful allocation of a single byte array and then another small byte array; and then another heap buffer allocation in the ByteBuffer. - decompress is hugely wasteful of allocations of ByteBuffers of small sizes. decompress/CompressedResourceHeader: - MAGIC does not need to be public decompress/Decompressor: - IOException "Plugin name not found" should include the missing name - StringsProvider is an unnecessary interface; could use Supplier - Redundant public modifiers in interface declarations decompress/SignatureParser: - Comments describing the input and output formats needed - style around operators does not consistently include spaces; and "if("... decompress/StringSharingDecompressor: - Wasteful use of ByteBuffers and small arrays without re-use (safeAdd...) - StringSharingDecompressor constructor with unused argument - remove decompress/ZipDecompressor: - Should be more specific about the zip algorithms supported since it needs to be stable across releases - decompress(): use try-with-resources for safer inflation src/java.base/share/native/libjimage/imageDecompressor.cpp - "// If ptr is not aligned, sparc will fail." implies input argument must be aligned - General doubt about using assert; for example to check on malloc allocation failure - In production environment will exhibit as segv From harold.seigel at oracle.com Tue Mar 8 18:19:53 2016 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Tue, 08 Mar 2016 18:19:53 +0000 Subject: hg: jigsaw/jake/hotspot: Remove unused _module_offset Message-ID: <201603081819.u28IJr4K002186@aojmv0008.oracle.com> Changeset: fc6d7220f074 Author: hseigel Date: 2016-03-08 12:52 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/fc6d7220f074 Remove unused _module_offset ! src/share/vm/runtime/vmStructs.cpp From rfscholte at apache.org Tue Mar 8 19:13:05 2016 From: rfscholte at apache.org (Robert Scholte) Date: Tue, 08 Mar 2016 20:13:05 +0100 Subject: modulepath and classpath mixture In-Reply-To: <56DD7072.7060009@oracle.com> References: <56CBAD62.3010508@oracle.com> <56D1C726.8020508@oracle.com> <56DD7072.7060009@oracle.com> Message-ID: On Mon, 07 Mar 2016 13:13:38 +0100, Alan Bateman wrote: > On 06/03/2016 14:01, Robert Scholte wrote: >> Hi, >> >> I've asked for some feedback and there seems to be concerns with split >> packages when there are two or more modules on the module path that >> export the same package. >> Unless I misunderstand the issue, I'd say you have the same problem >> with -addmods. If you add mod1 and mod2, which both export the same >> package, you have exactly the same issue, right? > Yes, although at least if you specify the module names to -addmods then > you are being explicit as to the additional modules to resolve. The > issue with -addmods ALL-NAMED (or what the token is) is that it will > resolve all modules that can be found via the application module path > and so would need to be used with great care. > I can only speak for Maven how it wants to use it. Only the modules used to compile the src/main/java sources will end up on the modulePath in this case. So the set of modules has already been validated, kind of. >> >> When talking about exports it made me realize there's probably another >> issue: only the exported packages of the "main"-module are accessible, >> right? Since src/test/java has no module-info, the -Xpatch is useless. >> An idea that comes to my mind is something like -mainModule , >> where are either a jar or directory containing module-info. All its >> classes can be accessed by the classes on the classpath, all other >> modules keep their package access restrictions. > I don't think I understand the issue here. Using -Xpatch doesn't change > the module declaration or export. It can be used to override or augment > the module content, it just can't override the module declaration. It > can be used in conjunction with -XaddReads and -XaddExports to read > additional modules or export additional packages. For example, if a > patch adds types to a new package then you could export that package > with -XaddExports. If the patch injects tests into an existing package > then those tests might have new dependences and requires compiling or > running with -XaddReads:$MODULE=junit for example. This is how I thought that -Xpatch would work in short: the module-info in src/main/java and src/test/java have both the same modulename. The module-info in src/test/java specifies the extra required modules (like junit). With -Xpatch the test-classes have access to the non-exported main-classes too. > > -Alan thanks, Robert From rfscholte at apache.org Tue Mar 8 19:36:04 2016 From: rfscholte at apache.org (Robert Scholte) Date: Tue, 08 Mar 2016 20:36:04 +0100 Subject: modulepath and classpath mixture In-Reply-To: <24463131-7A64-4E23-AECE-F3DC729CA886@luminis.eu> References: <56CBAD62.3010508@oracle.com> <56D1C726.8020508@oracle.com> <56DD7072.7060009@oracle.com> <24463131-7A64-4E23-AECE-F3DC729CA886@luminis.eu> Message-ID: On Mon, 07 Mar 2016 14:53:28 +0100, Sander Mak wrote: > >> I don't think I understand the issue here. Using -Xpatch doesn't change >> the module declaration or export. It can be used to override or augment >> the module content, it just can't override the module declaration. It >> can be used in conjunction with -XaddReads and -XaddExports to read >> additional modules or export additional packages. For example, if a >> patch adds types to a new package then you could export that package >> with -XaddExports. If the patch injects tests into an existing package >> then those tests might have new dependences and requires compiling or >> running with -XaddReads:$MODULE=junit for example. > > I was playing around with exactly this yesterday, and this is what I > ended up with: > > javac -Xmodule:javamodularity.easytext.algorithm.naivesyllablecounter \ > -XaddReads:javamodularity.easytext.algorithm.naivesyllablecounter=org.junit > \ > -mp mods:lib-test \ > -d > mods-test/javamodularity.easytext.algorithm.naivesyllablecounter $(find > src-test -name '*.java') > > java -Xpatch:mods-test \ > -XaddReads:javamodularity.easytext.algorithm.naivesyllablecounter=org.junit > \ > -XaddExports:javamodularity.easytext.algorithm.naivesyllablecounter/javamodularity.easytext.algorithm.naivesyllablecounter=org.junit > \ > -mp mods:lib-test \ > -addmods > javamodularity.easytext.algorithm.naivesyllablecounter,hamcrestcore \ > -m org.junit/org.junit.runner.JUnitCore > javamodularity.easytext.algorithm.naivesyllablecounter.NaiveSyllableCounterTest > > Which patches my application module to contain a unit test, and then > exposes my application module to junit at runtime (which is used as > automatic module here). This works as expected. > > > -- Sander When translating this to Maven it assumes that Maven is aware of the module name of the project is it building. Up until now that's not true. Developers specify the moduleName in the module-info.java and it doesn't make sense to ask them to add the same modulename to the pom (it that was possible) or the maven-compiler-plugin configuration. Instead Maven could use some new java9 APIs to discover the moduleName, but that would imply that from now on maven-compiler-plugin requires Java9 runtime. I don't think that's the way we want to go right now. Several Maven plugins have their own kind of multi-release pattern where some codeblocks depend on a specific Maven version, but we really want to avoid this. I hope we can find a way where Maven can simply refer to the classes-directory or the jar for some java/javac arguments where one would now need to be aware of its module name. From Mavens point of view the output directories are facts, dependencies from the pom.xml too, as is the packaged artifact name & location, the content of java files are a mystery and not of any interest (at least in a classpath world ;) ). thanks, Robert From pbenedict at apache.org Tue Mar 8 20:06:41 2016 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 8 Mar 2016 14:06:41 -0600 Subject: modulepath and classpath mixture In-Reply-To: References: <56CBAD62.3010508@oracle.com> <56D1C726.8020508@oracle.com> <56DD7072.7060009@oracle.com> <24463131-7A64-4E23-AECE-F3DC729CA886@luminis.eu> Message-ID: Robert, it's sounds like a chicken-and-egg problem. You need the module name to compile but don't know it until you have compiled. Too bad this file isn't XML so that any tool could read the module information outside of compiling. That's what I advocated for a long time but that battle has been lost. Cheers, Paul On Tue, Mar 8, 2016 at 1:36 PM, Robert Scholte wrote: > On Mon, 07 Mar 2016 14:53:28 +0100, Sander Mak > wrote: > > >> I don't think I understand the issue here. Using -Xpatch doesn't change >>> the module declaration or export. It can be used to override or augment the >>> module content, it just can't override the module declaration. It can be >>> used in conjunction with -XaddReads and -XaddExports to read additional >>> modules or export additional packages. For example, if a patch adds types >>> to a new package then you could export that package with -XaddExports. If >>> the patch injects tests into an existing package then those tests might >>> have new dependences and requires compiling or running with >>> -XaddReads:$MODULE=junit for example. >>> >> >> I was playing around with exactly this yesterday, and this is what I >> ended up with: >> >> javac -Xmodule:javamodularity.easytext.algorithm.naivesyllablecounter \ >> >> -XaddReads:javamodularity.easytext.algorithm.naivesyllablecounter=org.junit >> \ >> -mp mods:lib-test \ >> -d mods-test/javamodularity.easytext.algorithm.naivesyllablecounter >> $(find src-test -name '*.java') >> >> java -Xpatch:mods-test \ >> >> -XaddReads:javamodularity.easytext.algorithm.naivesyllablecounter=org.junit >> \ >> >> -XaddExports:javamodularity.easytext.algorithm.naivesyllablecounter/javamodularity.easytext.algorithm.naivesyllablecounter=org.junit >> \ >> -mp mods:lib-test \ >> -addmods >> javamodularity.easytext.algorithm.naivesyllablecounter,hamcrestcore \ >> -m org.junit/org.junit.runner.JUnitCore >> javamodularity.easytext.algorithm.naivesyllablecounter.NaiveSyllableCounterTest >> >> Which patches my application module to contain a unit test, and then >> exposes my application module to junit at runtime (which is used as >> automatic module here). This works as expected. >> >> >> -- Sander >> > > When translating this to Maven it assumes that Maven is aware of the > module name of the project is it building. > Up until now that's not true. Developers specify the moduleName in the > module-info.java and it doesn't make sense to ask them to add the same > modulename to the pom (it that was possible) or the maven-compiler-plugin > configuration. Instead Maven could use some new java9 APIs to discover the > moduleName, but that would imply that from now on maven-compiler-plugin > requires Java9 runtime. I don't think that's the way we want to go right > now. Several Maven plugins have their own kind of multi-release pattern > where some codeblocks depend on a specific Maven version, but we really > want to avoid this. > I hope we can find a way where Maven can simply refer to the > classes-directory or the jar for some java/javac arguments where one would > now need to be aware of its module name. > From Mavens point of view the output directories are facts, dependencies > from the pom.xml too, as is the packaged artifact name & location, the > content of java files are a mystery and not of any interest (at least in a > classpath world ;) ). > > thanks, > Robert > From harold.seigel at oracle.com Tue Mar 8 21:01:24 2016 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Tue, 08 Mar 2016 21:01:24 +0000 Subject: hg: jigsaw/jake/hotspot: Add #include from JDK-9 to fix open build Message-ID: <201603082101.u28L1OI9027405@aojmv0008.oracle.com> Changeset: 1ae14b475915 Author: hseigel Date: 2016-03-08 15:34 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1ae14b475915 Add #include from JDK-9 to fix open build ! src/share/vm/trace/traceTypes.xsl From naoto.sato at oracle.com Tue Mar 8 21:37:15 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 8 Mar 2016 13:37:15 -0800 Subject: Initial webrev with changes for JDK 9 In-Reply-To: <56DEF447.4000309@oracle.com> References: <56D84C7D.9020006@oracle.com> <56DEF447.4000309@oracle.com> Message-ID: <56DF460B.7010405@oracle.com> Hello, I reviewed ResourceBundle code and related locale data changes. Overall it looks good to me. Here are some minor comments: java.util.ResourceBundle.java - In the class description, there are two occurrences of example explaing service provider type (i.e., basename+"Provider"). It seems a bit redundant. If they should be there in both locations, then I'd use the same example. Currently, one base name is "p.MyResources", and the other is "com.example.app.MyResources". - This is sort of a hypothetical situation but what if a named module provides both local ResourceBundle, and a ResourceBundleProvider that "happens" to have that base name but returns a different bundle implementation? I guess ResourceBundleProvider wins, and I would expect that precedence described somewhere. - Line 626-630: This comment of CacheKey class should include some description for the newly added "module" key. Same is true for line 1620-1623. sun.util.resources.LocaleData.java - line 233: Can be removed, as it is redundant. Naoto On 3/8/16 7:48 AM, Alan Bateman wrote: > > I've refreshed the webrevs here: > http://cr.openjdk.java.net/~alanb/8142968/1 > > so that we have a snapshot of what is currently in the jigsaw/jake > forest. The webrves are against jdk-9+108. > > I plan to send mail to jdk9-dev soon proposing that we integrate a > snapshot into JDK 9 before the end of March. > > -Alan. From sean.coffey at oracle.com Tue Mar 8 22:06:57 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 8 Mar 2016 22:06:57 +0000 Subject: Initial webrev with changes for JDK 9 In-Reply-To: <56D84C7D.9020006@oracle.com> References: <56D84C7D.9020006@oracle.com> Message-ID: <56DF4D01.3000305@oracle.com> I'm hoping we can bulk up some of the new exception handling. I've put suggested edits for the jdk repo together in a webrev. No major edits here but it should help supportability of the code for the future. Will it be possible to import these in before the bulk push ? http://cr.openjdk.java.net/~coffeys/webrev.jake_edits/webrev/ Regards, Sean. On 03/03/2016 14:38, Alan Bateman wrote: > > I've pushed webrevs with the initial changes for JDK 9 here: > http://cr.openjdk.java.net/~alanb/8142968/0/ > > This is a snapshot of what is currently in the jigsaw/jake forest. Our > mission over the next few weeks is to iterate on this and get it to > the point where we + Reviewers are happy that it is a > reasonable/acceptable state to bring into JDK 9. We will need to set a > deadline so that we can plan the integration, more on this soon. As > per our previous milestones (JEP 201 and JEP 220) then we'll ask that > the integration from jdk9/dev to master skip a beat so that the module > system is the only change in master that week. > > It's important to remember that the initial push to JDK 9 is exactly > that, it's not the final bits. There are many areas that still need > work, there are many open issues, there is an ongoing JSR, and of > course there will be ongoing feedback that will help us get it right. > > Another important thing to say is this isn't a module system design or > API review. Questions/comments on the module system design can be > brought up here of course but we might have to punt to > jpms-spec-comments on topics that involve JSR discussions. For the API > then I expect it will go through many iterations, as every good API does. > > > The following is a summary of what is in each repository, this might > help to get a feel for where the implementation is currently at. > > > ** top-level repository ** > > Most of the build changes have already been pushed to JDK 9 as part of > JEP 201 and subsequent iteration. There are some additional > jake-specific build changes, most of it is in the top-level repository > with some changes in other repositories too. > > Of significance is that the temporary modules.xml document in the root > directory is gone, this has been replaced by a module declaration in > the source code of each module. The other significant thing is that > the build creates a packaged module for each standard and JDK module. > It also uses the jlink tool to create the JDK and JRE run-time images. > > Erik Joelsson will take point for all the build changes, with help > from Reviewers from the build group. > > > ** hotspot repository ** > > At a high-level, the changes in hotspot repository adds support for > modules to the virtual machine with access control extended to modules. > > Startup has been significantly reworked into a sequence of phases, > akin to runlevels, so that the module system is initialized before any > code outside of the base module is loaded. > > What we used to know as the boot class path is mostly gone except for > agent and -Xbootclasspath/a cases. Classes are instead loaded from > modules defined to boot loader. There is also support for patching > modules for testing and ad hoc needs. > > JNI has new functions, as has JVM TI with initial support for > debuggers and agents that instrument code in modules. There is > additional work on JVM TI in progress so expect to see more in later > webrevs. > > There are a number of diagnosability improvements, include improved > exception messages and support for module details in stack traces. > > There are many new tests. There are also updates to many existing > tests. Christian Tornqvist is planning to bring at least some of test > changes into jdk9/dev so we should see the patch reduce a bit once we > sync up. > > Lois Foltan will take point on the hotspot repository, she has lined > up several Reviewers in the hotspot group to help. > > > ** langtools repository ** > > As expected, the javac compiler is significantly updated to support > compilation containing module declarations. The javadoc tool and > doclet code has also involve significant changes. > > When compiling then there are several new command-line options, > support for module paths, and new compilation modes. JEP 261 has > useful descriptions. > > The jdeps tool has been upgraded with many new options. The javap tool > has also been updated. > > This repository also has the initial updates to the javax.tools and > javax.lang.model APIs. > > There are a lot of updates to existing tests in the webrev and many > new tests too. > > Jonathan Gibbons will take point for the langtools repository and I > expect will use Reviewers from the compiler group to help get through > this. > > > ** jdk repository ** > > There are a lot of changes in this repository. > > One of the most obvious is that there is a module-info.java source > file in each module's directory. > > There is a new java.lang.module API to support module descriptors and > to create configurations of modules. There are new APIs in > java.lang.reflect to represent modules and layers of modules. > > There are is a lot of support code for the module system itself, for > example ModuleBootstrap is the class that creates the configuration > and creates the boot layer. > > The application and extension class loaders have been replaced with a > new implementation based on BuiltinClassLoader that supports loading > classes/resources from modules (in addition to the class path). Note > that there are no changes to class loader hierarchy and no changes to > visibility except that some non-core modules are no longer defined to > the boot loader. > > In java.lang then Class and ClassLoader have several updates and new > methods to support modules. The legacy Package API and javadoc has > also been overhauled. The System class has been updated to support the > initialization of the module system. > > Core reflection has been updated so that access control is aligned > with the Java Language and VM, except that it assumes readability (a > discussion point in the JSR at this time). Proxy has been > significantly updated so that the package, module and accessibility of > the generated proxy classes are in line with the accessibility of the > proxy interfaces. > > The MethodHandle API has also been updated but I expect there will be > changes soon on this, maybe additional lookup modes and changes when > teleporting from one module to another (as things stand then all > access is lost). > > The ServiceLoader API has been updated to support instantiating > service providers that are deployed as modules. It also has new > support for iterating over service providers in Layers. > > The ResourceBundle API has been significantly updated to support > resources deployed as modules. There are also a lot of changes to the > locale providers. > > This repository has the jlink tool (JEP 282) to assembly a set of > modules as a modular run-time image (JEP 220). The jlink tool is > invoked in the JDK build to create the JDK and JRE run-time images as > I mentioned above. > > The jlink tool includes an experimental API for developing plugins > that do transformations or optimizations at link-time. There are > currently 11 plugins in the webrev, the most significant is the > "installed-modules" plugin that generates code at link-time to speed > up the reconstitution of module descriptors during startup. > > There are significant updates to the jimage container implementation > and jrtfs. The most obvious that is there is now only one jimage > container (named "modules") in the run-time image. > > The java launcher has been updated to support module paths and the > other command line options described in JEP 261. > > The jar tool has been updated to support modules packaged as modular > JAR files. It has also been refurbished with support for GNU style > command line options. > > JDI and JDWP have been updated to allow debugger enumerate and > introspect modules in the target VM. java.lang.instrument has initial > updates to support agents that instrument code in modules. > > There are smaller changes in many others including updates to the > logging API, the JMX implementation, Image I/O, JNDI and several > others. Most of these changes are localized and should be > straight-forward to understand (esp as the code is organized by module). > > There are lot of new tests. Some of the new tests aren't in the right > location yet and we'll resolve that soon. There are fewer updates to > existing tests that might be expected and this is because we've been > able to get the changes to several thousand tests into JDK 9 in advance. > > Jim Laskey and Sundararajan Athijegannathan will take point for the > jlink, jimage and jrtfs changes. > > For everything else then assume that Mandy Chung and I will take point > for now. We have approached many jdk9 Reviewers to help get through this. > > > ** nashorn repository ** > > Nashorn has been updated to work with a modular runtime, including > spinning dynamic modules. This is the first of the dynamic languages > to get working and we'll need to learn from this to see what might > potentially need to exposed further in the API. > > Sundar will take point on this, with Reviewers from the nashorn project. > > > ** jaxp repository ** > > JAXP has a small update to support the XSLTC generating of translets > in modules at runtime. We need to re-visit this at some point to > generate the translets in their own layer. > > > ** jaxws repository ** > > Most of the changes to JAXB and JAX-WS to work with modules are > already in JDK 9 and pushed to the upstream Metro project. There are > API changes so there will be updates to JSR 222 and JSR 224. > > The residual changes in the jaxws repository are mostly handling of > resources in modules. > > > ** corba repository ** > > No changes here except the module declaration. > > > I think that is mostly it for now. I will published new webrevs > periodically to take account of the ongoing changes. > > On wider communication, then we'll send mail to jdk9-dev soon to make > everyone working on the JDK 9 project aware that we are starting to > plan the integration into JDK 9. > > -Alan. From david.lloyd at redhat.com Tue Mar 8 22:08:36 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 8 Mar 2016 16:08:36 -0600 Subject: modulepath and classpath mixture In-Reply-To: References: <56CBAD62.3010508@oracle.com> <56D1C726.8020508@oracle.com> <56DD7072.7060009@oracle.com> <24463131-7A64-4E23-AECE-F3DC729CA886@luminis.eu> Message-ID: <56DF4D64.5080504@redhat.com> The only rational solution to this problem is to completely forego the JDK's capabilities and generate the file exclusively from the build tooling. I expect that at some point we'll end up with a series of tools which construct the exports list from annotated package-infos, the requires list from a mapping or static list in the build, and a bunch of build- and application-system specific miscellany besides. I don't believe that any nontrivial program is likely to bundle a module-info.java source file all, which makes me wonder if there's actually a point to having support for it at all. Why write it when you can generate it, and at the same time, keep all your build-related information in one spot? On 03/08/2016 02:06 PM, Paul Benedict wrote: > Robert, it's sounds like a chicken-and-egg problem. You need the module > name to compile but don't know it until you have compiled. > > Too bad this file isn't XML so that any tool could read the module > information outside of compiling. That's what I advocated for a long time > but that battle has been lost. > > > > Cheers, > Paul > > On Tue, Mar 8, 2016 at 1:36 PM, Robert Scholte wrote: > >> On Mon, 07 Mar 2016 14:53:28 +0100, Sander Mak >> wrote: >> >> >>> I don't think I understand the issue here. Using -Xpatch doesn't change >>>> the module declaration or export. It can be used to override or augment the >>>> module content, it just can't override the module declaration. It can be >>>> used in conjunction with -XaddReads and -XaddExports to read additional >>>> modules or export additional packages. For example, if a patch adds types >>>> to a new package then you could export that package with -XaddExports. If >>>> the patch injects tests into an existing package then those tests might >>>> have new dependences and requires compiling or running with >>>> -XaddReads:$MODULE=junit for example. >>>> >>> >>> I was playing around with exactly this yesterday, and this is what I >>> ended up with: >>> >>> javac -Xmodule:javamodularity.easytext.algorithm.naivesyllablecounter \ >>> >>> -XaddReads:javamodularity.easytext.algorithm.naivesyllablecounter=org.junit >>> \ >>> -mp mods:lib-test \ >>> -d mods-test/javamodularity.easytext.algorithm.naivesyllablecounter >>> $(find src-test -name '*.java') >>> >>> java -Xpatch:mods-test \ >>> >>> -XaddReads:javamodularity.easytext.algorithm.naivesyllablecounter=org.junit >>> \ >>> >>> -XaddExports:javamodularity.easytext.algorithm.naivesyllablecounter/javamodularity.easytext.algorithm.naivesyllablecounter=org.junit >>> \ >>> -mp mods:lib-test \ >>> -addmods >>> javamodularity.easytext.algorithm.naivesyllablecounter,hamcrestcore \ >>> -m org.junit/org.junit.runner.JUnitCore >>> javamodularity.easytext.algorithm.naivesyllablecounter.NaiveSyllableCounterTest >>> >>> Which patches my application module to contain a unit test, and then >>> exposes my application module to junit at runtime (which is used as >>> automatic module here). This works as expected. >>> >>> >>> -- Sander >>> >> >> When translating this to Maven it assumes that Maven is aware of the >> module name of the project is it building. >> Up until now that's not true. Developers specify the moduleName in the >> module-info.java and it doesn't make sense to ask them to add the same >> modulename to the pom (it that was possible) or the maven-compiler-plugin >> configuration. Instead Maven could use some new java9 APIs to discover the >> moduleName, but that would imply that from now on maven-compiler-plugin >> requires Java9 runtime. I don't think that's the way we want to go right >> now. Several Maven plugins have their own kind of multi-release pattern >> where some codeblocks depend on a specific Maven version, but we really >> want to avoid this. >> I hope we can find a way where Maven can simply refer to the >> classes-directory or the jar for some java/javac arguments where one would >> now need to be aware of its module name. >> From Mavens point of view the output directories are facts, dependencies >> from the pom.xml too, as is the packaged artifact name & location, the >> content of java files are a mystery and not of any interest (at least in a >> classpath world ;) ). >> >> thanks, >> Robert >> -- - DML From pbenedict at apache.org Tue Mar 8 22:26:14 2016 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 8 Mar 2016 16:26:14 -0600 Subject: modulepath and classpath mixture In-Reply-To: <56DF4D64.5080504@redhat.com> References: <56CBAD62.3010508@oracle.com> <56D1C726.8020508@oracle.com> <56DD7072.7060009@oracle.com> <24463131-7A64-4E23-AECE-F3DC729CA886@luminis.eu> <56DF4D64.5080504@redhat.com> Message-ID: Bikeshed: JDK 9 is supposed to be feature complete 5/26/16 and be RC by next January. Is this really enough time for EE Application Server projects and other tools like Maven to vet the capabilities? Cheers, Paul On Tue, Mar 8, 2016 at 4:08 PM, David M. Lloyd wrote: > The only rational solution to this problem is to completely forego the > JDK's capabilities and generate the file exclusively from the build > tooling. I expect that at some point we'll end up with a series of tools > which construct the exports list from annotated package-infos, the requires > list from a mapping or static list in the build, and a bunch of build- and > application-system specific miscellany besides. I don't believe that any > nontrivial program is likely to bundle a module-info.java source file all, > which makes me wonder if there's actually a point to having support for it > at all. Why write it when you can generate it, and at the same time, keep > all your build-related information in one spot? > > > On 03/08/2016 02:06 PM, Paul Benedict wrote: > >> Robert, it's sounds like a chicken-and-egg problem. You need the module >> name to compile but don't know it until you have compiled. >> >> Too bad this file isn't XML so that any tool could read the module >> information outside of compiling. That's what I advocated for a long time >> but that battle has been lost. >> >> >> >> Cheers, >> Paul >> >> On Tue, Mar 8, 2016 at 1:36 PM, Robert Scholte >> wrote: >> >> On Mon, 07 Mar 2016 14:53:28 +0100, Sander Mak >>> wrote: >>> >>> >>> I don't think I understand the issue here. Using -Xpatch doesn't change >>>> >>>>> the module declaration or export. It can be used to override or >>>>> augment the >>>>> module content, it just can't override the module declaration. It can >>>>> be >>>>> used in conjunction with -XaddReads and -XaddExports to read additional >>>>> modules or export additional packages. For example, if a patch adds >>>>> types >>>>> to a new package then you could export that package with -XaddExports. >>>>> If >>>>> the patch injects tests into an existing package then those tests might >>>>> have new dependences and requires compiling or running with >>>>> -XaddReads:$MODULE=junit for example. >>>>> >>>>> >>>> I was playing around with exactly this yesterday, and this is what I >>>> ended up with: >>>> >>>> javac -Xmodule:javamodularity.easytext.algorithm.naivesyllablecounter \ >>>> >>>> >>>> -XaddReads:javamodularity.easytext.algorithm.naivesyllablecounter=org.junit >>>> \ >>>> -mp mods:lib-test \ >>>> -d >>>> mods-test/javamodularity.easytext.algorithm.naivesyllablecounter >>>> $(find src-test -name '*.java') >>>> >>>> java -Xpatch:mods-test \ >>>> >>>> >>>> -XaddReads:javamodularity.easytext.algorithm.naivesyllablecounter=org.junit >>>> \ >>>> >>>> >>>> -XaddExports:javamodularity.easytext.algorithm.naivesyllablecounter/javamodularity.easytext.algorithm.naivesyllablecounter=org.junit >>>> \ >>>> -mp mods:lib-test \ >>>> -addmods >>>> javamodularity.easytext.algorithm.naivesyllablecounter,hamcrestcore \ >>>> -m org.junit/org.junit.runner.JUnitCore >>>> >>>> javamodularity.easytext.algorithm.naivesyllablecounter.NaiveSyllableCounterTest >>>> >>>> Which patches my application module to contain a unit test, and then >>>> exposes my application module to junit at runtime (which is used as >>>> automatic module here). This works as expected. >>>> >>>> >>>> -- Sander >>>> >>>> >>> When translating this to Maven it assumes that Maven is aware of the >>> module name of the project is it building. >>> Up until now that's not true. Developers specify the moduleName in the >>> module-info.java and it doesn't make sense to ask them to add the same >>> modulename to the pom (it that was possible) or the maven-compiler-plugin >>> configuration. Instead Maven could use some new java9 APIs to discover >>> the >>> moduleName, but that would imply that from now on maven-compiler-plugin >>> requires Java9 runtime. I don't think that's the way we want to go right >>> now. Several Maven plugins have their own kind of multi-release pattern >>> where some codeblocks depend on a specific Maven version, but we really >>> want to avoid this. >>> I hope we can find a way where Maven can simply refer to the >>> classes-directory or the jar for some java/javac arguments where one >>> would >>> now need to be aware of its module name. >>> From Mavens point of view the output directories are facts, dependencies >>> from the pom.xml too, as is the packaged artifact name & location, the >>> content of java files are a mystery and not of any interest (at least in >>> a >>> classpath world ;) ). >>> >>> thanks, >>> Robert >>> >>> > -- > - DML > From jonathan.gibbons at oracle.com Tue Mar 8 22:36:44 2016 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 08 Mar 2016 22:36:44 +0000 Subject: hg: jigsaw/jake/langtools: Add missing comments Message-ID: <201603082236.u28Mai2U003123@aojmv0008.oracle.com> Changeset: 806170c571fc Author: jjg Date: 2016-03-08 14:35 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/806170c571fc Add missing comments ! src/jdk.compiler/share/classes/com/sun/source/tree/ExportsTree.java ! src/jdk.compiler/share/classes/com/sun/source/tree/ModuleTree.java ! src/jdk.compiler/share/classes/com/sun/source/tree/ProvidesTree.java ! src/jdk.compiler/share/classes/com/sun/source/tree/RequiresTree.java ! src/jdk.compiler/share/classes/com/sun/source/tree/TreeVisitor.java ! src/jdk.compiler/share/classes/com/sun/source/tree/UsesTree.java From mandy.chung at oracle.com Tue Mar 8 22:38:48 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 08 Mar 2016 22:38:48 +0000 Subject: hg: jigsaw/jake/jdk: 2 new changesets Message-ID: <201603082238.u28Mcmd3003564@aojmv0008.oracle.com> Changeset: be44e8eac21b Author: mchung Date: 2016-03-08 14:38 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/be44e8eac21b java.management review comment ! src/java.management/share/classes/sun/management/ThreadInfoCompositeData.java Changeset: 21b6a9c4195c Author: mchung Date: 2016-03-08 14:38 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/21b6a9c4195c launcher review comment ! src/java.base/share/native/libjli/java.c From mandy.chung at oracle.com Tue Mar 8 23:00:09 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 8 Mar 2016 15:00:09 -0800 Subject: Need help testing the EA builds In-Reply-To: <56DEDCED.5040007@oracle.com> References: <56D7002A.9000509@oracle.com> <56DD4C00.7010908@oracle.com> <56DD6364.4060101@oracle.com> <56DD898F.4050505@oracle.com> <56DDDD49.5020309@oracle.com> <56DEDCED.5040007@oracle.com> Message-ID: <1B1397D4-E28C-49E7-9660-63000E3786A4@oracle.com> > On Mar 8, 2016, at 6:08 AM, Alan Bateman wrote: > > > On 08/03/2016 07:45, Volker Simonis wrote: >> : >> OK, that would be fine. This problem isn't very urgent but it would be >> good if we could resolve it before the big jake integration into >> jdk9-dev. >> >> > In order, then my preferences for resolving this are: > > 1. Compete the tool separation, meaning JDK-8059035. > > 2. Change these tools to use services so that the SA backend is a service provider. > #2 seems to be trivial and I quickly hack up a patch: http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/8059035/webrev.00/ This would need Dmitry and others to help do verification. Mandy > 3. Build-time solution. > > 4. Drop the dependency but compile the launchers for the tools on platforms that support SA with -addmods jdk.hotspot.agent or ALL-SYSTEM. > > I agree we need to address this soon. > > -Alan. From mandy.chung at oracle.com Tue Mar 8 23:45:32 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 8 Mar 2016 15:45:32 -0800 Subject: Initial webrev with changes for JDK 9 In-Reply-To: <56DF460B.7010405@oracle.com> References: <56D84C7D.9020006@oracle.com> <56DEF447.4000309@oracle.com> <56DF460B.7010405@oracle.com> Message-ID: > On Mar 8, 2016, at 1:37 PM, Naoto Sato wrote: > > Hello, > > I reviewed ResourceBundle code and related locale data changes. Overall it looks good to me. Here are some minor comments: > > java.util.ResourceBundle.java > > - In the class description, there are two occurrences of example explaing service provider type (i.e., basename+"Provider"). It seems a bit redundant. If they should be there in both locations, then I'd use the same example. Currently, one base name is "p.MyResources", and the other is "com.example.app.MyResources?. I changed it to com.example.app. > - This is sort of a hypothetical situation but what if a named module provides both local ResourceBundle, and a ResourceBundleProvider that "happens" to have that base name but returns a different bundle implementation? I guess ResourceBundleProvider wins, If the module provides ResourceBundleProvider, it will not search its local resource bundle. > and I would expect that precedence described somewhere. > It?s described here: 246 * In named modules, the loaded service providers for the given base name are 247 * used to load resource bundles. If no service providers are available, or if 248 * none of the service providers returns a resource bundle and the caller module 249 * doesn't have its own service provider, the {@code getBundle} factory method 250 * searches for resource bundles local to the caller module. > - Line 626-630: This comment of CacheKey class should include some description for the newly added "module" key. Same is true for line 1620-1623. > > sun.util.resources.LocaleData.java > > - line 233: Can be removed, as it is redundant. > Removed. Mandy > Naoto > > On 3/8/16 7:48 AM, Alan Bateman wrote: >> >> I've refreshed the webrevs here: >> http://cr.openjdk.java.net/~alanb/8142968/1 >> >> so that we have a snapshot of what is currently in the jigsaw/jake >> forest. The webrves are against jdk-9+108. >> >> I plan to send mail to jdk9-dev soon proposing that we integrate a >> snapshot into JDK 9 before the end of March. >> >> -Alan. From jonathan.gibbons at oracle.com Tue Mar 8 23:45:49 2016 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 08 Mar 2016 23:45:49 +0000 Subject: hg: jigsaw/jake/langtools: unexport javap Message-ID: <201603082345.u28Njn2j026919@aojmv0008.oracle.com> Changeset: 0cb233626ef4 Author: jjg Date: 2016-03-08 15:45 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/0cb233626ef4 unexport javap ! src/jdk.jdeps/share/classes/module-info.java ! test/tools/javac/6627362/T6627362.java ! test/tools/javac/ConstFoldTest.java ! test/tools/javac/T4965689/ClassLiteralWastesByteTest.java ! test/tools/javac/T5053846/MethodRefDupInConstantPoolTest.java ! test/tools/javac/T6181889/EmptyFinallyTest.java ! test/tools/javac/T6985181.java ! test/tools/javac/T7040592/T7040592.java ! test/tools/javac/annotations/typeAnnotations/classfile/NestedLambdasCastedTest.java ! test/tools/javac/code/ArrayClone.java ! test/tools/javac/lambda/LambdaInnerTypeVarReflect.java ! test/tools/javac/modules/AddReadsTest.java ! test/tools/javac/stackmap/StackMapTest.java ! test/tools/javap/4111861/T4111861.java ! test/tools/javap/4798312/JavapShouldLoadClassesFromRTJarTest.java ! test/tools/javap/4866831/PublicInterfaceTest.java ! test/tools/javap/4870651/T4870651.java ! test/tools/javap/6937244/T6937244.java ! test/tools/javap/6937244/T6937244A.java ! test/tools/javap/8006334/JavapTaskCtorFailWithNPE.java ! test/tools/javap/8007907/JavapReturns0AfterClassNotFoundTest.java ! test/tools/javap/AccessModifiers.java ! test/tools/javap/BadAttributeLength.java ! test/tools/javap/BoundsTypeVariableTest.java ! test/tools/javap/DescriptorTest.java ! test/tools/javap/ExtPath.java ! test/tools/javap/InvalidOptions.java ! test/tools/javap/MethodParameters.java ! test/tools/javap/StackMapTableTest.java ! test/tools/javap/T4075403.java ! test/tools/javap/T4459541.java ! test/tools/javap/T4501660.java ! test/tools/javap/T4501661.java ! test/tools/javap/T4777949.java ! test/tools/javap/T4876942.java ! test/tools/javap/T4880663.java ! test/tools/javap/T4880672.java ! test/tools/javap/T4884240.java ! test/tools/javap/T4975569.java ! test/tools/javap/T6271787.java ! test/tools/javap/T6474890.java ! test/tools/javap/T6587786.java ! test/tools/javap/T6622216.java ! test/tools/javap/T6622232.java ! test/tools/javap/T6622260.java ! test/tools/javap/T6715251.java ! test/tools/javap/T6715753.java ! test/tools/javap/T6715767.java ! test/tools/javap/T6729471.java ! test/tools/javap/T6824493.java ! test/tools/javap/T6863746.java ! test/tools/javap/T6866657.java ! test/tools/javap/T6868539.java ! test/tools/javap/T6879371.java ! test/tools/javap/T6980017.java ! test/tools/javap/T7004698.java ! test/tools/javap/T7186925.java ! test/tools/javap/T7190862.java ! test/tools/javap/T8032814.java ! test/tools/javap/T8032819.java ! test/tools/javap/T8033180.java ! test/tools/javap/T8033711.java ! test/tools/javap/T8035104.java ! test/tools/javap/T8038414.java ! test/tools/javap/TestSuperclass.java ! test/tools/javap/WhitespaceTest.java ! test/tools/javap/stackmap/StackmapTest.java ! test/tools/javap/typeAnnotations/T6855990.java From mandy.chung at oracle.com Tue Mar 8 23:47:10 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 08 Mar 2016 23:47:10 +0000 Subject: hg: jigsaw/jake/jdk: resource bundle review comment Message-ID: <201603082347.u28NlAb4027585@aojmv0008.oracle.com> Changeset: 8d10a22ce763 Author: mchung Date: 2016-03-08 15:47 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8d10a22ce763 resource bundle review comment ! src/java.base/share/classes/java/util/ResourceBundle.java ! src/java.base/share/classes/sun/util/resources/LocaleData.java From mandy.chung at oracle.com Wed Mar 9 01:37:16 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 09 Mar 2016 01:37:16 +0000 Subject: hg: jigsaw/jake: Reenable -Xdoclint for jdk.compiler Message-ID: <201603090137.u291bG6Y002706@aojmv0008.oracle.com> Changeset: 66a5d67b0116 Author: mchung Date: 2016-03-08 16:24 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/66a5d67b0116 Reenable -Xdoclint for jdk.compiler ! make/CompileJavaModules.gmk From jonathan.gibbons at oracle.com Wed Mar 9 01:47:07 2016 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 09 Mar 2016 01:47:07 +0000 Subject: hg: jigsaw/jake/langtools: start converting new code to new diags system Message-ID: <201603090147.u291l7i3005336@aojmv0008.oracle.com> Changeset: 8c6b165360cb Author: jjg Date: 2016-03-08 17:46 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/8c6b165360cb start converting new code to new diags system ! 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/modules/ProvidesTest.java ! test/tools/javac/modules/RepeatedUsesAndProvidesTest.java ! test/tools/javac/modules/T8145013/ServiceProvidedButNotExportedOrUsedTest.java ! test/tools/javac/modules/UsesTest.java From jonathan.gibbons at oracle.com Wed Mar 9 02:48:04 2016 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 09 Mar 2016 02:48:04 +0000 Subject: hg: jigsaw/jake/langtools: 2 new changesets Message-ID: <201603090248.u292m44U023858@aojmv0008.oracle.com> Changeset: 653b36207ab2 Author: jjg Date: 2016-03-08 18:40 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/653b36207ab2 minor source cleanup ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java Changeset: 4592ca08edb5 Author: jjg Date: 2016-03-08 18:47 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/4592ca08edb5 fixup tests for javap ! test/jdk/jshell/ClassPathTest.java ! test/jdk/jshell/CommandCompletionTest.java ! test/jdk/jshell/CompletionSuggestionTest.java ! test/jdk/jshell/ComputeFQNsTest.java ! test/jdk/jshell/ErrorTranslationTest.java ! test/jdk/jshell/ImportTest.java ! test/jdk/jshell/InferTypeTest.java ! test/jdk/jshell/StartOptionTest.java ! test/jdk/jshell/ToolReloadTest.java ! test/tools/javac/MissingInclude/MissingIncludeTest.java ! test/tools/javac/T6725036.java ! test/tools/javac/T6970173/DebugPointerAtBadPositionTest.java ! test/tools/javac/T8010659/CompilerCrashWhenMixingBinariesAndSourcesTest.java ! test/tools/javac/T8013394/CompileErrorWithIteratorTest.java ! test/tools/javac/T8019486/WrongLNTForLambdaTest.java ! test/tools/javac/T8024039/NoDeadCodeGenerationOnTrySmtTest.java ! test/tools/javac/classfiles/InnerClasses/T8068517.java ! test/tools/javac/classfiles/attributes/LocalVariableTable/LocalVariableTypeTableTest.java ! test/tools/javac/classfiles/attributes/Signature/EnumTest.java ! test/tools/javac/classfiles/attributes/Signature/ExceptionTest.java ! test/tools/javac/classfiles/attributes/Signature/MethodTypeBoundTest.java ! test/tools/javac/classfiles/attributes/SourceFile/InnerClassTest.java ! test/tools/javac/classfiles/attributes/SourceFile/MixTest.java ! test/tools/javac/classfiles/attributes/SourceFile/NoSourceFileAttribute.java ! test/tools/javac/classfiles/attributes/Synthetic/AccessToPrivateSiblingsTest.java ! test/tools/javac/classfiles/attributes/Synthetic/AssertFieldTest.java ! test/tools/javac/classfiles/attributes/Synthetic/EnumTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerEnumInInnerAnnotationTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerEnumsInInnerClassTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerInterfacesInInnerClassTest.java ! test/tools/javac/classfiles/attributes/innerclasses/NoInnerClassesTest.java ! test/tools/javac/importscope/ImportMembersTest.java ! test/tools/javac/modules/AbstractOrInnerClassServiceImplTest.java ! test/tools/javac/modules/AddLimitMods.java ! test/tools/javac/modules/AnnotationProcessing.java ! test/tools/javac/modules/AnnotationProcessorsInModulesTest.java ! test/tools/javac/modules/AutomaticModules.java ! test/tools/javac/modules/DuplicateClassTest.java ! test/tools/javac/modules/HelloWorldTest.java ! test/tools/javac/modules/ModuleInfoTest.java ! test/tools/javac/modules/ModuleSourcePathTest.java ! test/tools/javac/modules/MultiModuleModeTest.java ! test/tools/javac/modules/PackageConflictTest.java ! test/tools/javac/modules/PluginsInModulesTest.java ! test/tools/javac/modules/RepeatedUsesAndProvidesTest.java ! test/tools/javac/modules/ReportNonExistentPackageTest.java ! test/tools/javac/modules/SingleModuleModeTest.java ! test/tools/javac/modules/T8145013/ServiceProvidedButNotExportedOrUsedTest.java ! test/tools/javac/modules/UpgradeModulePathTest.java ! test/tools/javac/modules/XModuleTest.java ! test/tools/javac/newlines/NewLineTest.java ! test/tools/javah/constMacroTest/ConstMacroTest.java From jonathan.gibbons at oracle.com Wed Mar 9 04:06:36 2016 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 09 Mar 2016 04:06:36 +0000 Subject: hg: jigsaw/jake/langtools: convert new code to use new diags system Message-ID: <201603090406.u2946aeg018734@aojmv0008.oracle.com> Changeset: b252701735f4 Author: jjg Date: 2016-03-08 20:06 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/b252701735f4 convert new code to use new diags system ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/ModuleFinder.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/BaseFileManager.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Arguments.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/modules/AnnotationProcessorsInModulesTest.java From mandy.chung at oracle.com Wed Mar 9 04:43:35 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 09 Mar 2016 04:43:35 +0000 Subject: hg: jigsaw/jake/jdk: Minor javadoc cleanup Message-ID: <201603090443.u294hZ4C028832@aojmv0008.oracle.com> Changeset: b77257de7003 Author: mchung Date: 2016-03-08 20:43 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b77257de7003 Minor javadoc cleanup ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/classes/java/lang/ClassLoader.java From martin.balin at oracle.com Wed Mar 9 08:40:34 2016 From: martin.balin at oracle.com (Martin Balin) Date: Wed, 9 Mar 2016 09:40:34 +0100 Subject: NetBeans early support of Jigsaw Message-ID: <56DFE182.6030807@oracle.com> Hello, We would like to get a feedback from jigsaw development community on early support of Jigsaw modules in NetBeans. NetBeans IDE currently supports projects with one module (one module-info.java) using NetBeans Ant project type. Description of what you can expect, where to download it is http://wiki.netbeans.org/JigsawSupport We are working on other project types, e.g. evaluating latest Maven support for Jigsaw,... Feedback is welcome. Thank you, Martin Balin From Alan.Bateman at oracle.com Wed Mar 9 08:58:47 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 9 Mar 2016 08:58:47 +0000 Subject: Initial webrev with changes for JDK 9 In-Reply-To: <56DF4D01.3000305@oracle.com> References: <56D84C7D.9020006@oracle.com> <56DF4D01.3000305@oracle.com> Message-ID: <56DFE5C7.7070906@oracle.com> On 08/03/2016 22:06, Se?n Coffey wrote: > I'm hoping we can bulk up some of the new exception handling. I've put > suggested edits for the jdk repo together in a webrev. No major edits > here but it should help supportability of the code for the future. > Will it be possible to import these in before the bulk push ? > > http://cr.openjdk.java.net/~coffeys/webrev.jake_edits/webrev/ Thanks for bringing this up. No issue improving the exception messages, esp. incorrect API mis-use. I note that you've changed several InternalError where the JDK must be completely hosed (`java -version` would fail) if they were to arise. Given that there will be significant code churn for several months then maybe it would be better to do a pass over the exceptions closer to JDK 9 FC. Would you be okay with that? We can create an issue in JIRA to make sure that it doesn't get forgotten. -Alan From Alan.Bateman at oracle.com Wed Mar 9 09:02:16 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 9 Mar 2016 09:02:16 +0000 Subject: Initial webrev with changes for JDK 9 - jimage In-Reply-To: <56DF14EE.1050102@Oracle.com> References: <56D84C7D.9020006@oracle.com> <56DF14EE.1050102@Oracle.com> Message-ID: <56DFE698.8040209@oracle.com> On 08/03/2016 18:07, Roger Riggs wrote: > Hi, > > Review comments for the jimage code in java.base, mostly cleanup but > perhaps a bug or two. > General: inconsistent style and not following guidelines, copyright > dates may need an update. > Use of assert for error checking is not going to catch or help isolate > errors in production builds. I think Jim Laskey is going to reply to you on these comments. On copyright dates then I submitted an issue a few weeks ago to schedule a bulk update in JDK 9. This hasn't been done for some time and there are many files that need their dates updated. -Alan From sean.coffey at oracle.com Wed Mar 9 09:07:44 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 9 Mar 2016 09:07:44 +0000 Subject: Initial webrev with changes for JDK 9 In-Reply-To: <56DFE5C7.7070906@oracle.com> References: <56D84C7D.9020006@oracle.com> <56DF4D01.3000305@oracle.com> <56DFE5C7.7070906@oracle.com> Message-ID: <56DFE7E0.7050504@oracle.com> On 09/03/2016 08:58, Alan Bateman wrote: > > On 08/03/2016 22:06, Se?n Coffey wrote: >> I'm hoping we can bulk up some of the new exception handling. I've >> put suggested edits for the jdk repo together in a webrev. No major >> edits here but it should help supportability of the code for the >> future. Will it be possible to import these in before the bulk push ? >> >> http://cr.openjdk.java.net/~coffeys/webrev.jake_edits/webrev/ > Thanks for bringing this up. No issue improving the exception > messages, esp. incorrect API mis-use. I note that you've changed > several InternalError where the JDK must be completely hosed (`java > -version` would fail) if they were to arise. Agreed - important for end user to know what the JDK's last breath was all about. > > Given that there will be significant code churn for several months > then maybe it would be better to do a pass over the exceptions closer > to JDK 9 FC. Would you be okay with that? We can create an issue in > JIRA to make sure that it doesn't get forgotten. Yes - that works. I'll put forward a patch when this is in jdk9/dev. I was hoping to would be easier to target corrections before it entered the mainline. regards, Sean. > > -Alan From volker.simonis at gmail.com Wed Mar 9 09:23:14 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 9 Mar 2016 10:23:14 +0100 Subject: Need help testing the EA builds In-Reply-To: <1B1397D4-E28C-49E7-9660-63000E3786A4@oracle.com> References: <56D7002A.9000509@oracle.com> <56DD4C00.7010908@oracle.com> <56DD6364.4060101@oracle.com> <56DD898F.4050505@oracle.com> <56DDDD49.5020309@oracle.com> <56DEDCED.5040007@oracle.com> <1B1397D4-E28C-49E7-9660-63000E3786A4@oracle.com> Message-ID: Hi Mandy, thanks a lot for your patch. I've just verified that it works perfectly on AIX and also did some smoke test on Linux (i.e. jstack) which confirm that the original functionality is still preserved. This is not a complete review because I'm not a serviceability expert but with regard to fixing the dependencies on the SA agent in the build I'm completely happy with your change. Thank you and best regards, Volker On Wed, Mar 9, 2016 at 12:00 AM, Mandy Chung wrote: > >> On Mar 8, 2016, at 6:08 AM, Alan Bateman wrote: >> >> >> On 08/03/2016 07:45, Volker Simonis wrote: >>> : >>> OK, that would be fine. This problem isn't very urgent but it would be >>> good if we could resolve it before the big jake integration into >>> jdk9-dev. >>> >>> >> In order, then my preferences for resolving this are: >> >> 1. Compete the tool separation, meaning JDK-8059035. >> >> 2. Change these tools to use services so that the SA backend is a service provider. >> > > #2 seems to be trivial and I quickly hack up a patch: > http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/8059035/webrev.00/ > > This would need Dmitry and others to help do verification. > > Mandy > >> 3. Build-time solution. >> >> 4. Drop the dependency but compile the launchers for the tools on platforms that support SA with -addmods jdk.hotspot.agent or ALL-SYSTEM. >> >> I agree we need to address this soon. >> >> -Alan. > From Alan.Bateman at oracle.com Wed Mar 9 09:34:14 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 9 Mar 2016 09:34:14 +0000 Subject: modulepath and classpath mixture In-Reply-To: References: <56CBAD62.3010508@oracle.com> <56D1C726.8020508@oracle.com> <56DD7072.7060009@oracle.com> Message-ID: <56DFEE16.2020406@oracle.com> On 08/03/2016 19:13, Robert Scholte wrote: > > This is how I thought that -Xpatch would work in short: the > module-info in src/main/java and src/test/java have both the same > modulename. The module-info in src/test/java specifies the extra > required modules (like junit). With -Xpatch the test-classes have > access to the non-exported main-classes too. If the sources in src/test/java are a completely separate module then they will have their own module declaration. If the tests are instead intended to augment the module, say where the tests are in the same package as the code under test, they will not have their own module declaration. This means no module-info.java in src/test/java. As things currently stand then javac -Xmodule:$MODULE will ignore the module-info.java when you compile the sources in src/test/java. At run-time then you'll get a warning if there is a module-info.class found when patching a module. So I think you will need to get the module name when compiling the tests. You should not need the module name when compiling the code in src/main/java of course. The complication for the tests as they are being compiled "as if" they are part of the module. As the tests classes in the same module as the main classes then it means the tests have access to all public types in the modules (no exports are needed). Furthermore, they are in the same package as the main classes then they have access to private package types/methods too. The final part will be running the tests as the injected test classes will have dependences on JUnit or TestNG tests. They module declaration doesn't declare that it requires those and this is why we need to augment it at run-time with -XaddReads so that it reads the JUnit module. There are choices here as to whether JUnit is deployed on the class path or module path, it can work as either. -Alan From Alan.Bateman at oracle.com Wed Mar 9 09:39:32 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 9 Mar 2016 09:39:32 +0000 Subject: Need help testing the EA builds In-Reply-To: <1B1397D4-E28C-49E7-9660-63000E3786A4@oracle.com> References: <56D7002A.9000509@oracle.com> <56DD4C00.7010908@oracle.com> <56DD6364.4060101@oracle.com> <56DD898F.4050505@oracle.com> <56DDDD49.5020309@oracle.com> <56DEDCED.5040007@oracle.com> <1B1397D4-E28C-49E7-9660-63000E3786A4@oracle.com> Message-ID: <56DFEF54.8050605@oracle.com> On 08/03/2016 23:00, Mandy Chung wrote: >> On Mar 8, 2016, at 6:08 AM, Alan Bateman wrote: >> >> In order, then my preferences for resolving this are: >> >> 1. Compete the tool separation, meaning JDK-8059035. >> >> 2. Change these tools to use services so that the SA backend is a service provider. >> > #2 seems to be trivial and I quickly hack up a patch: > http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/8059035/webrev.00/ > Thanks for jumping on this, it looks good and very simple as you say. One thing that might need changes is the location of the tool provider, it's currently sun.tools.providers and that seems too general. Shoudl we put this to a spi package under jdk.internal for now? -Alan From Alan.Bateman at oracle.com Wed Mar 9 11:12:27 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 9 Mar 2016 11:12:27 +0000 Subject: modulepath and classpath mixture In-Reply-To: References: <56CBAD62.3010508@oracle.com> <56D1C726.8020508@oracle.com> <56DD7072.7060009@oracle.com> <24463131-7A64-4E23-AECE-F3DC729CA886@luminis.eu> Message-ID: <56E0051B.6040102@oracle.com> On 08/03/2016 20:06, Paul Benedict wrote: > Robert, it's sounds like a chicken-and-egg problem. You need the module > name to compile but don't know it until you have compiled. > I think the scenario is where the module has been compiled and the issue is the separate compilation of the tests "as if" they are in the module. -Alan From georgiy.rakov at oracle.com Wed Mar 9 13:14:54 2016 From: georgiy.rakov at oracle.com (Georgiy Rakov) Date: Wed, 9 Mar 2016 16:14:54 +0300 Subject: Package, import and type declarations are allowed now in module-info.java by spec In-Reply-To: <56D098BB.5070200@oracle.com> References: <56D07F37.1030806@oracle.com> <56D098BB.5070200@oracle.com> Message-ID: <56E021CE.3050801@oracle.com> Hi Alex, if I understand correctly you mean about following assertions from JLS 7.6: If and only if packages are stored in a file system (?7.2 ), the host system may choose to enforce the restriction that it is a compile-time error if a type is not found in a file under a name composed of the type name plus an extension (such as |.java|or |.jav|) if either of the following is true: * The type is referred to by code in other compilation units of the package in which the type is declared. * The type is declared |public|(and therefore is potentially accessible from code in other packages). Literally these assertion doesn't make presented behavior corresponding to spec because the declared type is neither public nor being referred to from other sources being compiled. Nevertheless following sources doesn't compile either despite the fact that no types are declared there at all. Namely when only package is specified: mod\module-info.java: module mod { exports pkg; } mod\pkg\module-info.java: package pkg; then compiling it by following command line with javac from [2]: javac -modulesourcepath . mod\module-info.java mod\pkg\module-info.java causes following output: mod\pkg\module-info.java:1: error: expected 'module package pkg; ^ 1 error When only import statment is specified: mod\module-info.java: module mod { exports pkg; } mod\pkg\module-info.java: import java.util.List; then compiling it by following command line with javac from [2]: javac -modulesourcepath . mod\module-info.java mod\pkg\module-info.java causes following output: mod\pkg\module-info.java:1: error: expected 'module' import java.util.List; ^ 1 error Please see minimized test cases attached in tests23.zip. In order to reproduce, please: 1. Unzip the attached archive to some dir on Windows machined, say directory A; 2. Rename A\test2\test_bat to A\test2\test.bat and A\test3\test_bat to A\test3\test.bat; 3. Modify these two test.bat files by changing JDK_HOME variable to point to your jigsaw JDK 9 installation directory; 4. Run test.bat files in turn. BTW: javac behavior [2] currently differs depending on whether sources are compiled "in module" mode or not. By "module mode" I mean specifying modulesourcepath option. For instance without modulesourcepath option module declarations are not recognized as valid grammar while import declarations contained within module-info.java compile successfully. This can be seen by experimenting with test3 from the attached testcases. Now javac from [2] even can throw exception in "non-module" mode, please see https://bugs.openjdk.java.net/browse/JDK-8150733. Could you please tell if spec will specify somehow two modes of processing java-sources, now it [1] doesn't. [1] http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html [2] http://download.java.net/java/jigsaw/archive/106/binaries/jigsaw-jdk-9-ea+106_windows-x86_bin.zip Thanks, Georgiy. On 26.02.2016 21:26, Alex Buckley wrote: > On 2/26/2016 8:37 AM, Georgiy Rakov wrote: >> current spec [1] now contains following assertions related to grammar: >> >> A compilation unit (JLS 7.3) may contain a module declaration, in >> which case the filename of the compilation unit is typically >> |module-info.java|. >> >> CompilationUnit: >> [PackageDeclaration] {ImportDeclaration} {TypeDeclaration} >> ModuleDeclaration >> >> These assertions allows to specify any of import, package or type >> declarations in any compilation unit, for instance module-info.java is >> allowed to contain any of the mentioned declarations. However currently >> javac in the latest jigsaw build [2] reports an error on such cases >> provided they are compiled in module mode. For example if we have >> following directory structure: >> >> mod\module-info.java: >> module mod { >> exports pkg; >> } >> >> mod\pkg\module-info.java: >> package pkg; >> >> class C { >> } >> >> then compiling it by following command line with javac from [2]: >> >> javac -modulesourcepath . mod\module-info.java >> mod\pkg\module-info.java >> >> causes following output: >> >> mod\pkg\module-info.java:1: error: expected 'module' >> package pkg; >> ^ >> 1 error > > javac is merely choosing to implement the rule at the end of JLS 7.6 > that a type declaration (optionally preceded by package/import > declarations) must be provided in a suitably named file. > > Perhaps I should say "a variant of the rule" because 7.6 as written > concerns a public type and your example has a package-access type. > Still, bottom line, javac is free to require that a compilation unit > which starts with a package declaration _must not_ be in a file called > foo-bar.java -- the hyphen indicates a name that can't possibly align > with the type declared in the compilation unit. > > The error message for mod\pkg\module-info.java could be a bit more > helpful, but that's a quality-of-implementation detail. > > Conversely, a compilation unit that contains a module declaration > _may_ be in a file called module-info.java, or in a file called > foo-bar.java, or in a file called mod_decl.JAV. The "typically" in [1] > is meant to indicate that the sub-clause on filename is non-normative. > This is akin to how a compilation unit that contains a package-access > type declaration for class C _may_ be in a file D.java. > > Alex From jan.lahoda at oracle.com Wed Mar 9 14:14:53 2016 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Wed, 09 Mar 2016 14:14:53 +0000 Subject: hg: jigsaw/jake/langtools: All tests that use ToolBox must require jdk.jdeps/com.sun.tools.javap Message-ID: <201603091414.u29EErTn008374@aojmv0008.oracle.com> Changeset: 5805785aa08a Author: jlahoda Date: 2016-03-09 15:14 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/5805785aa08a All tests that use ToolBox must require jdk.jdeps/com.sun.tools.javap ! test/tools/doclint/tool/PathsTest.java ! test/tools/javac/4846262/CheckEBCDICLocaleTest.java ! test/tools/javac/6302184/HiddenOptionsShouldUseGivenEncodingTest.java ! test/tools/javac/6508981/TestInferBinaryName.java ! test/tools/javac/AnonymousSubclassTest.java ! test/tools/javac/ClassPathTest/ClassPathTest.java ! test/tools/javac/ExtDirs/ExtDirTest.java ! test/tools/javac/IncorrectInheritance/IncorrectInheritanceTest.java ! test/tools/javac/Paths/AbsolutePathTest.java ! test/tools/javac/ProtectedInnerClass/ProtectedInnerClassesTest.java ! test/tools/javac/T5090006/AssertionFailureTest.java ! test/tools/javac/T6558476.java ! test/tools/javac/T7008643/InlinedFinallyConfuseDebuggersTest.java ! test/tools/javac/T8009640/CheckRejectProfileBCPOptionsIfUsedTogetherTest.java ! test/tools/javac/T8022162/IncorrectSignatureDeterminationForInnerClassesTest.java ! test/tools/javac/T8024437/ExceptionInferenceFromClassFileTest.java ! test/tools/javac/api/ToolProvider/HelloWorldTest.java ! test/tools/javac/api/ToolProvider/ToolProviderTest1.java ! test/tools/javac/api/ToolProvider/ToolProviderTest2.java ! test/tools/javac/boxing/IncrementBoxedAndAccess.java ! test/tools/javac/classfiles/attributes/AnnotationDefault/AnnotationDefaultTest.java ! test/tools/javac/classfiles/attributes/EnclosingMethod/EnclosingMethodTest.java ! test/tools/javac/classfiles/attributes/LineNumberTable/LineNumberTest.java ! test/tools/javac/classfiles/attributes/LocalVariableTable/LocalVariableTableTest.java ! test/tools/javac/classfiles/attributes/Module/ModuleFlagTest.java ! test/tools/javac/classfiles/attributes/Module/ModuleTest.java ! test/tools/javac/classfiles/attributes/Signature/ConstructorTest.java ! test/tools/javac/classfiles/attributes/Signature/FieldTest.java ! test/tools/javac/classfiles/attributes/Signature/InnerClassTest.java ! test/tools/javac/classfiles/attributes/Signature/MethodParameterTest.java ! test/tools/javac/classfiles/attributes/Signature/ReturnTypeTest.java ! test/tools/javac/classfiles/attributes/SourceFile/AnonymousClassTest.java ! test/tools/javac/classfiles/attributes/SourceFile/LocalClassTest.java ! test/tools/javac/classfiles/attributes/SourceFile/ModuleInfoTest.java ! test/tools/javac/classfiles/attributes/SourceFile/SyntheticClassTest.java ! test/tools/javac/classfiles/attributes/SourceFile/TopLevelClassesOneFileTest.java ! test/tools/javac/classfiles/attributes/Synthetic/AccessToPrivateInnerClassMembersTest.java ! test/tools/javac/classfiles/attributes/Synthetic/BridgeMethodForGenericMethodTest.java ! test/tools/javac/classfiles/attributes/Synthetic/BridgeMethodsForLambdaTest.java ! test/tools/javac/classfiles/attributes/Synthetic/PackageInfoTest.java ! test/tools/javac/classfiles/attributes/Synthetic/ThisFieldTest.java ! test/tools/javac/classfiles/attributes/annotations/RuntimeAnnotationsForGenericMethodTest.java ! test/tools/javac/classfiles/attributes/annotations/RuntimeAnnotationsForInnerAnnotationTest.java ! test/tools/javac/classfiles/attributes/annotations/RuntimeAnnotationsForInnerClassTest.java ! test/tools/javac/classfiles/attributes/annotations/RuntimeAnnotationsForInnerEnumTest.java ! test/tools/javac/classfiles/attributes/annotations/RuntimeAnnotationsForInnerInterfaceTest.java ! test/tools/javac/classfiles/attributes/annotations/RuntimeAnnotationsForTopLevelClassTest.java ! test/tools/javac/classfiles/attributes/annotations/RuntimeParameterAnnotationsForGenericMethodTest.java ! test/tools/javac/classfiles/attributes/annotations/RuntimeParameterAnnotationsForLambdaTest.java ! test/tools/javac/classfiles/attributes/annotations/RuntimeParameterAnnotationsTest.java ! test/tools/javac/classfiles/attributes/deprecated/DeprecatedPackageTest.java ! test/tools/javac/classfiles/attributes/deprecated/DeprecatedTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerAnnotationsInInnerAnnotationTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerAnnotationsInInnerClassTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerAnnotationsInInnerEnumTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerAnnotationsInInnerInterfaceTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerClassesHierarchyTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerClassesInAnonymousClassTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerClassesInInnerAnnotationTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerClassesInInnerClassTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerClassesInInnerEnumTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerClassesInInnerInterfaceTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerClassesInLocalClassTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerClassesIndexTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerClassesTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerEnumInInnerEnumTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerEnumInInnerInterfaceTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerInterfacesInInnerAnnotationTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerInterfacesInInnerEnumTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerInterfacesInInnerInterfaceTest.java ! test/tools/javac/defaultMethods/AssertionsTest.java ! test/tools/javac/defaultMethodsVisibility/DefaultMethodsNotVisibleForSourceLessThan8Test.java ! test/tools/javac/fatalErrors/NoJavaLangTest.java ! test/tools/javac/file/ExplodedImage.java ! test/tools/javac/importscope/CompletionFailureDuringImport.java ! test/tools/javac/importscope/ImportDependenciesTest.java ! test/tools/javac/importscope/NegativeCyclicDependencyTest.java ! test/tools/javac/innerClassFile/InnerClassFileTest.java ! test/tools/javac/javazip/JavaZipTest.java ! test/tools/javac/lambda/T8129740/SourceToSourceTranslationTest.java ! test/tools/javac/lambda/lambdaNaming/TestNonSerializableLambdaNameStability.java ! test/tools/javac/lambda/lambdaNaming/TestSerializedLambdaNameStability.java ! test/tools/javac/links/LinksTest.java ! test/tools/javac/main/MOptionTest.java ! test/tools/javac/modules/DoclintOtherModules.java ! test/tools/javac/modules/EdgeCases.java ! test/tools/javac/modules/GraphsTest.java ! test/tools/javac/modules/ModuleFinderTest.java ! test/tools/javac/modules/ModulePathTest.java ! test/tools/javac/modules/ModulesAndClassPathTest.java ! test/tools/javac/modules/OutputDirTest.java ! test/tools/javac/modules/PackageMultipleModules.java ! test/tools/javac/modules/QueryBeforeEnter.java ! test/tools/javac/modules/RequiresPublicTest.java ! test/tools/javac/modules/ResolveTest.java ! test/tools/javac/modules/SubpackageTest.java ! test/tools/javac/modules/T8133058/NPEEmptyFileTest.java ! test/tools/javac/modules/T8149033/ServiceInStaticClassErrorTest.java ! test/tools/javac/modules/UsesTest.java ! test/tools/javac/platform/PlatformProviderTest.java ! test/tools/javac/plugin/showtype/Test.java ! test/tools/javac/processing/rounds/CompleteOnClosed.java ! test/tools/javac/processing/rounds/OverwriteBetweenCompilations.java ! test/tools/javac/sym/ElementStructureTest.java ! test/tools/javac/tree/8067914/NukeExtraCast.java ! test/tools/javadoc/CompletionError.java ! test/tools/javah/6257087/T6257087.java ! test/tools/javah/ModuleClass.java ! test/tools/javah/T4942232/MissingParamClassTest.java ! test/tools/sjavac/ApiExtraction.java ! test/tools/sjavac/ClasspathDependencies.java ! test/tools/sjavac/CompileCircularSources.java ! test/tools/sjavac/CompileExcludingDependency.java ! test/tools/sjavac/CompileWithAtFile.java ! test/tools/sjavac/CompileWithInvisibleSources.java ! test/tools/sjavac/CompileWithOverrideSources.java ! test/tools/sjavac/HiddenFiles.java ! test/tools/sjavac/IncCompInheritance.java ! test/tools/sjavac/IncCompileChangeNative.java ! test/tools/sjavac/IncCompileDropClasses.java ! test/tools/sjavac/IncCompileFullyQualifiedRef.java ! test/tools/sjavac/IncCompileNoChanges.java ! test/tools/sjavac/IncCompileUpdateNative.java ! test/tools/sjavac/IncCompileWithChanges.java ! test/tools/sjavac/IncludeExcludePatterns.java ! test/tools/sjavac/NoState.java ! test/tools/sjavac/PackagePathMismatch.java ! test/tools/sjavac/ParallelCompilations.java ! test/tools/sjavac/PermittedArtifact.java ! test/tools/sjavac/StateDir.java From jan.lahoda at oracle.com Wed Mar 9 14:41:57 2016 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Wed, 09 Mar 2016 14:41:57 +0000 Subject: hg: jigsaw/jake/langtools: Reflecting feedback by mcimadamore; cleanup. Message-ID: <201603091441.u29EfvXZ027904@aojmv0008.oracle.com> Changeset: 5f23a3827660 Author: jlahoda Date: 2016-03-09 15:41 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/5f23a3827660 Reflecting feedback by mcimadamore; cleanup. ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/ClassFinder.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java From chris.hegarty at oracle.com Wed Mar 9 16:15:50 2016 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 09 Mar 2016 16:15:50 +0000 Subject: hg: jigsaw/jake/jdk: 3 new changesets Message-ID: <201603091615.u29GFoF8020113@aojmv0008.oracle.com> Changeset: c90e14742584 Author: chegar Date: 2016-03-09 12:06 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c90e14742584 jartool: Update pack200 long option name and make hidden ! src/jdk.jartool/share/classes/sun/tools/jar/GNUStyleOptions.java ! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties Changeset: 8e847b622dea Author: chegar Date: 2016-03-09 13:27 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8e847b622dea jartool: help indentation and formatting ! src/jdk.jartool/share/classes/sun/tools/jar/GNUStyleOptions.java ! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties Changeset: 1f891b199068 Author: chegar Date: 2016-03-09 15:07 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1f891b199068 jar.tool: separate out compatibility help ! src/jdk.jartool/share/classes/sun/tools/jar/GNUStyleOptions.java ! src/jdk.jartool/share/classes/sun/tools/jar/Main.java ! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties ! test/tools/jar/compat/CLICompatibility.java From alan.bateman at oracle.com Wed Mar 9 16:29:45 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 09 Mar 2016 16:29:45 +0000 Subject: hg: jigsaw/jake/langtools: 2 new changesets Message-ID: <201603091629.u29GTjWL026944@aojmv0008.oracle.com> Changeset: 2af9b0e73969 Author: alanb Date: 2016-03-09 12:17 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/2af9b0e73969 ModuleFinder.concat -> compose, part 1 ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModulePaths.java Changeset: 3760fc80b3b0 Author: alanb Date: 2016-03-09 16:27 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/3760fc80b3b0 Merge From alan.bateman at oracle.com Wed Mar 9 16:29:50 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 09 Mar 2016 16:29:50 +0000 Subject: hg: jigsaw/jake/jdk: 4 new changesets Message-ID: <201603091629.u29GTonT027006@aojmv0008.oracle.com> Changeset: d6f1a109cab2 Author: alanb Date: 2016-03-09 12:06 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d6f1a109cab2 Extend checks to ensure that provider implementation is local ! src/java.base/share/classes/java/lang/module/Configuration.java ! src/java.base/share/classes/java/lang/module/Resolver.java ! test/jdk/jigsaw/module/ConfigurationTest.java Changeset: 6190b52ada26 Author: alanb Date: 2016-03-09 12:17 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6190b52ada26 ModuleFinder.concat -> compose, part 1 ! src/java.base/share/classes/java/lang/module/ModuleFinder.java ! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java ! src/jdk.jartool/share/classes/sun/tools/jar/GNUStyleOptions.java ! test/jdk/jigsaw/module/AutomaticModulesTest.java ! test/jdk/jigsaw/module/ModuleFinderTest.java Changeset: c64eb9463ac6 Author: alanb Date: 2016-03-09 15:44 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c64eb9463ac6 fixed javadoc comment ! src/java.base/share/classes/java/lang/module/Resolver.java Changeset: 606674ad339d Author: alanb Date: 2016-03-09 16:26 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/606674ad339d Merge ! src/jdk.jartool/share/classes/sun/tools/jar/GNUStyleOptions.java From pbenedict at apache.org Wed Mar 9 17:22:24 2016 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 9 Mar 2016 11:22:24 -0600 Subject: modulepath and classpath mixture Message-ID: I have an idea: What if the jar tool in JDK 9 was upgraded so that the Manifest had a new entry that contained the module name? This would allow access to it without requiring new API, and tools running JDK 8 or below would have an easy way to detect if the JAR is a module. And is there a secondary benefit to decoupling the module name and the module configuration? I'd like to hear another use case, if one exists. On 08/03/2016 20:06, Paul Benedict wrote: > >* Robert, it's sounds like a chicken-and-egg problem. You need the module > *>* name to compile but don't know it until you have compiled. > *>I think the scenario is where the module has been compiled and the issue > is the separate compilation of the tests "as if" they are in the module. > > -Alan > > Cheers, Paul From mandy.chung at oracle.com Wed Mar 9 18:01:02 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 9 Mar 2016 10:01:02 -0800 Subject: Need help testing the EA builds In-Reply-To: <56DFEF54.8050605@oracle.com> References: <56D7002A.9000509@oracle.com> <56DD4C00.7010908@oracle.com> <56DD6364.4060101@oracle.com> <56DD898F.4050505@oracle.com> <56DDDD49.5020309@oracle.com> <56DEDCED.5040007@oracle.com> <1B1397D4-E28C-49E7-9660-63000E3786A4@oracle.com> <56DFEF54.8050605@oracle.com> Message-ID: <3F395C21-20BC-4A8A-9B6C-77D866973398@oracle.com> > On Mar 9, 2016, at 1:39 AM, Alan Bateman wrote: > > > > On 08/03/2016 23:00, Mandy Chung wrote: >>> On Mar 8, 2016, at 6:08 AM, Alan Bateman wrote: >>> >>> In order, then my preferences for resolving this are: >>> >>> 1. Compete the tool separation, meaning JDK-8059035. >>> >>> 2. Change these tools to use services so that the SA backend is a service provider. >>> >> #2 seems to be trivial and I quickly hack up a patch: >> http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/8059035/webrev.00/ >> > Thanks for jumping on this, it looks good and very simple as you say. > > One thing that might need changes is the location of the tool provider, it's currently sun.tools.providers and that seems too general. Shoudl we put this to a spi package under jdk.internal for now? I didn?t like the package name either but just get something to work. what about sun.tools.vm.spi? jdk.internal.vm.agent.spi (instead of jdk.internal.vm.spi which seems to be a generic VM SPI rather than specific to tools?) Mandy From pbenedict at apache.org Wed Mar 9 18:36:48 2016 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 9 Mar 2016 12:36:48 -0600 Subject: Unnamed module and duplicate package Message-ID: >From the doc: "If a package is defined in both a named module and the unnamed module then the package in the unnamed module is ignored. This preserves reliable configuration even in the face of the chaos of the class path, ensuring that every module still reads at most one module defining a given package. If, in our example above, a JAR file on the class path contains a class file named com/foo/bar/alpha/AlphaFactory.class then that file will never be loaded, since the com.foo.bar.alpha package is exported by the com.foo.bar module." I would like some clarification. Correct me if wrong, but I think this entire paragraph is really meant to be about the perspective from a modularized JAR? If a module has package A, and the unnamed module has package A, then of course the module's package A should win. However, if it is meant to be absolute language, then I disagree. The unnamed module should be coherent among itself. If the unnamed module has package B and relies on classes from package A, it should still be able to see its own package A. I don't think modules should be able to impact how the unnamed module sees itself. That's a surprising situation. Cheers, Paul From pbenedict at apache.org Wed Mar 9 18:53:01 2016 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 9 Mar 2016 12:53:01 -0600 Subject: Automatic module names Message-ID: SOTMS: "We can, instead, treat org-baz-qux.jar as an *automatic module* by placing it, unmodified, on the module path rather than the class path. This will define an observable module whose name, org.baz.qux, is derived from that of the JAR file so that other, non-automatic modules can depend upon it in the usual way" I think more detail is necessary here. JARs stored in Maven, for example, are not fully qualified. It's just a simple JAR name and version numbers are typically included. So if commons-collections-4.0.0.jar is dropped into the module path, is the module name "commons.collections.4.0.0"? PS: Please see my previous email where I propose the idea that the manifest define the module name. This will allow jars to name themselves (i.e., their own module names) in a cross-compatible JDK way when dropped into the module path; ignored when on the classpath. I believe that's a better solution than using the file name as the module name. Cheers, Paul From Alan.Bateman at oracle.com Wed Mar 9 19:09:30 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 9 Mar 2016 19:09:30 +0000 Subject: Automatic module names In-Reply-To: References: Message-ID: <56E074EA.8040906@oracle.com> On 09/03/2016 18:53, Paul Benedict wrote: > : > > So if commons-collections-4.0.0.jar is dropped into the module path, is the > module name "commons.collections.4.0.0"? > > Can you try `java -modulepath commons-collections-4.0.0.jar -listmods` to see the module name that is listed? See also the javadoc for ModuleFinder.of [1] as that specifies how module names are derived. -Alan [1] http://download.java.net/java/jigsaw/docs/api/java/lang/module/ModuleFinder.html#of-java.nio.file.Path...- From Alan.Bateman at oracle.com Wed Mar 9 19:13:57 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 9 Mar 2016 19:13:57 +0000 Subject: Need help testing the EA builds In-Reply-To: <3F395C21-20BC-4A8A-9B6C-77D866973398@oracle.com> References: <56D7002A.9000509@oracle.com> <56DD4C00.7010908@oracle.com> <56DD6364.4060101@oracle.com> <56DD898F.4050505@oracle.com> <56DDDD49.5020309@oracle.com> <56DEDCED.5040007@oracle.com> <1B1397D4-E28C-49E7-9660-63000E3786A4@oracle.com> <56DFEF54.8050605@oracle.com> <3F395C21-20BC-4A8A-9B6C-77D866973398@oracle.com> Message-ID: <56E075F5.2050808@oracle.com> On 09/03/2016 18:01, Mandy Chung wrote: > what about sun.tools.vm.spi? jdk.internal.vm.agent.spi (instead of jdk.internal.vm.spi which seems to be a generic VM SPI rather than specific to tools?) As the tools are in sun.tools. and the SA tool classes are in sun.jvm.hotspot.tools then this name looks okay to me. -Alan From mandy.chung at oracle.com Wed Mar 9 19:32:30 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 9 Mar 2016 11:32:30 -0800 Subject: Need help testing the EA builds In-Reply-To: <56E075F5.2050808@oracle.com> References: <56D7002A.9000509@oracle.com> <56DD4C00.7010908@oracle.com> <56DD6364.4060101@oracle.com> <56DD898F.4050505@oracle.com> <56DDDD49.5020309@oracle.com> <56DEDCED.5040007@oracle.com> <1B1397D4-E28C-49E7-9660-63000E3786A4@oracle.com> <56DFEF54.8050605@oracle.com> <3F395C21-20BC-4A8A-9B6C-77D866973398@oracle.com> <56E075F5.2050808@oracle.com> Message-ID: > On Mar 9, 2016, at 11:13 AM, Alan Bateman wrote: > > > > On 09/03/2016 18:01, Mandy Chung wrote: >> what about sun.tools.vm.spi? jdk.internal.vm.agent.spi (instead of jdk.internal.vm.spi which seems to be a generic VM SPI rather than specific to tools?) > As the tools are in sun.tools. and the SA tool classes are in sun.jvm.hotspot.tools then this name looks okay to me. I actually changed it to jdk.internal.vm.agent.spi as they are declared in module-info.java and I slightly prefer jdk.internal prefix. http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/8059035/webrev.01/index.html Dmitry and Alexander Kulyakhtin have verifed the change. > Volker Simonis wrote: > > thanks a lot for your patch. I've just verified that it works > perfectly on AIX and also did some smoke test on Linux (i.e. jstack) > which confirm that the original functionality is still preserved. This > is not a complete review because I'm not a serviceability expert but > with regard to fixing the dependencies on the SA agent in the build > I'm completely happy with your change. Volker - thanks for test build and sanity test it. Mandy From mark.reinhold at oracle.com Wed Mar 9 20:05:14 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 09 Mar 2016 12:05:14 -0800 Subject: Automatic module names In-Reply-To: References: Message-ID: <20160309120514.978081958eggemoggin.niobe.net> 2016/3/9 10:53 -0800, pbenedict at apache.org: > SOTMS: > "We can, instead, treat org-baz-qux.jar as an *automatic module* by placing > it, unmodified, on the module path rather than the class path. This will > define an observable module whose name, org.baz.qux, is derived from that > of the JAR file so that other, non-automatic modules can depend upon it in > the usual way" > > I think more detail is necessary here. JARs stored in Maven, for example, > are not fully qualified. It's just a simple JAR name and version numbers > are typically included. > > So if commons-collections-4.0.0.jar is dropped into the module path, is the > module name "commons.collections.4.0.0"? No, the name is "commons.collections", and the version string is "4.0.0". > PS: Please see my previous email where I propose the idea that the manifest > define the module name. This will allow jars to name themselves (i.e., > their own module names) in a cross-compatible JDK way when dropped into the > module path; ignored when on the classpath. I believe that's a better > solution than using the file name as the module name. That could work for new JARs but it won't work for all the JARs present on Maven Central today, and that's kind of the whole point of automatic modules. If you're willing and able to modify a JAR file then you might as well make it into a true module. - Mark From harold.seigel at oracle.com Wed Mar 9 20:13:02 2016 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Wed, 09 Mar 2016 20:13:02 +0000 Subject: hg: jigsaw/jake/hotspot: Added missing ResourceMark in MetaspaceShared::check_shared_class_loader_type. Message-ID: <201603092013.u29KD2Gb008231@aojmv0008.oracle.com> Changeset: 1e4ed69f0803 Author: ccheung Date: 2016-03-09 11:00 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1e4ed69f0803 Added missing ResourceMark in MetaspaceShared::check_shared_class_loader_type. Reviewed-by: coleenp ! src/share/vm/memory/metaspaceShared.cpp From sander.mak at luminis.eu Wed Mar 9 20:14:15 2016 From: sander.mak at luminis.eu (Sander Mak) Date: Wed, 9 Mar 2016 20:14:15 +0000 Subject: Automatic module names In-Reply-To: References: Message-ID: > So if commons-collections-4.0.0.jar is dropped into the module path, is the > module name "commons.collections.4.0.0"? I was wondering about this as well, played around a bit with this yesterday: - hamcrest-core -> hamcrest.core - hamcrest-^-core -> hamcrest.core - hamcrest-core-1.0 -> hamcrest.core - hamcrest-core-1.0a.b -> hamcrest.core - hamcrest-1.2a-core -> couldn't figure out what name it is mangled into - hamcrest-core-1.0 & hamcrest-core-1.1 on module path -> duplicate module error Not going to speculate on the actual algorithm... -- Sander From sander.mak at luminis.eu Wed Mar 9 20:15:30 2016 From: sander.mak at luminis.eu (Sander Mak) Date: Wed, 9 Mar 2016 20:15:30 +0000 Subject: Automatic module names In-Reply-To: <56E074EA.8040906@oracle.com> References: <56E074EA.8040906@oracle.com> Message-ID: > Can you try `java -modulepath commons-collections-4.0.0.jar -listmods` to see the module name that is listed? > > See also the javadoc for ModuleFinder.of [1] as that specifies how module names are derived. ... and fortunately I don't need to speculate because it's spelled out here, nice! -- Sander From alex.buckley at oracle.com Wed Mar 9 20:38:59 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 09 Mar 2016 12:38:59 -0800 Subject: Unnamed module and duplicate package In-Reply-To: References: Message-ID: <56E089E3.8040204@oracle.com> On 3/9/2016 10:36 AM, Paul Benedict wrote: > From the doc: > "If a package is defined in both a named module and the unnamed module then > the package in the unnamed module is ignored. This preserves reliable > configuration even in the face of the chaos of the class path, ensuring > that every module still reads at most one module defining a given package. > If, in our example above, a JAR file on the class path contains a class > file named com/foo/bar/alpha/AlphaFactory.class then that file will never > be loaded, since the com.foo.bar.alpha package is exported by the > com.foo.bar module." > > I would like some clarification. Correct me if wrong, but I think this > entire paragraph is really meant to be about the perspective from a > modularized JAR? If a module has package A, and the unnamed module has > package A, then of course the module's package A should win. > > However, if it is meant to be absolute language, then I disagree. > > The unnamed module should be coherent among itself. If the unnamed module > has package B and relies on classes from package A, it should still be able > to see its own package A. I don't think modules should be able to impact > how the unnamed module sees itself. That's a surprising situation. The unnamed module is not a root module during resolution. If your main class is in the unnamed module (i.e. you did java -jar MyApp.jar rather than java -m MyApp), then the module graph is created by resolving various root modules (what are they? separate discussion) and only then is the unnamed module hooked up to read every module in the graph. Hope we're OK so far. If some named module in the graph exports package A (more than one module exporting A? separate discussion), then since the unnamed module reads that named module, the unnamed module will access A.* types from that named module. It's hard to imagine the unnamed module NOT accessing A.* types from that named module. Primarily, we need to avoid a split package situation where code in the unnamed module sometimes accesses A.* types from the named module and sometimes from the unnamed module. You might say, OK, let code in the unnamed module exclusively access A.* in the unnamed module rather than exclusively access A.* in the named module. Then you have two problems: 1. There are issues for named modules in the same class loader as the unnamed module -- such named modules MUST get A.* from the named module rather than the unnamed module, and the class loading mechanism is incapable of switching based on accessor. It'll be common for named modules to exist in the same class loader as the unnamed module, as modular JARs on the modulepath and non-modular JARs on the classpath all end up in the application class loader (modular JARs as named modules; non-modular JARs jointly as the unnamed module). 2. While the module system is sure that package A exists in the named module, how would the module system possibly know that package A exists in the unnamed module? Scanning every class file in every non-modular JAR on the classpath at startup sounds bad. Alex From pbenedict at apache.org Wed Mar 9 21:17:01 2016 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 9 Mar 2016 15:17:01 -0600 Subject: Unnamed module and duplicate package In-Reply-To: <56E089E3.8040204@oracle.com> References: <56E089E3.8040204@oracle.com> Message-ID: But isn't what your proposing a security issue? Let's say my package A is in the unnamed module and your package A is in a named module. You basically took over my code; your classes will be substituted for mine. Cheers, Paul On Wed, Mar 9, 2016 at 2:38 PM, Alex Buckley wrote: > On 3/9/2016 10:36 AM, Paul Benedict wrote: > >> From the doc: >> "If a package is defined in both a named module and the unnamed module >> then >> the package in the unnamed module is ignored. This preserves reliable >> configuration even in the face of the chaos of the class path, ensuring >> that every module still reads at most one module defining a given package. >> If, in our example above, a JAR file on the class path contains a class >> file named com/foo/bar/alpha/AlphaFactory.class then that file will never >> be loaded, since the com.foo.bar.alpha package is exported by the >> com.foo.bar module." >> >> I would like some clarification. Correct me if wrong, but I think this >> entire paragraph is really meant to be about the perspective from a >> modularized JAR? If a module has package A, and the unnamed module has >> package A, then of course the module's package A should win. >> >> However, if it is meant to be absolute language, then I disagree. >> >> The unnamed module should be coherent among itself. If the unnamed module >> has package B and relies on classes from package A, it should still be >> able >> to see its own package A. I don't think modules should be able to impact >> how the unnamed module sees itself. That's a surprising situation. >> > > The unnamed module is not a root module during resolution. If your main > class is in the unnamed module (i.e. you did java -jar MyApp.jar rather > than java -m MyApp), then the module graph is created by resolving various > root modules (what are they? separate discussion) and only then is the > unnamed module hooked up to read every module in the graph. > > Hope we're OK so far. > > If some named module in the graph exports package A (more than one module > exporting A? separate discussion), then since the unnamed module reads that > named module, the unnamed module will access A.* types from that named > module. > > It's hard to imagine the unnamed module NOT accessing A.* types from that > named module. Primarily, we need to avoid a split package situation where > code in the unnamed module sometimes accesses A.* types from the named > module and sometimes from the unnamed module. > > You might say, OK, let code in the unnamed module exclusively access A.* > in the unnamed module rather than exclusively access A.* in the named > module. Then you have two problems: > > 1. There are issues for named modules in the same class loader as the > unnamed module -- such named modules MUST get A.* from the named module > rather than the unnamed module, and the class loading mechanism is > incapable of switching based on accessor. It'll be common for named modules > to exist in the same class loader as the unnamed module, as modular JARs on > the modulepath and non-modular JARs on the classpath all end up in the > application class loader (modular JARs as named modules; non-modular JARs > jointly as the unnamed module). > > 2. While the module system is sure that package A exists in the named > module, how would the module system possibly know that package A exists in > the unnamed module? Scanning every class file in every non-modular JAR on > the classpath at startup sounds bad. > > Alex > From harold.seigel at oracle.com Wed Mar 9 21:22:31 2016 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Wed, 09 Mar 2016 21:22:31 +0000 Subject: hg: jigsaw/jake/jdk: Check for package names of "" to prevent anonymous class names that start with '/'. Message-ID: <201603092122.u29LMWdf011033@aojmv0008.oracle.com> Changeset: d7102ae141b1 Author: hseigel Date: 2016-03-09 15:55 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d7102ae141b1 Check for package names of "" to prevent anonymous class names that start with '/'. Reviewed by: alanb, shade ! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java From mandy.chung at oracle.com Wed Mar 9 21:24:40 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 09 Mar 2016 21:24:40 +0000 Subject: hg: jigsaw/jake/hotspot: Eliminate jdk.jcmd dependency on jdk.hotspot.agent by converting to service interface Message-ID: <201603092124.u29LOemm012237@aojmv0008.oracle.com> Changeset: f2d8674642fe Author: mchung Date: 2016-03-09 13:24 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f2d8674642fe Eliminate jdk.jcmd dependency on jdk.hotspot.agent by converting to service interface ! src/jdk.hotspot.agent/share/classes/module-info.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/ClassLoaderStats.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/FinalizerInfo.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/HeapDumper.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/JInfo.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/JStack.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/ObjectHistogram.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/PMap.java From mandy.chung at oracle.com Wed Mar 9 21:24:47 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 09 Mar 2016 21:24:47 +0000 Subject: hg: jigsaw/jake/jdk: Eliminate jdk.jcmd dependency on jdk.hotspot.agent by converting to service interface Message-ID: <201603092124.u29LOlSk012343@aojmv0008.oracle.com> Changeset: 0080ef862071 Author: mchung Date: 2016-03-09 13:24 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0080ef862071 Eliminate jdk.jcmd dependency on jdk.hotspot.agent by converting to service interface + src/jdk.jcmd/share/classes/jdk/internal/vm/agent/spi/ToolProvider.java + src/jdk.jcmd/share/classes/jdk/internal/vm/agent/spi/ToolProviderFinder.java ! src/jdk.jcmd/share/classes/module-info.java ! src/jdk.jcmd/share/classes/sun/tools/jinfo/JInfo.java ! src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java ! src/jdk.jcmd/share/classes/sun/tools/jstack/JStack.java From alex.buckley at oracle.com Wed Mar 9 21:37:57 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 09 Mar 2016 13:37:57 -0800 Subject: Unnamed module and duplicate package In-Reply-To: References: <56E089E3.8040204@oracle.com> Message-ID: <56E097B5.9040201@oracle.com> Presumably you would count the equivalent scenario on JDK 8 -- my package A is in Alex.jar on the classpath and your package A is in Paul.jar on the classpath -- as a security issue too, because some of my classes may substitute for yours (or some of yours for mine, depending on how the classpath is constructed). On JDK 9, we do the "substitution" cleanly. Package A is not split. That avoids one category of error (ClassCastException). What about poor package B that finds itself accessing a different package A than it was compiled with? Well, since package A is exported by a named module, it's reasonable to assume that the named module "owns" package A [*], and that the developer of package B co-bundled some version of package A without renaming it. Dangerous in JDK 8, dangerous in JDK 9. (We're trying to encapsulate the internals of a module, which is different from trying to isolate modules from each other.) [*] Advanced scenario: the named module exporting A is actually an automatic module which happened to co-bundle package A. By placing this JAR on the modulepath to form an automatic module, it dominates the JAR left on the classpath which also co-bundled package A. Alex On 3/9/2016 1:17 PM, Paul Benedict wrote: > But isn't what your proposing a security issue? Let's say my package A > is in the unnamed module and your package A is in a named module. You > basically took over my code; your classes will be substituted for mine. > > Cheers, > Paul > > On Wed, Mar 9, 2016 at 2:38 PM, Alex Buckley > wrote: > > On 3/9/2016 10:36 AM, Paul Benedict wrote: > > From the doc: > "If a package is defined in both a named module and the unnamed > module then > the package in the unnamed module is ignored. This preserves > reliable > configuration even in the face of the chaos of the class path, > ensuring > that every module still reads at most one module defining a > given package. > If, in our example above, a JAR file on the class path contains > a class > file named com/foo/bar/alpha/AlphaFactory.class then that file > will never > be loaded, since the com.foo.bar.alpha package is exported by the > com.foo.bar module." > > I would like some clarification. Correct me if wrong, but I > think this > entire paragraph is really meant to be about the perspective from a > modularized JAR? If a module has package A, and the unnamed > module has > package A, then of course the module's package A should win. > > However, if it is meant to be absolute language, then I disagree. > > The unnamed module should be coherent among itself. If the > unnamed module > has package B and relies on classes from package A, it should > still be able > to see its own package A. I don't think modules should be able > to impact > how the unnamed module sees itself. That's a surprising situation. > > > The unnamed module is not a root module during resolution. If your > main class is in the unnamed module (i.e. you did java -jar > MyApp.jar rather than java -m MyApp), then the module graph is > created by resolving various root modules (what are they? separate > discussion) and only then is the unnamed module hooked up to read > every module in the graph. > > Hope we're OK so far. > > If some named module in the graph exports package A (more than one > module exporting A? separate discussion), then since the unnamed > module reads that named module, the unnamed module will access A.* > types from that named module. > > It's hard to imagine the unnamed module NOT accessing A.* types from > that named module. Primarily, we need to avoid a split package > situation where code in the unnamed module sometimes accesses A.* > types from the named module and sometimes from the unnamed module. > > You might say, OK, let code in the unnamed module exclusively access > A.* in the unnamed module rather than exclusively access A.* in the > named module. Then you have two problems: > > 1. There are issues for named modules in the same class loader as > the unnamed module -- such named modules MUST get A.* from the named > module rather than the unnamed module, and the class loading > mechanism is incapable of switching based on accessor. It'll be > common for named modules to exist in the same class loader as the > unnamed module, as modular JARs on the modulepath and non-modular > JARs on the classpath all end up in the application class loader > (modular JARs as named modules; non-modular JARs jointly as the > unnamed module). > > 2. While the module system is sure that package A exists in the > named module, how would the module system possibly know that package > A exists in the unnamed module? Scanning every class file in every > non-modular JAR on the classpath at startup sounds bad. > > Alex > > From pbenedict at apache.org Wed Mar 9 21:47:24 2016 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 9 Mar 2016 15:47:24 -0600 Subject: Unnamed module and duplicate package In-Reply-To: <56E097B5.9040201@oracle.com> References: <56E089E3.8040204@oracle.com> <56E097B5.9040201@oracle.com> Message-ID: Thank you Alex. Since it's roughly the same as JDK 8, then it's also not worse. I defer to your explanation on that point. Cheers, Paul On Wed, Mar 9, 2016 at 3:37 PM, Alex Buckley wrote: > Presumably you would count the equivalent scenario on JDK 8 -- my package > A is in Alex.jar on the classpath and your package A is in Paul.jar on the > classpath -- as a security issue too, because some of my classes may > substitute for yours (or some of yours for mine, depending on how the > classpath is constructed). > > On JDK 9, we do the "substitution" cleanly. Package A is not split. That > avoids one category of error (ClassCastException). What about poor package > B that finds itself accessing a different package A than it was compiled > with? Well, since package A is exported by a named module, it's reasonable > to assume that the named module "owns" package A [*], and that the > developer of package B co-bundled some version of package A without > renaming it. Dangerous in JDK 8, dangerous in JDK 9. (We're trying to > encapsulate the internals of a module, which is different from trying to > isolate modules from each other.) > > [*] Advanced scenario: the named module exporting A is actually an > automatic module which happened to co-bundle package A. By placing this JAR > on the modulepath to form an automatic module, it dominates the JAR left on > the classpath which also co-bundled package A. > > Alex > > On 3/9/2016 1:17 PM, Paul Benedict wrote: > >> But isn't what your proposing a security issue? Let's say my package A >> is in the unnamed module and your package A is in a named module. You >> basically took over my code; your classes will be substituted for mine. >> >> Cheers, >> Paul >> >> On Wed, Mar 9, 2016 at 2:38 PM, Alex Buckley > > wrote: >> >> On 3/9/2016 10:36 AM, Paul Benedict wrote: >> >> From the doc: >> "If a package is defined in both a named module and the unnamed >> module then >> the package in the unnamed module is ignored. This preserves >> reliable >> configuration even in the face of the chaos of the class path, >> ensuring >> that every module still reads at most one module defining a >> given package. >> If, in our example above, a JAR file on the class path contains >> a class >> file named com/foo/bar/alpha/AlphaFactory.class then that file >> will never >> be loaded, since the com.foo.bar.alpha package is exported by the >> com.foo.bar module." >> >> I would like some clarification. Correct me if wrong, but I >> think this >> entire paragraph is really meant to be about the perspective from >> a >> modularized JAR? If a module has package A, and the unnamed >> module has >> package A, then of course the module's package A should win. >> >> However, if it is meant to be absolute language, then I disagree. >> >> The unnamed module should be coherent among itself. If the >> unnamed module >> has package B and relies on classes from package A, it should >> still be able >> to see its own package A. I don't think modules should be able >> to impact >> how the unnamed module sees itself. That's a surprising situation. >> >> >> The unnamed module is not a root module during resolution. If your >> main class is in the unnamed module (i.e. you did java -jar >> MyApp.jar rather than java -m MyApp), then the module graph is >> created by resolving various root modules (what are they? separate >> discussion) and only then is the unnamed module hooked up to read >> every module in the graph. >> >> Hope we're OK so far. >> >> If some named module in the graph exports package A (more than one >> module exporting A? separate discussion), then since the unnamed >> module reads that named module, the unnamed module will access A.* >> types from that named module. >> >> It's hard to imagine the unnamed module NOT accessing A.* types from >> that named module. Primarily, we need to avoid a split package >> situation where code in the unnamed module sometimes accesses A.* >> types from the named module and sometimes from the unnamed module. >> >> You might say, OK, let code in the unnamed module exclusively access >> A.* in the unnamed module rather than exclusively access A.* in the >> named module. Then you have two problems: >> >> 1. There are issues for named modules in the same class loader as >> the unnamed module -- such named modules MUST get A.* from the named >> module rather than the unnamed module, and the class loading >> mechanism is incapable of switching based on accessor. It'll be >> common for named modules to exist in the same class loader as the >> unnamed module, as modular JARs on the modulepath and non-modular >> JARs on the classpath all end up in the application class loader >> (modular JARs as named modules; non-modular JARs jointly as the >> unnamed module). >> >> 2. While the module system is sure that package A exists in the >> named module, how would the module system possibly know that package >> A exists in the unnamed module? Scanning every class file in every >> non-modular JAR on the classpath at startup sounds bad. >> >> Alex >> >> >> From alex.buckley at oracle.com Wed Mar 9 22:02:10 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 09 Mar 2016 14:02:10 -0800 Subject: Package, import and type declarations are allowed now in module-info.java by spec In-Reply-To: <56E021CE.3050801@oracle.com> References: <56D07F37.1030806@oracle.com> <56D098BB.5070200@oracle.com> <56E021CE.3050801@oracle.com> Message-ID: <56E09D62.3060507@oracle.com> The JLS doesn't prevent javac from rejecting a package declaration or an import declaration in a file called module-info.java. In fact, since a package declaration or import declaration must be followed by a type declaration, and since a type declaration cannot use a hyphen, javac is free to take the optional rule from JLS 7.6 -- filename must align with type declaration -- and develop it further: rejecting a package declaration or import declaration in module-info.java because the filename cannot possibly align with any type declaration. I can't speak to what a particular EA build of javac is doing with a particular option. javac options are irrelevant to the JLS. If a compiler accepts the Java language circa SE 9, then a module declaration is a valid compilation unit. What's the name of the file containing such a compilation unit? Anything the compiler likes. Alex On 3/9/2016 5:14 AM, Georgiy Rakov wrote: > Hi Alex, > > if I understand correctly you mean about following assertions from JLS 7.6: > > If and only if packages are stored in a file system (?7.2 > ), > the host system may choose to enforce the restriction that it is a > compile-time error if a type is not found in a file under a name > composed of the type name plus an extension (such as |.java|or > |.jav|) if either of the following is true: > > * > > The type is referred to by code in other compilation units of > the package in which the type is declared. > > * > > The type is declared |public|(and therefore is potentially > accessible from code in other packages). > > Literally these assertion doesn't make presented behavior corresponding > to spec because the declared type is neither public nor being referred > to from other sources being compiled. > > Nevertheless following sources doesn't compile either despite the fact > that no types are declared there at all. > Namely when only package is specified: > > mod\module-info.java: > module mod { > exports pkg; > } > > mod\pkg\module-info.java: > package pkg; > > then compiling it by following command line with javac from [2]: > > javac -modulesourcepath . mod\module-info.java mod\pkg\module-info.java > > causes following output: > > mod\pkg\module-info.java:1: error: expected 'module > package pkg; > ^ > 1 error > > When only import statment is specified: > > mod\module-info.java: > module mod { > exports pkg; > } > > mod\pkg\module-info.java: > import java.util.List; > > then compiling it by following command line with javac from [2]: > > javac -modulesourcepath . mod\module-info.java mod\pkg\module-info.java > > causes following output: > > mod\pkg\module-info.java:1: error: expected 'module' > import java.util.List; > ^ > 1 error > > Please see minimized test cases attached in tests23.zip. In order to > reproduce, please: > > 1. Unzip the attached archive to some dir on Windows machined, say > directory A; > 2. Rename A\test2\test_bat to A\test2\test.bat and A\test3\test_bat to > A\test3\test.bat; > 3. Modify these two test.bat files by changing JDK_HOME variable to > point to your jigsaw JDK 9 installation directory; > 4. Run test.bat files in turn. > > BTW: javac behavior [2] currently differs depending on whether sources > are compiled "in module" mode or not. By "module mode" I mean specifying > modulesourcepath option. For instance without modulesourcepath option > module declarations are not recognized as valid grammar while import > declarations contained within module-info.java compile successfully. > This can be seen by experimenting with test3 from the attached > testcases. Now javac from [2] even can throw exception in "non-module" > mode, please see https://bugs.openjdk.java.net/browse/JDK-8150733. > > Could you please tell if spec will specify somehow two modes of > processing java-sources, now it [1] doesn't. > > [1] http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html > [2] > http://download.java.net/java/jigsaw/archive/106/binaries/jigsaw-jdk-9-ea+106_windows-x86_bin.zip > > Thanks, > Georgiy. > > On 26.02.2016 21:26, Alex Buckley wrote: >> On 2/26/2016 8:37 AM, Georgiy Rakov wrote: >>> current spec [1] now contains following assertions related to grammar: >>> >>> A compilation unit (JLS 7.3) may contain a module declaration, in >>> which case the filename of the compilation unit is typically >>> |module-info.java|. >>> >>> CompilationUnit: >>> [PackageDeclaration] {ImportDeclaration} {TypeDeclaration} >>> ModuleDeclaration >>> >>> These assertions allows to specify any of import, package or type >>> declarations in any compilation unit, for instance module-info.java is >>> allowed to contain any of the mentioned declarations. However currently >>> javac in the latest jigsaw build [2] reports an error on such cases >>> provided they are compiled in module mode. For example if we have >>> following directory structure: >>> >>> mod\module-info.java: >>> module mod { >>> exports pkg; >>> } >>> >>> mod\pkg\module-info.java: >>> package pkg; >>> >>> class C { >>> } >>> >>> then compiling it by following command line with javac from [2]: >>> >>> javac -modulesourcepath . mod\module-info.java >>> mod\pkg\module-info.java >>> >>> causes following output: >>> >>> mod\pkg\module-info.java:1: error: expected 'module' >>> package pkg; >>> ^ >>> 1 error >> >> javac is merely choosing to implement the rule at the end of JLS 7.6 >> that a type declaration (optionally preceded by package/import >> declarations) must be provided in a suitably named file. >> >> Perhaps I should say "a variant of the rule" because 7.6 as written >> concerns a public type and your example has a package-access type. >> Still, bottom line, javac is free to require that a compilation unit >> which starts with a package declaration _must not_ be in a file called >> foo-bar.java -- the hyphen indicates a name that can't possibly align >> with the type declared in the compilation unit. >> >> The error message for mod\pkg\module-info.java could be a bit more >> helpful, but that's a quality-of-implementation detail. >> >> Conversely, a compilation unit that contains a module declaration >> _may_ be in a file called module-info.java, or in a file called >> foo-bar.java, or in a file called mod_decl.JAV. The "typically" in [1] >> is meant to indicate that the sub-clause on filename is non-normative. >> This is akin to how a compilation unit that contains a package-access >> type declaration for class C _may_ be in a file D.java. >> >> Alex > From pbenedict at apache.org Wed Mar 9 22:15:27 2016 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 9 Mar 2016 16:15:27 -0600 Subject: Automatic module names In-Reply-To: <56e08206.8896420a.2a052.442aSMTPIN_ADDED_BROKEN@mx.google.com> References: <56e08206.8896420a.2a052.442aSMTPIN_ADDED_BROKEN@mx.google.com> Message-ID: Mark, I don't think that is sufficient for everyone who must support older class formats. I can think of three intersecting requirements that an existing project might have: 1) Wants to assign an official module name when used in the modulepath (forward looking requirement) 2) Doesn't want to make JDK 9 a minimum version (thus no module-info.class) 3) Doesn't want to change the filename for historical purposes (especially in a Maven repo) Specifying the module name in the Manifest provides a suitable transition path here. It's a relatively easy win for a developer. I propose it for your consideration. Cheers, Paul On Wed, Mar 9, 2016 at 2:05 PM, wrote: > 2016/3/9 10:53 -0800, pbenedict at apache.org: > > SOTMS: > > "We can, instead, treat org-baz-qux.jar as an *automatic module* by > placing > > it, unmodified, on the module path rather than the class path. This will > > define an observable module whose name, org.baz.qux, is derived from that > > of the JAR file so that other, non-automatic modules can depend upon it > in > > the usual way" > > > > I think more detail is necessary here. JARs stored in Maven, for example, > > are not fully qualified. It's just a simple JAR name and version numbers > > are typically included. > > > > So if commons-collections-4.0.0.jar is dropped into the module path, is > the > > module name "commons.collections.4.0.0"? > > No, the name is "commons.collections", and the version string is "4.0.0". > > > PS: Please see my previous email where I propose the idea that the > manifest > > define the module name. This will allow jars to name themselves (i.e., > > their own module names) in a cross-compatible JDK way when dropped into > the > > module path; ignored when on the classpath. I believe that's a better > > solution than using the file name as the module name. > > That could work for new JARs but it won't work for all the JARs present > on Maven Central today, and that's kind of the whole point of automatic > modules. If you're willing and able to modify a JAR file then you might > as well make it into a true module. > > - Mark > From alex.buckley at oracle.com Wed Mar 9 23:13:20 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 09 Mar 2016 15:13:20 -0800 Subject: Unnamed module and duplicate package In-Reply-To: References: <56E089E3.8040204@oracle.com> <56E097B5.9040201@oracle.com> Message-ID: <56E0AE10.80300@oracle.com> Paul, thank you for asking. The module system's treatment of the unnamed module vis-a-vis named modules is probably the biggest factor affecting usability of the module system. This is true almost by definition because at JDK 9 GA the only named modules in the world will be the JDK's while every other class will be in the unnamed module of the application class loader. So please, ask more questions about the unnamed module. I am especially interested to know if anyone has JARs that contain javax packages (or heaven forbid, sun or com.sun packages) found in the JDK -- such JARs are a mortal danger to interop between unnamed and named modules. Alex On 3/9/2016 1:47 PM, Paul Benedict wrote: > Thank you Alex. Since it's roughly the same as JDK 8, then it's also not > worse. I defer to your explanation on that point. > > Cheers, > Paul > > On Wed, Mar 9, 2016 at 3:37 PM, Alex Buckley > wrote: > > Presumably you would count the equivalent scenario on JDK 8 -- my > package A is in Alex.jar on the classpath and your package A is in > Paul.jar on the classpath -- as a security issue too, because some > of my classes may substitute for yours (or some of yours for mine, > depending on how the classpath is constructed). > > On JDK 9, we do the "substitution" cleanly. Package A is not split. > That avoids one category of error (ClassCastException). What about > poor package B that finds itself accessing a different package A > than it was compiled with? Well, since package A is exported by a > named module, it's reasonable to assume that the named module "owns" > package A [*], and that the developer of package B co-bundled some > version of package A without renaming it. Dangerous in JDK 8, > dangerous in JDK 9. (We're trying to encapsulate the internals of a > module, which is different from trying to isolate modules from each > other.) > > [*] Advanced scenario: the named module exporting A is actually an > automatic module which happened to co-bundle package A. By placing > this JAR on the modulepath to form an automatic module, it dominates > the JAR left on the classpath which also co-bundled package A. > > Alex > > On 3/9/2016 1:17 PM, Paul Benedict wrote: > > But isn't what your proposing a security issue? Let's say my > package A > is in the unnamed module and your package A is in a named > module. You > basically took over my code; your classes will be substituted > for mine. > > Cheers, > Paul > > On Wed, Mar 9, 2016 at 2:38 PM, Alex Buckley > > >> wrote: > > On 3/9/2016 10:36 AM, Paul Benedict wrote: > > From the doc: > "If a package is defined in both a named module and the > unnamed > module then > the package in the unnamed module is ignored. This > preserves > reliable > configuration even in the face of the chaos of the > class path, > ensuring > that every module still reads at most one module defining a > given package. > If, in our example above, a JAR file on the class path > contains > a class > file named com/foo/bar/alpha/AlphaFactory.class then > that file > will never > be loaded, since the com.foo.bar.alpha package is > exported by the > com.foo.bar module." > > I would like some clarification. Correct me if wrong, but I > think this > entire paragraph is really meant to be about the > perspective from a > modularized JAR? If a module has package A, and the unnamed > module has > package A, then of course the module's package A should > win. > > However, if it is meant to be absolute language, then I > disagree. > > The unnamed module should be coherent among itself. If the > unnamed module > has package B and relies on classes from package A, it > should > still be able > to see its own package A. I don't think modules should > be able > to impact > how the unnamed module sees itself. That's a surprising > situation. > > > The unnamed module is not a root module during resolution. > If your > main class is in the unnamed module (i.e. you did java -jar > MyApp.jar rather than java -m MyApp), then the module graph is > created by resolving various root modules (what are they? > separate > discussion) and only then is the unnamed module hooked up > to read > every module in the graph. > > Hope we're OK so far. > > If some named module in the graph exports package A (more > than one > module exporting A? separate discussion), then since the > unnamed > module reads that named module, the unnamed module will > access A.* > types from that named module. > > It's hard to imagine the unnamed module NOT accessing A.* > types from > that named module. Primarily, we need to avoid a split package > situation where code in the unnamed module sometimes > accesses A.* > types from the named module and sometimes from the unnamed > module. > > You might say, OK, let code in the unnamed module > exclusively access > A.* in the unnamed module rather than exclusively access > A.* in the > named module. Then you have two problems: > > 1. There are issues for named modules in the same class > loader as > the unnamed module -- such named modules MUST get A.* from > the named > module rather than the unnamed module, and the class loading > mechanism is incapable of switching based on accessor. It'll be > common for named modules to exist in the same class loader > as the > unnamed module, as modular JARs on the modulepath and > non-modular > JARs on the classpath all end up in the application class > loader > (modular JARs as named modules; non-modular JARs jointly as the > unnamed module). > > 2. While the module system is sure that package A exists in the > named module, how would the module system possibly know > that package > A exists in the unnamed module? Scanning every class file > in every > non-modular JAR on the classpath at startup sounds bad. > > Alex > > > From mark.reinhold at oracle.com Wed Mar 9 23:31:19 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 09 Mar 2016 23:31:19 +0000 Subject: hg: jigsaw/jake: Add java.se.ee module Message-ID: <201603092331.u29NVKD0005084@aojmv0008.oracle.com> Changeset: 0a3fac7cfd07 Author: mr Date: 2016-03-09 15:24 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/0a3fac7cfd07 Add java.se.ee module ! make/Images.gmk ! make/Javadoc.gmk From mark.reinhold at oracle.com Wed Mar 9 23:31:36 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 09 Mar 2016 23:31:36 +0000 Subject: hg: jigsaw/jake/jdk: 2 new changesets Message-ID: <201603092331.u29NVauT005674@aojmv0008.oracle.com> Changeset: a5cd23aca348 Author: mr Date: 2016-03-09 15:24 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a5cd23aca348 Add java.se.ee module + src/java.se.ee/share/classes/module-info.java ! src/java.se/share/classes/module-info.java Changeset: 3b5b2437f9a9 Author: mr Date: 2016-03-09 15:24 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3b5b2437f9a9 GenGraphs tweaks Sort nodes and edges for consistent display For the whole JDK, treat the SE graph as a cluster so it's easy to see ! make/src/classes/build/tools/jigsaw/GenGraphs.java From mark.reinhold at oracle.com Wed Mar 9 23:31:40 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 09 Mar 2016 23:31:40 +0000 Subject: hg: jigsaw/jake/langtools: Add java.se.ee module Message-ID: <201603092331.u29NVeWw005931@aojmv0008.oracle.com> Changeset: a40aee7353b6 Author: mr Date: 2016-03-09 15:24 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/a40aee7353b6 Add java.se.ee module ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Profile.java From mandy.chung at oracle.com Wed Mar 9 23:58:42 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 09 Mar 2016 23:58:42 +0000 Subject: hg: jigsaw/jake/langtools: jdeps -check option to check module dependences and any unused qualified exports Message-ID: <201603092358.u29NwgcJ018321@aojmv0008.oracle.com> Changeset: a8cbb0d9aaa0 Author: mchung Date: 2016-03-09 15:58 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/a8cbb0d9aaa0 jdeps -check option to check module dependences and any unused qualified exports ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsTask.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps.properties From russell.gold at oracle.com Thu Mar 10 01:16:26 2016 From: russell.gold at oracle.com (Russell Gold) Date: Wed, 9 Mar 2016 20:16:26 -0500 Subject: Unnamed module and duplicate package In-Reply-To: <56E097B5.9040201@oracle.com> References: <56E089E3.8040204@oracle.com> <56E097B5.9040201@oracle.com> Message-ID: <3AD054BA-035F-44A6-9636-8238016E049F@oracle.com> Doesn?t this kind of error only happen when a second module exports the same _class_? What is the problem with another class being defined in the same package, given that package B isn?t going to access that new class at all? - Russ > On Mar 9, 2016, at 4:37 PM, Alex Buckley wrote: > > Presumably you would count the equivalent scenario on JDK 8 -- my package A is in Alex.jar on the classpath and your package A is in Paul.jar on the classpath -- as a security issue too, because some of my classes may substitute for yours (or some of yours for mine, depending on how the classpath is constructed). > > On JDK 9, we do the "substitution" cleanly. Package A is not split. That avoids one category of error (ClassCastException). What about poor package B that finds itself accessing a different package A than it was compiled with? Well, since package A is exported by a named module, it's reasonable to assume that the named module "owns" package A [*], and that the developer of package B co-bundled some version of package A without renaming it. Dangerous in JDK 8, dangerous in JDK 9. (We're trying to encapsulate the internals of a module, which is different from trying to isolate modules from each other.) > > [*] Advanced scenario: the named module exporting A is actually an automatic module which happened to co-bundle package A. By placing this JAR on the modulepath to form an automatic module, it dominates the JAR left on the classpath which also co-bundled package A. > > Alex > > On 3/9/2016 1:17 PM, Paul Benedict wrote: >> But isn't what your proposing a security issue? Let's say my package A >> is in the unnamed module and your package A is in a named module. You >> basically took over my code; your classes will be substituted for mine. >> >> Cheers, >> Paul >> >> On Wed, Mar 9, 2016 at 2:38 PM, Alex Buckley > > wrote: >> >> On 3/9/2016 10:36 AM, Paul Benedict wrote: >> >> From the doc: >> "If a package is defined in both a named module and the unnamed >> module then >> the package in the unnamed module is ignored. This preserves >> reliable >> configuration even in the face of the chaos of the class path, >> ensuring >> that every module still reads at most one module defining a >> given package. >> If, in our example above, a JAR file on the class path contains >> a class >> file named com/foo/bar/alpha/AlphaFactory.class then that file >> will never >> be loaded, since the com.foo.bar.alpha package is exported by the >> com.foo.bar module." >> >> I would like some clarification. Correct me if wrong, but I >> think this >> entire paragraph is really meant to be about the perspective from a >> modularized JAR? If a module has package A, and the unnamed >> module has >> package A, then of course the module's package A should win. >> >> However, if it is meant to be absolute language, then I disagree. >> >> The unnamed module should be coherent among itself. If the >> unnamed module >> has package B and relies on classes from package A, it should >> still be able >> to see its own package A. I don't think modules should be able >> to impact >> how the unnamed module sees itself. That's a surprising situation. >> >> >> The unnamed module is not a root module during resolution. If your >> main class is in the unnamed module (i.e. you did java -jar >> MyApp.jar rather than java -m MyApp), then the module graph is >> created by resolving various root modules (what are they? separate >> discussion) and only then is the unnamed module hooked up to read >> every module in the graph. >> >> Hope we're OK so far. >> >> If some named module in the graph exports package A (more than one >> module exporting A? separate discussion), then since the unnamed >> module reads that named module, the unnamed module will access A.* >> types from that named module. >> >> It's hard to imagine the unnamed module NOT accessing A.* types from >> that named module. Primarily, we need to avoid a split package >> situation where code in the unnamed module sometimes accesses A.* >> types from the named module and sometimes from the unnamed module. >> >> You might say, OK, let code in the unnamed module exclusively access >> A.* in the unnamed module rather than exclusively access A.* in the >> named module. Then you have two problems: >> >> 1. There are issues for named modules in the same class loader as >> the unnamed module -- such named modules MUST get A.* from the named >> module rather than the unnamed module, and the class loading >> mechanism is incapable of switching based on accessor. It'll be >> common for named modules to exist in the same class loader as the >> unnamed module, as modular JARs on the modulepath and non-modular >> JARs on the classpath all end up in the application class loader >> (modular JARs as named modules; non-modular JARs jointly as the >> unnamed module). >> >> 2. While the module system is sure that package A exists in the >> named module, how would the module system possibly know that package >> A exists in the unnamed module? Scanning every class file in every >> non-modular JAR on the classpath at startup sounds bad. >> >> Alex >> >> From sundararajan.athijegannathan at oracle.com Thu Mar 10 01:28:51 2016 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Thu, 10 Mar 2016 01:28:51 +0000 Subject: hg: jigsaw/jake/jdk: ImageReader should fail with an IOException if image can't be opened in requested ByteOrder Message-ID: <201603100128.u2A1SpIw018994@aojmv0008.oracle.com> Changeset: 1768da383e24 Author: sundar Date: 2016-03-10 06:58 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1768da383e24 ImageReader should fail with an IOException if image can't be opened in requested ByteOrder Contributed-by: claes.redestad at oracle.com ! src/java.base/share/classes/jdk/internal/jimage/ImageReader.java ! test/jdk/internal/jimage/JImageReadTest.java From alex.buckley at oracle.com Thu Mar 10 01:56:54 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 09 Mar 2016 17:56:54 -0800 Subject: Unnamed module and duplicate package In-Reply-To: <3AD054BA-035F-44A6-9636-8238016E049F@oracle.com> References: <56E089E3.8040204@oracle.com> <56E097B5.9040201@oracle.com> <3AD054BA-035F-44A6-9636-8238016E049F@oracle.com> Message-ID: <56E0D466.9090605@oracle.com> Yes, a ClassCastException could only arise when (sticking with Paul's scenario) the same class exists in both the named module and the unnamed module. It would be "safe" for the module system to allow a package that is split perfectly between modules: no overlap of classes and no cyclic references between members. This is checkable when a package is split between two named modules that the resolver can observe in great detail. (You don't even need to check no-cyclic-references, since it's dominated by the no-cyclic-dependencies rule for the modules -- basically the split has to be perfect for the package to work at all.) But in the case of a package split between a named module and the unnamed module, the check is basically impossible, since the resolver can't enumerate the A.* types in the unnamed module without scanning the classpath, which sounds bad. tl;dr We don't want a lot of gymnastics in the module system to support a known-bad idiom which most Java developers will never come across. ("most" means "in the millions".) Alex On 3/9/2016 5:16 PM, Russell Gold wrote: > Doesn?t this kind of error only happen when a second module exports > the same _class_? What is the problem with another class being > defined in the same package, given that package B isn?t going to > access that new class at all? > > - Russ > >> On Mar 9, 2016, at 4:37 PM, Alex Buckley >> wrote: >> >> Presumably you would count the equivalent scenario on JDK 8 -- my >> package A is in Alex.jar on the classpath and your package A is in >> Paul.jar on the classpath -- as a security issue too, because some >> of my classes may substitute for yours (or some of yours for mine, >> depending on how the classpath is constructed). >> >> On JDK 9, we do the "substitution" cleanly. Package A is not split. >> That avoids one category of error (ClassCastException). What about >> poor package B that finds itself accessing a different package A >> than it was compiled with? Well, since package A is exported by a >> named module, it's reasonable to assume that the named module >> "owns" package A [*], and that the developer of package B >> co-bundled some version of package A without renaming it. Dangerous >> in JDK 8, dangerous in JDK 9. (We're trying to encapsulate the >> internals of a module, which is different from trying to isolate >> modules from each other.) >> >> [*] Advanced scenario: the named module exporting A is actually an >> automatic module which happened to co-bundle package A. By placing >> this JAR on the modulepath to form an automatic module, it >> dominates the JAR left on the classpath which also co-bundled >> package A. >> >> Alex >> >> On 3/9/2016 1:17 PM, Paul Benedict wrote: >>> But isn't what your proposing a security issue? Let's say my >>> package A is in the unnamed module and your package A is in a >>> named module. You basically took over my code; your classes will >>> be substituted for mine. >>> >>> Cheers, Paul >>> >>> On Wed, Mar 9, 2016 at 2:38 PM, Alex Buckley >>> > >>> wrote: >>> >>> On 3/9/2016 10:36 AM, Paul Benedict wrote: >>> >>> From the doc: "If a package is defined in both a named module and >>> the unnamed module then the package in the unnamed module is >>> ignored. This preserves reliable configuration even in the face >>> of the chaos of the class path, ensuring that every module still >>> reads at most one module defining a given package. If, in our >>> example above, a JAR file on the class path contains a class file >>> named com/foo/bar/alpha/AlphaFactory.class then that file will >>> never be loaded, since the com.foo.bar.alpha package is exported >>> by the com.foo.bar module." >>> >>> I would like some clarification. Correct me if wrong, but I think >>> this entire paragraph is really meant to be about the perspective >>> from a modularized JAR? If a module has package A, and the >>> unnamed module has package A, then of course the module's package >>> A should win. >>> >>> However, if it is meant to be absolute language, then I >>> disagree. >>> >>> The unnamed module should be coherent among itself. If the >>> unnamed module has package B and relies on classes from package >>> A, it should still be able to see its own package A. I don't >>> think modules should be able to impact how the unnamed module >>> sees itself. That's a surprising situation. >>> >>> >>> The unnamed module is not a root module during resolution. If >>> your main class is in the unnamed module (i.e. you did java -jar >>> MyApp.jar rather than java -m MyApp), then the module graph is >>> created by resolving various root modules (what are they? >>> separate discussion) and only then is the unnamed module hooked >>> up to read every module in the graph. >>> >>> Hope we're OK so far. >>> >>> If some named module in the graph exports package A (more than >>> one module exporting A? separate discussion), then since the >>> unnamed module reads that named module, the unnamed module will >>> access A.* types from that named module. >>> >>> It's hard to imagine the unnamed module NOT accessing A.* types >>> from that named module. Primarily, we need to avoid a split >>> package situation where code in the unnamed module sometimes >>> accesses A.* types from the named module and sometimes from the >>> unnamed module. >>> >>> You might say, OK, let code in the unnamed module exclusively >>> access A.* in the unnamed module rather than exclusively access >>> A.* in the named module. Then you have two problems: >>> >>> 1. There are issues for named modules in the same class loader >>> as the unnamed module -- such named modules MUST get A.* from the >>> named module rather than the unnamed module, and the class >>> loading mechanism is incapable of switching based on accessor. >>> It'll be common for named modules to exist in the same class >>> loader as the unnamed module, as modular JARs on the modulepath >>> and non-modular JARs on the classpath all end up in the >>> application class loader (modular JARs as named modules; >>> non-modular JARs jointly as the unnamed module). >>> >>> 2. While the module system is sure that package A exists in the >>> named module, how would the module system possibly know that >>> package A exists in the unnamed module? Scanning every class file >>> in every non-modular JAR on the classpath at startup sounds bad. >>> >>> Alex >>> >>> > From mandy.chung at oracle.com Thu Mar 10 02:21:26 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 10 Mar 2016 02:21:26 +0000 Subject: hg: jigsaw/jake/jdk: 3 new changesets Message-ID: <201603100221.u2A2LQfC007849@aojmv0008.oracle.com> Changeset: dd49e37ce9f1 Author: mchung Date: 2016-03-09 15:52 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/dd49e37ce9f1 Update StackFrame::toStackTraceElement to include module name and version ! src/java.base/share/classes/java/lang/StackFrameInfo.java ! src/java.base/share/classes/java/lang/StackWalker.java ! test/java/lang/StackWalker/VerifyStackTrace.java Changeset: 8291239ba70f Author: mchung Date: 2016-03-09 18:20 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8291239ba70f Minor formatting nit on Proxy ! src/java.base/share/classes/java/lang/reflect/Proxy.java ! src/java.base/share/classes/sun/reflect/misc/ReflectUtil.java Changeset: db24da498c17 Author: mchung Date: 2016-03-09 18:21 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/db24da498c17 Merge From russell.gold at oracle.com Thu Mar 10 03:14:09 2016 From: russell.gold at oracle.com (Russell Gold) Date: Wed, 9 Mar 2016 22:14:09 -0500 Subject: Unnamed module and duplicate package In-Reply-To: <56E0D466.9090605@oracle.com> References: <56E089E3.8040204@oracle.com> <56E097B5.9040201@oracle.com> <3AD054BA-035F-44A6-9636-8238016E049F@oracle.com> <56E0D466.9090605@oracle.com> Message-ID: This should, however, be completely safe in the case when one of those modules is part of the JDK itself, isn?t it? It is not clear to me how you could ever get a circular dependency in that case. In fact, this should be true of any library as well - the only scenario that I can think of where you could get this mess is if a developer compiles a bunch of classes, and then deliberately creates circularity between modules by putting some of those classes into a named module and some into the unnamed module, which seems incredibly unlikely. If there an actual plausible scenario from which you are hoping to protect developers with this restriction? - Russ > On Mar 9, 2016, at 8:56 PM, Alex Buckley wrote: > > Yes, a ClassCastException could only arise when (sticking with Paul's scenario) the same class exists in both the named module and the unnamed module. > > It would be "safe" for the module system to allow a package that is split perfectly between modules: no overlap of classes and no cyclic references between members. This is checkable when a package is split between two named modules that the resolver can observe in great detail. (You don't even need to check no-cyclic-references, since it's dominated by the no-cyclic-dependencies rule for the modules -- basically the split has to be perfect for the package to work at all.) > > But in the case of a package split between a named module and the unnamed module, the check is basically impossible, since the resolver can't enumerate the A.* types in the unnamed module without scanning the classpath, which sounds bad. > > tl;dr We don't want a lot of gymnastics in the module system to support a known-bad idiom which most Java developers will never come across. ("most" means "in the millions".) > > Alex > > On 3/9/2016 5:16 PM, Russell Gold wrote: >> Doesn?t this kind of error only happen when a second module exports >> the same _class_? What is the problem with another class being >> defined in the same package, given that package B isn?t going to >> access that new class at all? >> >> - Russ >> >>> On Mar 9, 2016, at 4:37 PM, Alex Buckley >>> wrote: >>> >>> Presumably you would count the equivalent scenario on JDK 8 -- my >>> package A is in Alex.jar on the classpath and your package A is in >>> Paul.jar on the classpath -- as a security issue too, because some >>> of my classes may substitute for yours (or some of yours for mine, >>> depending on how the classpath is constructed). >>> >>> On JDK 9, we do the "substitution" cleanly. Package A is not split. >>> That avoids one category of error (ClassCastException). What about >>> poor package B that finds itself accessing a different package A >>> than it was compiled with? Well, since package A is exported by a >>> named module, it's reasonable to assume that the named module >>> "owns" package A [*], and that the developer of package B >>> co-bundled some version of package A without renaming it. Dangerous >>> in JDK 8, dangerous in JDK 9. (We're trying to encapsulate the >>> internals of a module, which is different from trying to isolate >>> modules from each other.) >>> >>> [*] Advanced scenario: the named module exporting A is actually an >>> automatic module which happened to co-bundle package A. By placing >>> this JAR on the modulepath to form an automatic module, it >>> dominates the JAR left on the classpath which also co-bundled >>> package A. >>> >>> Alex >>> >>> On 3/9/2016 1:17 PM, Paul Benedict wrote: >>>> But isn't what your proposing a security issue? Let's say my >>>> package A is in the unnamed module and your package A is in a >>>> named module. You basically took over my code; your classes will >>>> be substituted for mine. >>>> >>>> Cheers, Paul >>>> >>>> On Wed, Mar 9, 2016 at 2:38 PM, Alex Buckley >>>> > >>>> wrote: >>>> >>>> On 3/9/2016 10:36 AM, Paul Benedict wrote: >>>> >>>> From the doc: "If a package is defined in both a named module and >>>> the unnamed module then the package in the unnamed module is >>>> ignored. This preserves reliable configuration even in the face >>>> of the chaos of the class path, ensuring that every module still >>>> reads at most one module defining a given package. If, in our >>>> example above, a JAR file on the class path contains a class file >>>> named com/foo/bar/alpha/AlphaFactory.class then that file will >>>> never be loaded, since the com.foo.bar.alpha package is exported >>>> by the com.foo.bar module." >>>> >>>> I would like some clarification. Correct me if wrong, but I think >>>> this entire paragraph is really meant to be about the perspective >>>> from a modularized JAR? If a module has package A, and the >>>> unnamed module has package A, then of course the module's package >>>> A should win. >>>> >>>> However, if it is meant to be absolute language, then I >>>> disagree. >>>> >>>> The unnamed module should be coherent among itself. If the >>>> unnamed module has package B and relies on classes from package >>>> A, it should still be able to see its own package A. I don't >>>> think modules should be able to impact how the unnamed module >>>> sees itself. That's a surprising situation. >>>> >>>> >>>> The unnamed module is not a root module during resolution. If >>>> your main class is in the unnamed module (i.e. you did java -jar >>>> MyApp.jar rather than java -m MyApp), then the module graph is >>>> created by resolving various root modules (what are they? >>>> separate discussion) and only then is the unnamed module hooked >>>> up to read every module in the graph. >>>> >>>> Hope we're OK so far. >>>> >>>> If some named module in the graph exports package A (more than >>>> one module exporting A? separate discussion), then since the >>>> unnamed module reads that named module, the unnamed module will >>>> access A.* types from that named module. >>>> >>>> It's hard to imagine the unnamed module NOT accessing A.* types >>>> from that named module. Primarily, we need to avoid a split >>>> package situation where code in the unnamed module sometimes >>>> accesses A.* types from the named module and sometimes from the >>>> unnamed module. >>>> >>>> You might say, OK, let code in the unnamed module exclusively >>>> access A.* in the unnamed module rather than exclusively access >>>> A.* in the named module. Then you have two problems: >>>> >>>> 1. There are issues for named modules in the same class loader >>>> as the unnamed module -- such named modules MUST get A.* from the >>>> named module rather than the unnamed module, and the class >>>> loading mechanism is incapable of switching based on accessor. >>>> It'll be common for named modules to exist in the same class >>>> loader as the unnamed module, as modular JARs on the modulepath >>>> and non-modular JARs on the classpath all end up in the >>>> application class loader (modular JARs as named modules; >>>> non-modular JARs jointly as the unnamed module). >>>> >>>> 2. While the module system is sure that package A exists in the >>>> named module, how would the module system possibly know that >>>> package A exists in the unnamed module? Scanning every class file >>>> in every non-modular JAR on the classpath at startup sounds bad. >>>> >>>> Alex >>>> >>>> >> From mandy.chung at oracle.com Thu Mar 10 04:43:04 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 10 Mar 2016 04:43:04 +0000 Subject: hg: jigsaw/jake/jdk: 2 new changesets Message-ID: <201603100443.u2A4h480028378@aojmv0008.oracle.com> Changeset: 0df311376629 Author: mchung Date: 2016-03-09 17:43 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0df311376629 Define aggregator modules by the ext class loader ! make/gensrc/GensrcModuleLoaderMap.gmk Changeset: 55db10fa9b76 Author: mchung Date: 2016-03-09 20:43 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/55db10fa9b76 Merge From Alan.Bateman at oracle.com Thu Mar 10 07:58:15 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 10 Mar 2016 07:58:15 +0000 Subject: Automatic module names In-Reply-To: References: <56e08206.8896420a.2a052.442aSMTPIN_ADDED_BROKEN@mx.google.com> Message-ID: <56E12917.1090804@oracle.com> On 09/03/2016 22:15, Paul Benedict wrote: > : > > 1) Wants to assign an official module name when used in the modulepath > (forward looking requirement) > 2) Doesn't want to make JDK 9 a minimum version (thus no module-info.class) > Keep in mind that a compiled module-info can be added to a JAR file where the code is otherwise compiled for an older release. If you are willing to tolerate a newer JDK in your build environment then you can compile that code with `javac -release N`(see JEP 247 [1]). This means one JDK in your build environment with the build creating a JAR file that you can deploy on the class path with JDK N or newer, or as an explicit module with JDK 9 or newer. It is of course a more complicated build but something that a "forward looking" developer could do. -Alan [1] http://openjdk.java.net/jeps/247 From scolebourne at joda.org Thu Mar 10 08:27:14 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 10 Mar 2016 08:27:14 +0000 Subject: Automatic module names In-Reply-To: <56E12917.1090804@oracle.com> References: <56e08206.8896420a.2a052.442aSMTPIN_ADDED_BROKEN@mx.google.com> <56E12917.1090804@oracle.com> Message-ID: On 10 March 2016 at 07:58, Alan Bateman wrote: > Keep in mind that a compiled module-info can be added to a JAR file where > the code is otherwise compiled for an older release. If you are willing to > tolerate a newer JDK in your build environment then you can compile that > code with `javac -release N`(see JEP 247 [1]). This means one JDK in your > build environment with the build creating a JAR file that you can deploy on > the class path with JDK N or newer, or as an explicit module with JDK 9 or > newer. It is of course a more complicated build but something that a > "forward looking" developer could do. Joda-Time compiles for JDK 1.5, other Joda projects for 1..6. Last time I looked, the tool didn't go back far enough to be useful. Stephen From david.lloyd at redhat.com Thu Mar 10 12:39:33 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 10 Mar 2016 06:39:33 -0600 Subject: Unnamed module and duplicate package In-Reply-To: References: <56E089E3.8040204@oracle.com> Message-ID: <56E16B05.7020008@redhat.com> I presume this wouldn't happen if the packages were sealed though, whether in Java 8 or earlier or under the unnamed module in Java 9. Right? On 03/09/2016 03:17 PM, Paul Benedict wrote: > But isn't what your proposing a security issue? Let's say my package A is > in the unnamed module and your package A is in a named module. You > basically took over my code; your classes will be substituted for mine. > > Cheers, > Paul > > On Wed, Mar 9, 2016 at 2:38 PM, Alex Buckley > wrote: > >> On 3/9/2016 10:36 AM, Paul Benedict wrote: >> >>> From the doc: >>> "If a package is defined in both a named module and the unnamed module >>> then >>> the package in the unnamed module is ignored. This preserves reliable >>> configuration even in the face of the chaos of the class path, ensuring >>> that every module still reads at most one module defining a given package. >>> If, in our example above, a JAR file on the class path contains a class >>> file named com/foo/bar/alpha/AlphaFactory.class then that file will never >>> be loaded, since the com.foo.bar.alpha package is exported by the >>> com.foo.bar module." >>> >>> I would like some clarification. Correct me if wrong, but I think this >>> entire paragraph is really meant to be about the perspective from a >>> modularized JAR? If a module has package A, and the unnamed module has >>> package A, then of course the module's package A should win. >>> >>> However, if it is meant to be absolute language, then I disagree. >>> >>> The unnamed module should be coherent among itself. If the unnamed module >>> has package B and relies on classes from package A, it should still be >>> able >>> to see its own package A. I don't think modules should be able to impact >>> how the unnamed module sees itself. That's a surprising situation. >>> >> >> The unnamed module is not a root module during resolution. If your main >> class is in the unnamed module (i.e. you did java -jar MyApp.jar rather >> than java -m MyApp), then the module graph is created by resolving various >> root modules (what are they? separate discussion) and only then is the >> unnamed module hooked up to read every module in the graph. >> >> Hope we're OK so far. >> >> If some named module in the graph exports package A (more than one module >> exporting A? separate discussion), then since the unnamed module reads that >> named module, the unnamed module will access A.* types from that named >> module. >> >> It's hard to imagine the unnamed module NOT accessing A.* types from that >> named module. Primarily, we need to avoid a split package situation where >> code in the unnamed module sometimes accesses A.* types from the named >> module and sometimes from the unnamed module. >> >> You might say, OK, let code in the unnamed module exclusively access A.* >> in the unnamed module rather than exclusively access A.* in the named >> module. Then you have two problems: >> >> 1. There are issues for named modules in the same class loader as the >> unnamed module -- such named modules MUST get A.* from the named module >> rather than the unnamed module, and the class loading mechanism is >> incapable of switching based on accessor. It'll be common for named modules >> to exist in the same class loader as the unnamed module, as modular JARs on >> the modulepath and non-modular JARs on the classpath all end up in the >> application class loader (modular JARs as named modules; non-modular JARs >> jointly as the unnamed module). >> >> 2. While the module system is sure that package A exists in the named >> module, how would the module system possibly know that package A exists in >> the unnamed module? Scanning every class file in every non-modular JAR on >> the classpath at startup sounds bad. >> >> Alex >> -- - DML From jan.lahoda at oracle.com Thu Mar 10 13:36:26 2016 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Thu, 10 Mar 2016 13:36:26 +0000 Subject: hg: jigsaw/jake/langtools: Fixing tests on Win. Message-ID: <201603101336.u2ADaQkO007427@aojmv0008.oracle.com> Changeset: 4316d49b4bb1 Author: jlahoda Date: 2016-03-10 14:35 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/4316d49b4bb1 Fixing tests on Win. ! test/tools/javac/modules/AddLimitMods.java ! test/tools/javac/modules/AnnotationProcessorsInModulesTest.java ! test/tools/javac/modules/EdgeCases.java ! test/tools/javac/modules/ModulePathTest.java ! test/tools/javac/modules/OutputDirTest.java ! test/tools/javac/modules/PluginsInModulesTest.java From Alan.Bateman at oracle.com Thu Mar 10 13:41:40 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 10 Mar 2016 13:41:40 +0000 Subject: Unnamed module and duplicate package In-Reply-To: <56E16B05.7020008@redhat.com> References: <56E089E3.8040204@oracle.com> <56E16B05.7020008@redhat.com> Message-ID: <56E17994.2030507@oracle.com> On 10/03/2016 12:39, David M. Lloyd wrote: > I presume this wouldn't happen if the packages were sealed though, > whether in Java 8 or earlier or under the unnamed module in Java 9. > Right? > That's right although I don't think sealed packages have been popular. With named modules then the packages are of course sealed with the location of the module (if known). -Alan. From harold.seigel at oracle.com Thu Mar 10 13:48:06 2016 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Thu, 10 Mar 2016 13:48:06 +0000 Subject: hg: jigsaw/jake/jdk: Use String.isEmpty() instead of checking for "". Message-ID: <201603101348.u2ADm6qr011309@aojmv0008.oracle.com> Changeset: 0a46b03f327c Author: hseigel Date: 2016-03-10 08:19 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0a46b03f327c Use String.isEmpty() instead of checking for "". ! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java From lois.foltan at oracle.com Thu Mar 10 14:35:31 2016 From: lois.foltan at oracle.com (lois.foltan at oracle.com) Date: Thu, 10 Mar 2016 14:35:31 +0000 Subject: hg: jigsaw/jake/hotspot: Fix issue with test JFR capturing system properties at startup. Message-ID: <201603101435.u2AEZWsu029712@aojmv0008.oracle.com> Changeset: ee0c70bdad15 Author: lfoltan Date: 2016-03-10 09:08 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ee0c70bdad15 Fix issue with test JFR capturing system properties at startup. ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp From erik.joelsson at oracle.com Thu Mar 10 14:39:47 2016 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Thu, 10 Mar 2016 14:39:47 +0000 Subject: hg: jigsaw/jake: Fixing JDK-8149775: Exploded image has _the. files on system module path Message-ID: <201603101439.u2AEdlDm000715@aojmv0008.oracle.com> Changeset: 6b9bb0953873 Author: erikj Date: 2016-03-10 15:39 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/6b9bb0953873 Fixing JDK-8149775: Exploded image has _the. files on system module path ! make/CreateJmods.gmk ! make/common/JavaCompilation.gmk From lois.foltan at oracle.com Thu Mar 10 15:10:36 2016 From: lois.foltan at oracle.com (lois.foltan at oracle.com) Date: Thu, 10 Mar 2016 15:10:36 +0000 Subject: hg: jigsaw/jake/hotspot: Cleanup from internal code review comments. Message-ID: <201603101510.u2AFAa2u012544@aojmv0008.oracle.com> Changeset: 291f29771cd0 Author: lfoltan Date: 2016-03-10 09:43 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/291f29771cd0 Cleanup from internal code review comments. ! src/share/vm/classfile/moduleEntry.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/reflection.cpp From pbenedict at apache.org Thu Mar 10 15:27:22 2016 From: pbenedict at apache.org (Paul Benedict) Date: Thu, 10 Mar 2016 09:27:22 -0600 Subject: Automatic module names In-Reply-To: References: <56e08206.8896420a.2a052.442aSMTPIN_ADDED_BROKEN@mx.google.com> <56E12917.1090804@oracle.com> Message-ID: Yes, Stephen is correct. This is true. And as Robert Scholte of Maven pointed out, he still needs to support JRE 6 as the minimum. Lots of OSS projects still target 6. I think we should give them a little help in this area. Cheers, Paul On Thu, Mar 10, 2016 at 2:27 AM, Stephen Colebourne wrote: > On 10 March 2016 at 07:58, Alan Bateman wrote: > > Keep in mind that a compiled module-info can be added to a JAR file where > > the code is otherwise compiled for an older release. If you are willing > to > > tolerate a newer JDK in your build environment then you can compile that > > code with `javac -release N`(see JEP 247 [1]). This means one JDK in your > > build environment with the build creating a JAR file that you can deploy > on > > the class path with JDK N or newer, or as an explicit module with JDK 9 > or > > newer. It is of course a more complicated build but something that a > > "forward looking" developer could do. > > Joda-Time compiles for JDK 1.5, other Joda projects for 1..6. Last > time I looked, the tool didn't go back far enough to be useful. > > Stephen > From Alan.Bateman at oracle.com Thu Mar 10 15:33:32 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 10 Mar 2016 15:33:32 +0000 Subject: Automatic module names In-Reply-To: References: <56e08206.8896420a.2a052.442aSMTPIN_ADDED_BROKEN@mx.google.com> <56E12917.1090804@oracle.com> Message-ID: <56E193CC.20707@oracle.com> On 10/03/2016 08:27, Stephen Colebourne wrote: > : > Joda-Time compiles for JDK 1.5, other Joda projects for 1..6. Last > time I looked, the tool didn't go back far enough to be useful. > It's three back so `javac -release 6` should be okay. -Alan. From mandy.chung at oracle.com Thu Mar 10 17:54:40 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 10 Mar 2016 17:54:40 +0000 Subject: hg: jigsaw/jake: 6 new changesets Message-ID: <201603101754.u2AHsefx025732@aojmv0008.oracle.com> Changeset: 009487c0169b Author: erikj Date: 2016-03-07 09:13 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/009487c0169b 8151300: Build shell trace functionality lost in JDK-8076060 Reviewed-by: tbell ! make/common/MakeBase.gmk Changeset: 2436705f4a75 Author: erikj Date: 2016-03-07 09:14 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/2436705f4a75 8150504: JIB profiles for reference implementation builds Reviewed-by: ihse ! common/conf/jib-profiles.js Changeset: 1787bdaabb2b Author: ddehaven Date: 2016-03-07 09:08 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/1787bdaabb2b 8132743: Move netscape.javascript package from jdk.plugin to new module Reviewed-by: kcr, mchung, alanb ! make/Images.gmk ! modules.xml Changeset: 43743623fcea Author: henryjen Date: 2016-03-09 18:48 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/43743623fcea Merge ! common/autoconf/generated-configure.sh ! common/conf/jib-profiles.js ! make/Images.gmk ! make/common/MakeBase.gmk Changeset: 6f5bc4442d67 Author: henryjen Date: 2016-03-09 18:50 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/6f5bc4442d67 Merge ! make/Images.gmk Changeset: d20ac1c8a722 Author: mchung Date: 2016-03-10 09:26 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/d20ac1c8a722 Merge From mandy.chung at oracle.com Thu Mar 10 17:54:51 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 10 Mar 2016 17:54:51 +0000 Subject: hg: jigsaw/jake/hotspot: 41 new changesets Message-ID: <201603101754.u2AHsqPE025887@aojmv0008.oracle.com> Changeset: 0b63d854f7a6 Author: kbarrett Date: 2016-02-16 21:58 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0b63d854f7a6 8146728: TestPrintGCDetailsVerbose is never run by jtreg Summary: Remove requirement for fastdebug, update logging option Reviewed-by: sjohanss, brutisso, dfazunen ! test/TEST.ROOT ! test/gc/parallel/TestPrintGCDetailsVerbose.java Changeset: b0cdcfe42ebf Author: mlarsson Date: 2016-02-17 11:11 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b0cdcfe42ebf 8148219: Add decorator hostname to UL Reviewed-by: dholmes, mlarsson Contributed-by: robbin.ehn at oracle.com ! src/os/posix/vm/os_posix.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/logging/logConfiguration.cpp ! src/share/vm/logging/logDecorations.cpp ! src/share/vm/logging/logDecorations.hpp ! src/share/vm/logging/logDecorators.hpp ! src/share/vm/runtime/os.hpp Changeset: 695127299575 Author: ddmitriev Date: 2016-02-17 11:00 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/695127299575 8144578: TestOptionsWithRanges test only ever uses the default collector Reviewed-by: sangheki, dholmes ! test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java ! test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOption.java ! test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java + test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMStartup.java Changeset: f83b14f087e3 Author: ddmitriev Date: 2016-02-17 12:44 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f83b14f087e3 Merge Changeset: 99f1cf3520d9 Author: jmasa Date: 2016-02-16 13:20 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/99f1cf3520d9 8149643: Remove check of counters in VirtualSpaceNode::inc_container_count Reviewed-by: brutisso, kbarrett, mgerdin Contributed-by: dmitry.dmitriev at oracle.com ! src/share/vm/memory/metaspace.cpp Changeset: eda0d9992163 Author: rprotacio Date: 2016-02-17 14:03 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/eda0d9992163 8148630: Convert TraceStartupTime to Unified Logging Summary: The former -XX:+TraceStartupTime flag has been converted to the UL option -Xlog:startuptime=info Reviewed-by: coleenp, dholmes ! src/share/vm/interpreter/cppInterpreter.cpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/interpreter/templateTable.cpp ! src/share/vm/logging/logTag.hpp ! src/share/vm/memory/metaspaceShared.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/globals.hpp + src/share/vm/runtime/logTimer.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/timer.cpp ! src/share/vm/runtime/timer.hpp + test/runtime/logging/StartupTimeTest.java Changeset: f5f89bd4cd27 Author: kbarrett Date: 2016-02-17 16:00 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f5f89bd4cd27 8149793: DirtyCardQueueSet::apply_closure_to_completed_buffer_helper isn't helpful Summary: Merge helper into sole caller. Reviewed-by: brutisso, jwilhelm, tschatzl ! src/share/vm/gc/g1/concurrentG1RefineThread.cpp ! src/share/vm/gc/g1/dirtyCardQueue.cpp ! src/share/vm/gc/g1/dirtyCardQueue.hpp Changeset: 5c492a3bcacf Author: kbarrett Date: 2016-02-17 23:57 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5c492a3bcacf Merge Changeset: b1d3888c0ae7 Author: sgehwolf Date: 2016-02-17 17:03 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b1d3888c0ae7 8143245: Zero build requires disabled warnings Reviewed-by: dholmes, coleenp ! make/linux/makefiles/zeroshark.make ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/interpreterRT_zero.cpp ! src/os_cpu/linux_zero/vm/os_linux_zero.cpp ! src/os_cpu/linux_zero/vm/thread_linux_zero.hpp Changeset: 04465692f987 Author: coleenp Date: 2016-02-18 03:47 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/04465692f987 Merge Changeset: 9fd1e876ec1f Author: simonis Date: 2016-02-17 22:17 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9fd1e876ec1f 8150079: MSVC prior to VS 2013 doesn't know the 'va_copy' macro Reviewed-by: dholmes ! src/share/vm/prims/jni.cpp ! src/share/vm/utilities/globalDefinitions_visCPP.hpp Changeset: 50e7ba84b313 Author: dholmes Date: 2016-02-18 03:51 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/50e7ba84b313 Merge Changeset: dcfd41c9aee8 Author: akulyakh Date: 2016-02-18 14:56 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/dcfd41c9aee8 8150067: Quarantine serviceability/tmtools/jstat/GcCapacityTest.java Summary: Quarantine a falsely failing test until the test issue is fixed Reviewed-by: sla ! test/serviceability/tmtools/jstat/GcCapacityTest.java Changeset: 66a81854aa5d Author: rprotacio Date: 2016-02-18 17:10 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/66a81854aa5d 8149383: Convert TraceBiasedLocking to Unified Logging Summary: The former -XX:+TraceBiasedLocking flag has been converted to the UL option -Xlog:biasedlocking=info and =trace, with the old option being aliased. Reviewed-by: dholmes, dcubed ! src/share/vm/logging/logTag.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/biasedLocking.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp + test/runtime/logging/BiasedLockingTest.java Changeset: 8c94907406e1 Author: drwhite Date: 2016-02-17 18:02 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/8c94907406e1 8149837: String.intern creates morre work than necessary for G1 Summary: Only use the SATB read barrier when reading existing strings from string table, not when adding new strings. Reviewed-by: stefank, kbarrett ! src/share/vm/classfile/stringTable.cpp Changeset: c364db766187 Author: ysuenaga Date: 2016-02-18 23:26 +0900 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c364db766187 8147388: Add diagnostic commands to attach JVMTI agent. Reviewed-by: jbachorik, sspitsyn ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp + test/serviceability/dcmd/jvmti/LoadAgentDcmdTest.java + test/serviceability/dcmd/jvmti/LoadJavaAgentDcmdTest.java + test/serviceability/dcmd/jvmti/SimpleJvmtiAgent.java Changeset: a4dc32b7640d Author: ddmitriev Date: 2016-02-19 13:24 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a4dc32b7640d 8146187: Print develop and nonproduct flags by -XX:+PrintFlags* options in debug build Reviewed-by: gtriantafill, gziemski, dholmes ! src/share/vm/runtime/globals.cpp ! test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java Changeset: a10b72550e25 Author: ddmitriev Date: 2016-02-19 12:47 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a10b72550e25 Merge Changeset: 2eed484c9c04 Author: mgerdin Date: 2016-02-04 08:22 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2eed484c9c04 8149013: Remove unused and dead code from G1CollectorPolicy Reviewed-by: ehelin, jwilhelm ! src/share/vm/gc/g1/g1CollectedHeap.cpp ! src/share/vm/gc/g1/g1CollectorPolicy.cpp ! src/share/vm/gc/g1/g1CollectorPolicy.hpp ! src/share/vm/gc/g1/g1ConcurrentMark.cpp Changeset: d858d53ddd54 Author: mgerdin Date: 2016-02-19 13:08 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d858d53ddd54 Merge Changeset: d02f3149a3e8 Author: mgerdin Date: 2016-02-19 14:15 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d02f3149a3e8 Merge Changeset: ffd3843c127c Author: ihse Date: 2016-02-19 14:04 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ffd3843c127c 8150201: Restore missing -g flags to files with OPT_CFLAGS/per-file Reviewed-by: dholmes, erikj ! make/bsd/makefiles/amd64.make ! make/bsd/makefiles/gcc.make ! make/linux/makefiles/amd64.make ! make/linux/makefiles/gcc.make ! make/linux/makefiles/i486.make ! make/solaris/makefiles/amd64.make ! make/solaris/makefiles/product.make ! make/solaris/makefiles/sparcWorks.make Changeset: 8931bfe95633 Author: ihse Date: 2016-02-19 15:25 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/8931bfe95633 Merge Changeset: 1f58338cdec9 Author: kbarrett Date: 2016-02-19 15:14 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1f58338cdec9 8150134: Simplify concurrent refinement thread deactivation Summary: Remove explicit deactivation and use green stop_at value. Reviewed-by: jmasa, tschatzl ! src/share/vm/gc/g1/concurrentG1RefineThread.cpp Changeset: ad7a71500f4a Author: clanger Date: 2016-02-19 10:44 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ad7a71500f4a 8150232: AIX cleanup: Integrate changes of 7178026 and others Reviewed-by: simonis ! src/os/aix/vm/attachListener_aix.cpp ! src/os/aix/vm/perfMemory_aix.cpp Changeset: 7f60f3f24e80 Author: jmasa Date: 2016-02-22 09:41 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7f60f3f24e80 8150302: Reference processing logging prints the "from list" incorrectly Reviewed-by: tamao, brutisso ! src/share/vm/gc/shared/referenceProcessor.cpp Changeset: 124a4306663f Author: jwilhelm Date: 2016-02-22 19:46 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/124a4306663f Merge ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/thread.cpp Changeset: 5624ea45bbd7 Author: jwilhelm Date: 2016-02-22 19:25 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5624ea45bbd7 Merge Changeset: c35381ecd2da Author: brutisso Date: 2016-02-23 09:52 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c35381ecd2da 8150367: Add back information about the number of GC workers Reviewed-by: sjohanss, tschatzl ! src/share/vm/gc/g1/g1CollectedHeap.cpp ! src/share/vm/gc/shared/workgroup.hpp Changeset: 7bc85612c893 Author: tonyp Date: 2016-02-23 10:44 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7bc85612c893 8146989: Introduce per-worker preserved mark stacks in ParNew Summary: Unify and provide per-worker preserved mark stack handling in ParNew Reviewed-by: tschatzl, ysr ! src/share/vm/gc/cms/parNewGeneration.cpp ! src/share/vm/gc/cms/parNewGeneration.hpp ! src/share/vm/gc/g1/g1EvacFailure.hpp ! src/share/vm/gc/serial/defNewGeneration.cpp ! src/share/vm/gc/serial/defNewGeneration.hpp + src/share/vm/gc/shared/preservedMarks.cpp + src/share/vm/gc/shared/preservedMarks.hpp + src/share/vm/gc/shared/preservedMarks.inline.hpp Changeset: d015eb5b230c Author: tschatzl Date: 2016-02-23 14:14 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d015eb5b230c Merge Changeset: 046cdd3a4173 Author: stuefe Date: 2016-02-23 19:10 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/046cdd3a4173 8150379: [windows] Fix Leaks in perfMemory_windows.cpp Reviewed-by: clanger, dholmes, gthornbr ! src/os/windows/vm/perfMemory_windows.cpp Changeset: e389b96f65cd Author: jwilhelm Date: 2016-02-25 17:26 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e389b96f65cd 8150647: Quarantine TestPLABResize.java until JDK-8150183 is fixed 8150562: Quarantine LoadAgentDcmdTest.java due to JDK-8150318 Reviewed-by: iklam, tschatzl ! test/gc/g1/plab/TestPLABResize.java ! test/serviceability/dcmd/jvmti/LoadAgentDcmdTest.java Changeset: 0fe42e7d345c Author: amurillo Date: 2016-02-26 10:35 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0fe42e7d345c Merge Changeset: d132d9803a5e Author: chegar Date: 2016-03-03 12:59 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d132d9803a5e 8150162: Move sun.misc.Version to a truly internal package Reviewed-by: alanb, dholmes, iris, mchung, rriggs ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/thread.cpp Changeset: f20c0fbdd45a Author: lana Date: 2016-03-03 12:49 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f20c0fbdd45a Merge Changeset: c7e17532efa8 Author: ctornqvi Date: 2016-03-03 12:44 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c7e17532efa8 8151156: [TESTBUG] Integrate trivial Hotspot test changes from Jake before Jigsaw M3 Reviewed-by: hseigel, gtriantafill ! test/compiler/calls/fromCompiled/CompiledInvokeDynamic2CompiledTest.java ! test/compiler/calls/fromCompiled/CompiledInvokeDynamic2InterpretedTest.java ! test/compiler/calls/fromCompiled/CompiledInvokeDynamic2NativeTest.java ! test/compiler/calls/fromInterpreted/InterpretedInvokeDynamic2CompiledTest.java ! test/compiler/calls/fromInterpreted/InterpretedInvokeDynamic2InterpretedTest.java ! test/compiler/calls/fromInterpreted/InterpretedInvokeDynamic2NativeTest.java ! test/compiler/intrinsics/unsafe/TestUnsafeUnalignedMismatchedAccesses.java ! test/compiler/jvmci/JVM_GetJVMCIRuntimeTest.java ! test/compiler/jvmci/code/InterpreterFrameSizeTest.java ! test/compiler/jvmci/compilerToVM/JVM_RegisterJVMCINatives.java ! test/compiler/jvmci/errors/TestInvalidCompilationResult.java ! test/compiler/jvmci/errors/TestInvalidDebugInfo.java ! test/compiler/jvmci/errors/TestInvalidOopMap.java ! test/compiler/jvmci/events/JvmciShutdownEventTest.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/ResolvedJavaTypeResolveConcreteMethodTest.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/ResolvedJavaTypeResolveMethodTest.java ! test/runtime/RedefineTests/RedefineRunningMethodsWithResolutionErrors.java ! test/runtime/ReservedStack/ReservedStackTest.java ! test/runtime/SharedArchiveFile/LimitSharedSizes.java ! test/runtime/contended/Basic.java ! test/runtime/contended/DefaultValue.java ! test/runtime/contended/HasNonStatic.java ! test/runtime/contended/Inheritance1.java ! test/runtime/contended/OopMaps.java ! test/runtime/contended/OopMapsSameGroup.java ! test/runtime/lambda-features/TestStaticandInstance.java ! test/serviceability/attach/AttachSetGetFlag.java ! test/serviceability/attach/AttachWithStalePidFile.java ! test/serviceability/dcmd/gc/HeapDumpAllTest.java ! test/serviceability/dcmd/gc/HeapDumpTest.java ! test/testlibrary_tests/ctw/ClassesDirTest.java ! test/testlibrary_tests/ctw/ClassesListTest.java ! test/testlibrary_tests/ctw/JarDirTest.java ! test/testlibrary_tests/ctw/JarsTest.java Changeset: 7e7e50ac4faf Author: dcubed Date: 2016-03-05 19:22 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7e7e50ac4faf 8151348: quarantine compiler/codecache/jmx/PeakUsageTest.java in JDK9-dev Reviewed-by: ctornqvi, amurillo ! test/compiler/codecache/jmx/PeakUsageTest.java Changeset: e6f7fd26f9ca Author: henryjen Date: 2016-03-09 18:48 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e6f7fd26f9ca Merge ! src/os/windows/vm/os_windows.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/logging/logTag.hpp ! src/share/vm/memory/metaspaceShared.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/thread.cpp ! test/compiler/calls/fromCompiled/CompiledInvokeDynamic2CompiledTest.java ! test/compiler/calls/fromCompiled/CompiledInvokeDynamic2InterpretedTest.java ! test/compiler/calls/fromCompiled/CompiledInvokeDynamic2NativeTest.java ! test/compiler/calls/fromInterpreted/InterpretedInvokeDynamic2CompiledTest.java ! test/compiler/calls/fromInterpreted/InterpretedInvokeDynamic2InterpretedTest.java ! test/compiler/calls/fromInterpreted/InterpretedInvokeDynamic2NativeTest.java ! test/compiler/intrinsics/unsafe/TestUnsafeUnalignedMismatchedAccesses.java ! test/compiler/jvmci/JVM_GetJVMCIRuntimeTest.java ! test/compiler/jvmci/compilerToVM/JVM_RegisterJVMCINatives.java ! test/compiler/jvmci/errors/TestInvalidCompilationResult.java ! test/compiler/jvmci/errors/TestInvalidDebugInfo.java ! test/compiler/jvmci/errors/TestInvalidOopMap.java ! test/compiler/jvmci/events/JvmciShutdownEventTest.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/ResolvedJavaTypeResolveConcreteMethodTest.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/ResolvedJavaTypeResolveMethodTest.java ! test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java ! test/runtime/RedefineTests/RedefineRunningMethodsWithResolutionErrors.java ! test/runtime/ReservedStack/ReservedStackTest.java ! test/runtime/SharedArchiveFile/LimitSharedSizes.java ! test/runtime/contended/Basic.java ! test/runtime/contended/DefaultValue.java ! test/runtime/contended/HasNonStatic.java ! test/runtime/contended/Inheritance1.java ! test/runtime/contended/OopMaps.java ! test/runtime/contended/OopMapsSameGroup.java ! test/runtime/lambda-features/TestStaticandInstance.java ! test/serviceability/attach/AttachSetGetFlag.java ! test/serviceability/attach/AttachWithStalePidFile.java ! test/serviceability/dcmd/gc/HeapDumpAllTest.java ! test/serviceability/dcmd/gc/HeapDumpTest.java ! test/testlibrary_tests/ctw/ClassesDirTest.java ! test/testlibrary_tests/ctw/ClassesListTest.java ! test/testlibrary_tests/ctw/JarDirTest.java ! test/testlibrary_tests/ctw/JarsTest.java Changeset: c3bb10ec9192 Author: henryjen Date: 2016-03-09 18:50 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c3bb10ec9192 Merge ! src/share/vm/memory/metaspaceShared.cpp Changeset: a5ceb4c57e84 Author: mchung Date: 2016-03-10 09:26 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a5ceb4c57e84 Merge ! src/share/vm/runtime/arguments.cpp From mandy.chung at oracle.com Thu Mar 10 17:54:57 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 10 Mar 2016 17:54:57 +0000 Subject: hg: jigsaw/jake/jaxws: 3 new changesets Message-ID: <201603101754.u2AHsvcO025988@aojmv0008.oracle.com> Changeset: ebff1bd3627a Author: aefimov Date: 2016-03-01 17:19 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/ebff1bd3627a 8150174: Update JAX-WS RI integration to latest version (2.3.0-SNAPSHOT) Reviewed-by: lancea ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/Const.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/StructureLoader.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/schemagen/XmlSchemaGenerator.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/packaging/mime/internet/InternetHeaders.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/MimeBodyPart.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/api/pipe/ThreadHelper.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/Headers.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/util/ServiceFinder.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/util/version.properties ! src/java.xml.ws/share/classes/javax/xml/soap/FactoryFinder.java ! src/java.xml.ws/share/classes/javax/xml/ws/spi/FactoryFinder.java ! src/jdk.xml.bind/share/classes/com/sun/codemodel/internal/JJavaName.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/jxc/ap/MessageBundle.properties + src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_de.properties + src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_es.properties + src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_fr.properties + src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_it.properties + src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_ja.properties + src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_ko.properties + src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_pt_BR.properties + src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_zh_CN.properties + src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_zh_TW.properties ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/model/CTypeRef.java ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/version.properties Changeset: 4b0697e4ce89 Author: lana Date: 2016-03-03 12:48 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/4b0697e4ce89 Merge Changeset: f978795a3a50 Author: henryjen Date: 2016-03-09 18:48 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/f978795a3a50 Merge ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/util/ServiceFinder.java ! src/java.xml.ws/share/classes/javax/xml/soap/FactoryFinder.java ! src/java.xml.ws/share/classes/javax/xml/ws/spi/FactoryFinder.java From mandy.chung at oracle.com Thu Mar 10 17:55:07 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 10 Mar 2016 17:55:07 +0000 Subject: hg: jigsaw/jake/jdk: 46 new changesets Message-ID: <201603101755.u2AHt9NC026128@aojmv0008.oracle.com> Changeset: d6dbe934ed0f Author: rriggs Date: 2016-02-29 18:00 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d6dbe934ed0f 8150346: java/lang/ProcessHandle/InfoTest.java failed - startTime after process spawn completed Reviewed-by: redestad, martin ! test/java/lang/ProcessHandle/Basic.java ! test/java/lang/ProcessHandle/InfoTest.java Changeset: a9258705870f Author: hb Date: 2016-03-01 09:48 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a9258705870f 8147610: javax/management/mxbean/MXBeanLoadingTest1.java assumes URLClassLoader Reviewed-by: jbachorik ! test/javax/management/mxbean/MXBeanLoadingTest1.java Changeset: d19d6f5d07dd Author: dfuchs Date: 2016-03-01 12:05 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d19d6f5d07dd 8150856: Inconsistent API documentation for @param caller in System.LoggerFinder.getLogger Summary: @throws clause is correct; @param caller documentation fixed: caller must not be null. Reviewed-by: martin ! src/java.base/share/classes/java/lang/System.java Changeset: f8dc643587de Author: dfuchs Date: 2016-03-02 11:14 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f8dc643587de 8148820: Missing @since Javadoc tag in Logger.log(Level, Supplier) Summary: Added @since 1.8 Reviewed-by: lancea, rriggs ! src/java.logging/share/classes/java/util/logging/Logger.java Changeset: 123593aacb48 Author: igerasim Date: 2016-03-02 14:10 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/123593aacb48 8149330: Capacity of StringBuilder should not get close to Integer.MAX_VALUE unless necessary Reviewed-by: martin ! src/java.base/share/classes/java/lang/AbstractStringBuilder.java + test/java/lang/StringBuilder/Capacity.java + test/java/lang/StringBuilder/HugeCapacity.java Changeset: 8c2194ad4ca3 Author: mhaupt Date: 2016-03-02 14:15 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8c2194ad4ca3 8150953: j.l.i.MethodHandles: example section in whileLoop(...) provides example for doWhileLoop Reviewed-by: psandoz ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! test/java/lang/invoke/JavaDocExamplesTest.java Changeset: 8f23f1e1e7ea Author: chegar Date: 2016-03-02 16:25 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8f23f1e1e7ea 8150976: JarFile and MRJAR tests should use the JDK specific Version API Reviewed-by: alanb, mchung ! src/java.base/share/classes/java/util/jar/JarFile.java ! test/java/util/jar/JarFile/MultiReleaseJarAPI.java ! test/java/util/jar/JarFile/MultiReleaseJarIterators.java ! test/java/util/jar/JarFile/MultiReleaseJarProperties.java ! test/java/util/jar/JarFile/MultiReleaseJarSecurity.java ! test/jdk/nio/zipfs/MultiReleaseJarTest.java Changeset: a24ddbbc4beb Author: mhaupt Date: 2016-03-02 20:16 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a24ddbbc4beb 8150635: j.l.i.MethodHandles.loop(...) throws IndexOutOfBoundsException Reviewed-by: psandoz ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! test/java/lang/invoke/T8139885.java Changeset: c48cb760984f Author: mhaupt Date: 2016-03-02 20:36 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c48cb760984f 8150832: split T8139885 into several tests by functionality Reviewed-by: redestad + test/java/lang/invoke/FindAccessTest.java + test/java/lang/invoke/FoldTest.java + test/java/lang/invoke/LoopCombinatorTest.java + test/java/lang/invoke/SpreadCollectTest.java - test/java/lang/invoke/T8139885.java + test/java/lang/invoke/TryFinallyTest.java Changeset: 6e9a5ea0feaa Author: mikael Date: 2016-03-02 13:21 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6e9a5ea0feaa 8149596: Remove java.nio.Bits copy wrapper methods Reviewed-by: bpb, chegar, psandoz ! src/java.base/share/classes/java/nio/Bits.java ! src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template Changeset: 9d2a7770ab23 Author: tvaleev Date: 2016-03-03 10:06 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9d2a7770ab23 8072727: add variation of Stream.iterate() that's finite Reviewed-by: psandoz, briangoetz ! src/java.base/share/classes/java/util/stream/DoubleStream.java ! src/java.base/share/classes/java/util/stream/IntStream.java ! src/java.base/share/classes/java/util/stream/LongStream.java ! src/java.base/share/classes/java/util/stream/Stream.java ! src/java.base/share/classes/java/util/stream/Streams.java ! test/java/util/stream/bootlib/java.base/java/util/stream/DoubleStreamTestDataProvider.java ! test/java/util/stream/bootlib/java.base/java/util/stream/IntStreamTestDataProvider.java ! test/java/util/stream/bootlib/java.base/java/util/stream/LongStreamTestDataProvider.java ! test/java/util/stream/bootlib/java.base/java/util/stream/StreamTestDataProvider.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/IterateTest.java Changeset: 677d437b4bd9 Author: tvaleev Date: 2016-03-03 10:06 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/677d437b4bd9 8147505: BaseStream.onClose() should not allow registering new handlers after stream is consumed Reviewed-by: psandoz ! src/java.base/share/classes/java/util/stream/AbstractPipeline.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamCloseTest.java Changeset: 9a83d6009bd3 Author: chegar Date: 2016-03-03 12:07 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9a83d6009bd3 8150162: Move sun.misc.Version to a truly internal package Reviewed-by: alanb, iris, mchung, rriggs ! make/gensrc/GensrcMisc.gmk ! make/mapfiles/libjava/mapfile-vers ! src/java.base/share/classes/java/lang/System.java + src/java.base/share/classes/java/lang/VersionProps.java.template - src/java.base/share/classes/sun/misc/Version.java.template - src/java.base/share/native/libjava/Version.c ! src/java.base/share/native/libjli/java.c - test/sun/misc/Version/Version.java Changeset: 3016faa53222 Author: chegar Date: 2016-03-03 12:07 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3016faa53222 8151140: Replace use of lambda/method ref in jdk.Version constructor Reviewed-by: psandoz ! src/java.base/share/classes/jdk/Version.java Changeset: e941d983c8e4 Author: mhaupt Date: 2016-03-03 14:29 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e941d983c8e4 8150957: j.l.i.MethodHandles.whileLoop(...) fails with IOOBE in the case init is null, step and pred have parameters Reviewed-by: psandoz ! test/java/lang/invoke/LoopCombinatorTest.java Changeset: 49781476b709 Author: vtewari Date: 2016-03-03 17:21 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/49781476b709 8148609: socket impl supportedOptions() should return an immutable set Reviewed-by: alanb, chegar ! src/java.base/share/classes/java/net/DatagramSocketImpl.java ! src/java.base/share/classes/java/net/SocketImpl.java + test/java/net/SocketOption/ImmutableOptions.java Changeset: eb5798a009cc Author: vtewari Date: 2016-03-03 17:27 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/eb5798a009cc 8150521: SharedSecrets.getJavaNetInetAddressAccess should ensure that InetAddress is initialised Reviewed-by: alanb, chegar ! src/java.base/share/classes/jdk/internal/misc/SharedSecrets.java Changeset: ddcb72fcf357 Author: dl Date: 2016-03-03 10:32 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ddcb72fcf357 6842353: Linux testcase failure java/util/WeakHashMap/GCDuringIteration.java Reviewed-by: martin, psandoz, darcy ! test/java/util/WeakHashMap/GCDuringIteration.java Changeset: e16d92f2b8a7 Author: dl Date: 2016-03-03 10:36 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e16d92f2b8a7 8150319: ScheduledExecutorTest:testFixedDelaySequence timeout with slow VMs Reviewed-by: martin, psandoz ! test/java/util/concurrent/tck/JSR166TestCase.java ! test/java/util/concurrent/tck/ScheduledExecutorSubclassTest.java ! test/java/util/concurrent/tck/ScheduledExecutorTest.java Changeset: 410a3ececec1 Author: dl Date: 2016-03-03 10:39 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/410a3ececec1 8150417: Make ThreadLocalRandom more robust against static initialization cycles Reviewed-by: martin, psandoz, dholmes, mhaupt ! src/java.base/share/classes/java/util/SplittableRandom.java ! src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java Changeset: a54ed9514075 Author: dl Date: 2016-03-03 10:43 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a54ed9514075 8150523: improve jtreg test timeout handling, especially -timeout: Reviewed-by: martin, psandoz, smarks ! test/java/util/concurrent/BlockingQueue/CancelledProducerConsumerLoops.java ! test/java/util/concurrent/BlockingQueue/Interrupt.java ! test/java/util/concurrent/BlockingQueue/MultipleProducersSingleConsumerLoops.java ! test/java/util/concurrent/BlockingQueue/ProducerConsumerLoops.java ! test/java/util/concurrent/BlockingQueue/SingleProducerMultipleConsumerLoops.java ! test/java/util/concurrent/CompletableFuture/Basic.java ! test/java/util/concurrent/ConcurrentHashMap/MapLoops.java ! test/java/util/concurrent/ConcurrentQueues/ConcurrentQueueLoops.java ! test/java/util/concurrent/ConcurrentQueues/GCRetention.java ! test/java/util/concurrent/CyclicBarrier/Basic.java ! test/java/util/concurrent/DelayQueue/Stress.java ! test/java/util/concurrent/Exchanger/ExchangeLoops.java ! test/java/util/concurrent/ExecutorCompletionService/ExecutorCompletionServiceLoops.java ! test/java/util/concurrent/Executors/AutoShutdown.java ! test/java/util/concurrent/FutureTask/CancelledFutureLoops.java ! test/java/util/concurrent/FutureTask/DoneMeansDone.java ! test/java/util/concurrent/ScheduledThreadPoolExecutor/DelayOverflow.java ! test/java/util/concurrent/ScheduledThreadPoolExecutor/GCRetention.java ! test/java/util/concurrent/ScheduledThreadPoolExecutor/ZeroCorePoolSize.java ! test/java/util/concurrent/ScheduledThreadPoolExecutor/ZeroCoreThreads.java ! test/java/util/concurrent/ThreadPoolExecutor/CoreThreadTimeOut.java ! test/java/util/concurrent/ThreadPoolExecutor/Custom.java ! test/java/util/concurrent/ThreadPoolExecutor/FlakyThreadFactory.java ! test/java/util/concurrent/ThreadPoolExecutor/SelfInterrupt.java ! test/java/util/concurrent/ThreadPoolExecutor/ThreadRestarts.java ! test/java/util/concurrent/ThreadPoolExecutor/TimeOutShrink.java ! test/java/util/concurrent/locks/Lock/CheckedLockLoops.java ! test/java/util/concurrent/locks/Lock/FlakyMutex.java ! test/java/util/concurrent/locks/Lock/TimedAcquireLeak.java ! test/java/util/concurrent/locks/LockSupport/ParkLoops.java ! test/java/util/concurrent/locks/ReentrantLock/LockOncePerThreadLoops.java ! test/java/util/concurrent/locks/ReentrantLock/SimpleReentrantLockLoops.java ! test/java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java ! test/java/util/concurrent/locks/ReentrantReadWriteLock/Count.java ! test/java/util/concurrent/locks/ReentrantReadWriteLock/MapLoops.java ! test/java/util/concurrent/locks/StampedLock/Basic.java Changeset: 75b933981e86 Author: dl Date: 2016-03-03 10:46 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/75b933981e86 8150416: Miscellaneous changes imported from jsr166 CVS 2016-03 Reviewed-by: martin, psandoz ! test/java/util/concurrent/tck/Collection8Test.java ! test/java/util/concurrent/tck/ThreadTest.java Changeset: a603b1f1d9a1 Author: lana Date: 2016-03-03 12:49 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a603b1f1d9a1 Merge - src/java.base/share/classes/sun/misc/Version.java.template - src/java.base/share/native/libjava/Version.c - test/java/lang/invoke/T8139885.java - test/sun/misc/Version/Version.java Changeset: 721288127c82 Author: sdrach Date: 2016-03-03 09:47 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/721288127c82 8150679: closed/javax/crypto/CryptoPermission/CallerIdentification.sh fails after fix for JDK-8132734 Summary: also fixes JDK-8150920 Reviewed-by: psandoz, redestad Contributed-by: steve.drach at oracle.com ! src/java.base/share/classes/java/util/jar/JarFile.java ! test/sun/net/www/protocol/jar/MultiReleaseJarURLConnection.java Changeset: 232843a54696 Author: shurailine Date: 2016-03-03 15:13 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/232843a54696 8150998: Fix module dependences in java/lang tests Reviewed-by: mchung ! test/java/lang/ProcessHandle/Basic.java ! test/java/lang/ProcessHandle/InfoTest.java ! test/java/lang/ProcessHandle/OnExitTest.java ! test/java/lang/ProcessHandle/TreeTest.java ! test/java/lang/StackWalker/StackStreamTest.java ! test/java/lang/System/Logger/Level/LoggerLevelTest.java ! test/java/lang/System/Logger/default/DefaultLoggerTest.java ! test/java/lang/System/LoggerFinder/DefaultLoggerFinderTest/DefaultLoggerFinderTest.java ! test/java/lang/System/LoggerFinder/internal/BootstrapLogger/BootstrapLoggerTest.java ! test/java/lang/System/LoggerFinder/internal/LoggerBridgeTest/LoggerBridgeTest.java ! test/java/lang/System/LoggerFinder/internal/PlatformLoggerBridgeTest/PlatformLoggerBridgeTest.java ! test/java/lang/System/LoggerFinder/internal/api/LoggerFinderAPITest.java ! test/java/lang/System/MacEncoding/TestFileEncoding.java ! test/java/lang/instrument/ManyMethodsBenchmarkAgent.java ! test/java/lang/instrument/RetransformAgent.java ! test/java/lang/invoke/lambda/LambdaAccessControlDoPrivilegedTest.java ! test/java/lang/invoke/lambda/LambdaAsm.java ! test/java/lang/invoke/lambda/LogGeneratedClassesTest.java ! test/java/lang/ref/CleanerTest.java Changeset: 70e358e75ba5 Author: darcy Date: 2016-03-03 15:47 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/70e358e75ba5 8151226: Mark UdpTest.java as intermittently failing Reviewed-by: lancea ! test/java/net/ipv6tests/UdpTest.java Changeset: 4fe2c0cf7b3b Author: amlu Date: 2016-03-04 13:59 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4fe2c0cf7b3b 8038330: tools/jar/JarEntryTime.java fails intermittently on checking extracted file last modified values are the current times Reviewed-by: sherman, plevart ! test/tools/jar/JarEntryTime.java Changeset: d52c28899f24 Author: darcy Date: 2016-03-03 22:55 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d52c28899f24 8151228: Mark TestDSAGenParameterSpec.java as intermittently failing Reviewed-by: xuelei ! test/sun/security/provider/NSASuiteB/TestDSAGenParameterSpec.java Changeset: efeef5749c28 Author: rpatil Date: 2016-03-02 23:28 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/efeef5749c28 8087104: DateFormatSymbols triggers this.clone() in the constructor Summary: Instead of using its own instance for caching and calling clone in DateFormatSymbols, a nested class SymbolsCacheEntry is introduced. Reviewed-by: okutsu, peytoia ! src/java.base/share/classes/java/text/DateFormatSymbols.java + test/java/text/Format/DateFormat/DFSConstructorCloneTest.java Changeset: 124d07ef3b32 Author: xuelei Date: 2016-03-04 14:04 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/124d07ef3b32 8148108: Disable Diffie-Hellman keys less than 1024 bits Reviewed-by: vinnie, mullan ! src/java.base/share/conf/security/java.security + test/sun/security/ssl/DHKeyExchange/LegacyDHEKeyExchange.java Changeset: bc2722be85be Author: erikj Date: 2016-03-04 17:05 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/bc2722be85be 8151297: Class name change for CLDRLocaleDataMetaInfo_jdk_localedata needs updating in makefile Reviewed-by: alanb ! make/gensrc/GensrcCLDR.gmk Changeset: 60ea1a15d560 Author: erikj Date: 2016-03-04 18:36 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/60ea1a15d560 8151302: Attempt at silencing build log broke html32.bdtd Reviewed-by: mchung ! make/gendata/GendataHtml32dtd.gmk Changeset: f36a67535bfb Author: darcy Date: 2016-03-04 10:09 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f36a67535bfb 8151225: Mark SpecTest.java as intermittently failing Reviewed-by: mullan ! test/sun/security/rsa/SpecTest.java Changeset: 4ee6d4809d3f Author: amlu Date: 2016-03-05 10:30 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4ee6d4809d3f 8151286: Remove intermittent key from TestLocalTime.java and move back to tier1 Reviewed-by: darcy ! test/TEST.groups ! test/java/util/zip/TestLocalTime.java Changeset: d920311e7871 Author: amlu Date: 2016-03-05 10:34 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d920311e7871 8151263: Mark java/rmi test LeaseCheckInterval.java as intermittently failing Reviewed-by: darcy ! test/java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java Changeset: 1c352638984e Author: vinnie Date: 2016-03-07 14:52 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1c352638984e 8151149: CipherSpi implementation of PBEWithSHA1AndDESede returns key size in bytes Reviewed-by: xuelei ! src/java.base/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java + test/com/sun/crypto/provider/Cipher/PBE/CheckPBEKeySize.java Changeset: c76255da3ec0 Author: mullan Date: 2016-03-07 10:10 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c76255da3ec0 8138653: Default key sizes for the AlgorithmParameterGenerator and KeyPairGenerator implementations should be upgraded Reviewed-by: coffeys, vinnie ! src/java.base/share/classes/com/sun/crypto/provider/DHKeyPairGenerator.java ! src/java.base/share/classes/com/sun/crypto/provider/DHParameterGenerator.java ! src/java.base/share/classes/java/security/KeyPairGenerator.java ! src/java.base/share/classes/sun/security/rsa/RSAKeyPairGenerator.java ! src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/RSAKeyPairGenerator.java ! src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/SunMSCAPI.java ! src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11KeyPairGenerator.java ! test/com/sun/crypto/provider/KeyAgreement/TestExponentSize.java ! test/sun/security/pkcs11/PKCS11Test.java Changeset: 15a99a1f2d88 Author: mullan Date: 2016-03-07 10:11 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/15a99a1f2d88 Merge Changeset: dea5c036cb15 Author: sdrach Date: 2016-03-07 19:37 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/dea5c036cb15 8151339: Adding fragment to JAR URLs breaks ant Reviewed-by: alanb ! src/java.base/share/classes/sun/misc/URLClassPath.java Changeset: 7d878555b604 Author: ddehaven Date: 2016-02-25 15:42 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7d878555b604 8132743: Move netscape.javascript package from jdk.plugin to new module Reviewed-by: kcr, mchung, alanb ! make/src/classes/build/tools/module/boot.modules + src/jdk.jsobject/share/classes/jdk/internal/netscape/javascript/spi/JSObjectProvider.java + src/jdk.jsobject/share/classes/netscape/javascript/JSException.java + src/jdk.jsobject/share/classes/netscape/javascript/JSObject.java + src/jdk.jsobject/share/classes/netscape/javascript/package-info.java Changeset: 1c7bad079890 Author: darcy Date: 2016-03-07 12:10 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1c7bad079890 8151393: Revert changes for JDK-8087104 Reviewed-by: alanb ! src/java.base/share/classes/java/text/DateFormatSymbols.java - test/java/text/Format/DateFormat/DFSConstructorCloneTest.java Changeset: d5ff178e50c1 Author: henryjen Date: 2016-03-09 18:48 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d5ff178e50c1 Merge ! make/gendata/GendataHtml32dtd.gmk ! make/gensrc/GensrcCLDR.gmk ! make/gensrc/GensrcMisc.gmk ! make/mapfiles/libjava/mapfile-vers ! 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/nio/Bits.java ! src/java.base/share/classes/jdk/internal/misc/SharedSecrets.java ! src/java.base/share/classes/sun/misc/URLClassPath.java - src/java.base/share/classes/sun/misc/Version.java.template ! src/java.base/share/conf/security/java.security - src/java.base/share/native/libjava/Version.c ! src/java.base/share/native/libjli/java.c ! src/java.logging/share/classes/java/util/logging/Logger.java ! src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/RSAKeyPairGenerator.java + src/jdk.jsobject/share/classes/module-info.java ! test/TEST.groups ! test/java/lang/instrument/RetransformAgent.java - test/java/lang/invoke/T8139885.java ! test/java/lang/invoke/lambda/LambdaAccessControlDoPrivilegedTest.java ! test/java/lang/invoke/lambda/LambdaAsm.java - test/sun/misc/Version/Version.java ! test/sun/security/pkcs11/PKCS11Test.java Changeset: 99688f1402fa Author: henryjen Date: 2016-03-09 18:50 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/99688f1402fa Merge - src/java.base/share/classes/sun/misc/Version.java.template - src/java.base/share/native/libjava/Version.c - test/java/lang/invoke/T8139885.java - test/sun/misc/Version/Version.java Changeset: d583edbd04c8 Author: mchung Date: 2016-03-09 20:30 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d583edbd04c8 Define jdk.jsobject by ext class loader ! make/gensrc/GensrcModuleLoaderMap.gmk ! src/java.base/share/conf/security/java.policy ! src/jdk.jsobject/share/classes/module-info.java Changeset: a3c4da65e373 Author: mchung Date: 2016-03-09 20:43 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a3c4da65e373 Merge ! make/gensrc/GensrcModuleLoaderMap.gmk - src/java.base/share/classes/sun/misc/Version.java.template - src/java.base/share/native/libjava/Version.c - test/java/lang/invoke/T8139885.java - test/sun/misc/Version/Version.java Changeset: 0a1fad9b5a1f Author: mchung Date: 2016-03-10 09:26 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0a1fad9b5a1f Merge From mandy.chung at oracle.com Thu Mar 10 17:55:13 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 10 Mar 2016 17:55:13 +0000 Subject: hg: jigsaw/jake/langtools: 15 new changesets Message-ID: <201603101755.u2AHtEOc026219@aojmv0008.oracle.com> Changeset: 20c4b78bf457 Author: alundblad Date: 2016-03-02 12:54 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/20c4b78bf457 8150941: Sjavac should not wait for portfile to materialize if server process is terminated Summary: Sjavac cancels forking early if server process dies. Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/client/SjavacClient.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/PortFile.java Changeset: 01b00ac6bc18 Author: alundblad Date: 2016-03-02 13:12 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/01b00ac6bc18 8061320: Sjavac should prevent using source dir as dest dir Summary: Sjavac now makes sure that src and dst dirs do not overlap. Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/SjavacImpl.java + test/tools/sjavac/OverlappingSrcDst.java Changeset: cb0309f4983f Author: sadayapalam Date: 2016-03-02 19:09 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/cb0309f4983f 8151016: Migrate asserts introduced in Valhalla code generation to JDK9 dev Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java Changeset: 61980f5f4e38 Author: bpatel Date: 2016-03-02 21:27 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/61980f5f4e38 8148985: javadoc "FRAMES" and "NO FRAMES" links not working correctly Reviewed-by: jjg, ksrini ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/FrameOutputWriter.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/FrameOutputWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlWriter.java ! test/com/sun/javadoc/testHtmlVersion/TestHtmlVersion.java ! test/com/sun/javadoc/testJavascript/TestJavascript.java ! test/jdk/javadoc/doclet/testHtmlVersion/TestHtmlVersion.java ! test/jdk/javadoc/doclet/testJavascript/TestJavascript.java Changeset: 5c59fd4607e5 Author: ksrini Date: 2016-03-02 15:00 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/5c59fd4607e5 8150895: Fix bug id in test for JDK-8149842 Reviewed-by: bpatel ! test/jdk/javadoc/doclet/testIncluded/TestIncluded.java Changeset: aaa527f80b3b Author: sadayapalam Date: 2016-03-03 06:10 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/aaa527f80b3b 8151018: javac should emit a clearer diagnostic when a <> inferred anonymous type's non-private methods don't override super's Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/DiamondMethodDoesNotOverride.java ! test/tools/javac/generics/diamond/neg/Neg15.out Changeset: d061b06552eb Author: sadayapalam Date: 2016-03-03 15:07 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/d061b06552eb 8151134: Fix bug id in test for JDK-8151018 Reviewed-by: jlahoda ! test/tools/javac/generics/diamond/neg/Neg15.java Changeset: 178ce5786775 Author: alundblad Date: 2016-03-03 15:53 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/178ce5786775 8151141: Sjavac fails to fork server on Windows Summary: Reverted changeset 3269:20c4b78bf457. Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/client/SjavacClient.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/PortFile.java Changeset: 8000338dd45a Author: lana Date: 2016-03-03 12:48 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/8000338dd45a Merge Changeset: e90d9efcb13f Author: ksrini Date: 2016-03-03 14:54 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/e90d9efcb13f 8150130: NPE building javafx docs with new doclet Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocTreeMaker.java ! test/jdk/javadoc/doclet/testJavaFX/TestJavaFX.java + test/jdk/javadoc/doclet/testJavaFX/pkg4/C.java Changeset: f8aebd55b8f5 Author: ksrini Date: 2016-03-05 07:53 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/f8aebd55b8f5 8150000: Javadoc omits package listing for type Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css ! test/jdk/javadoc/doclet/testSubTitle/TestSubTitle.java Changeset: f5991c73ed73 Author: sadayapalam Date: 2016-03-07 18:49 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/f5991c73ed73 8148930: Incorrect erasure of exceptions in override-equivalent dual interface impl Summary: Before computing intersection of thrown types, javac must make sure type variables come from the same set. Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/generics/inference/CheckNoTimeoutException.java + test/tools/javac/generics/inference/IntersectThrownTypesTest.java + test/tools/javac/generics/inference/IntersectThrownTypesTest.out Changeset: ef229332fb57 Author: henryjen Date: 2016-03-09 18:48 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/ef229332fb57 Merge ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/SjavacImpl.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css ! test/com/sun/javadoc/testHtmlVersion/TestHtmlVersion.java ! test/jdk/javadoc/doclet/testHtmlVersion/TestHtmlVersion.java ! test/jdk/javadoc/doclet/testJavaFX/TestJavaFX.java ! test/jdk/javadoc/doclet/testJavascript/TestJavascript.java ! test/jdk/javadoc/doclet/testSubTitle/TestSubTitle.java + test/tools/sjavac/OverlappingSrcDst.java Changeset: 394ddcc18338 Author: henryjen Date: 2016-03-09 18:50 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/394ddcc18338 Merge Changeset: 6d84ba2711b3 Author: mchung Date: 2016-03-10 09:26 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/6d84ba2711b3 Merge From pbenedict at apache.org Thu Mar 10 18:27:09 2016 From: pbenedict at apache.org (Paul Benedict) Date: Thu, 10 Mar 2016 12:27:09 -0600 Subject: Unnamed module and duplicate package In-Reply-To: <56E0AE10.80300@oracle.com> References: <56E089E3.8040204@oracle.com> <56E097B5.9040201@oracle.com> <56E0AE10.80300@oracle.com> Message-ID: Alex, there are JARs that contain javax packages. Anyone in the web development community knows how many people have included xml-apis in their WEB-INF :-) only to find out it wasn't loaded or it took precedent over the JDK versions. Has Jigsaw introduced any restrictions here on this front? Honestly, I think the JDK should make it illegal for the classpath to contain ANY packages that the jdk has. Please opine when it is convenient for you. Cheers, Paul On Wed, Mar 9, 2016 at 5:13 PM, Alex Buckley wrote: > Paul, thank you for asking. The module system's treatment of the unnamed > module vis-a-vis named modules is probably the biggest factor affecting > usability of the module system. This is true almost by definition because > at JDK 9 GA the only named modules in the world will be the JDK's while > every other class will be in the unnamed module of the application class > loader. > > So please, ask more questions about the unnamed module. I am especially > interested to know if anyone has JARs that contain javax packages (or > heaven forbid, sun or com.sun packages) found in the JDK -- such JARs are a > mortal danger to interop between unnamed and named modules. > > Alex > > On 3/9/2016 1:47 PM, Paul Benedict wrote: > >> Thank you Alex. Since it's roughly the same as JDK 8, then it's also not >> worse. I defer to your explanation on that point. >> >> Cheers, >> Paul >> >> On Wed, Mar 9, 2016 at 3:37 PM, Alex Buckley > > wrote: >> >> Presumably you would count the equivalent scenario on JDK 8 -- my >> package A is in Alex.jar on the classpath and your package A is in >> Paul.jar on the classpath -- as a security issue too, because some >> of my classes may substitute for yours (or some of yours for mine, >> depending on how the classpath is constructed). >> >> On JDK 9, we do the "substitution" cleanly. Package A is not split. >> That avoids one category of error (ClassCastException). What about >> poor package B that finds itself accessing a different package A >> than it was compiled with? Well, since package A is exported by a >> named module, it's reasonable to assume that the named module "owns" >> package A [*], and that the developer of package B co-bundled some >> version of package A without renaming it. Dangerous in JDK 8, >> dangerous in JDK 9. (We're trying to encapsulate the internals of a >> module, which is different from trying to isolate modules from each >> other.) >> >> [*] Advanced scenario: the named module exporting A is actually an >> automatic module which happened to co-bundle package A. By placing >> this JAR on the modulepath to form an automatic module, it dominates >> the JAR left on the classpath which also co-bundled package A. >> >> Alex >> >> On 3/9/2016 1:17 PM, Paul Benedict wrote: >> >> But isn't what your proposing a security issue? Let's say my >> package A >> is in the unnamed module and your package A is in a named >> module. You >> basically took over my code; your classes will be substituted >> for mine. >> >> Cheers, >> Paul >> >> On Wed, Mar 9, 2016 at 2:38 PM, Alex Buckley >> >> > >> >> wrote: >> >> On 3/9/2016 10:36 AM, Paul Benedict wrote: >> >> From the doc: >> "If a package is defined in both a named module and the >> unnamed >> module then >> the package in the unnamed module is ignored. This >> preserves >> reliable >> configuration even in the face of the chaos of the >> class path, >> ensuring >> that every module still reads at most one module >> defining a >> given package. >> If, in our example above, a JAR file on the class path >> contains >> a class >> file named com/foo/bar/alpha/AlphaFactory.class then >> that file >> will never >> be loaded, since the com.foo.bar.alpha package is >> exported by the >> com.foo.bar module." >> >> I would like some clarification. Correct me if wrong, >> but I >> think this >> entire paragraph is really meant to be about the >> perspective from a >> modularized JAR? If a module has package A, and the >> unnamed >> module has >> package A, then of course the module's package A should >> win. >> >> However, if it is meant to be absolute language, then I >> disagree. >> >> The unnamed module should be coherent among itself. If >> the >> unnamed module >> has package B and relies on classes from package A, it >> should >> still be able >> to see its own package A. I don't think modules should >> be able >> to impact >> how the unnamed module sees itself. That's a surprising >> situation. >> >> >> The unnamed module is not a root module during resolution. >> If your >> main class is in the unnamed module (i.e. you did java -jar >> MyApp.jar rather than java -m MyApp), then the module graph >> is >> created by resolving various root modules (what are they? >> separate >> discussion) and only then is the unnamed module hooked up >> to read >> every module in the graph. >> >> Hope we're OK so far. >> >> If some named module in the graph exports package A (more >> than one >> module exporting A? separate discussion), then since the >> unnamed >> module reads that named module, the unnamed module will >> access A.* >> types from that named module. >> >> It's hard to imagine the unnamed module NOT accessing A.* >> types from >> that named module. Primarily, we need to avoid a split >> package >> situation where code in the unnamed module sometimes >> accesses A.* >> types from the named module and sometimes from the unnamed >> module. >> >> You might say, OK, let code in the unnamed module >> exclusively access >> A.* in the unnamed module rather than exclusively access >> A.* in the >> named module. Then you have two problems: >> >> 1. There are issues for named modules in the same class >> loader as >> the unnamed module -- such named modules MUST get A.* from >> the named >> module rather than the unnamed module, and the class loading >> mechanism is incapable of switching based on accessor. It'll >> be >> common for named modules to exist in the same class loader >> as the >> unnamed module, as modular JARs on the modulepath and >> non-modular >> JARs on the classpath all end up in the application class >> loader >> (modular JARs as named modules; non-modular JARs jointly as >> the >> unnamed module). >> >> 2. While the module system is sure that package A exists in >> the >> named module, how would the module system possibly know >> that package >> A exists in the unnamed module? Scanning every class file >> in every >> non-modular JAR on the classpath at startup sounds bad. >> >> Alex >> >> >> >> From mandy.chung at oracle.com Thu Mar 10 19:23:31 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 10 Mar 2016 19:23:31 +0000 Subject: hg: jigsaw/jake/langtools: Fix GenModuleInfo.java failing on windows Message-ID: <201603101923.u2AJNVOq002720@aojmv0008.oracle.com> Changeset: 5bc1e98df6d3 Author: mchung Date: 2016-03-10 11:23 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/5bc1e98df6d3 Fix GenModuleInfo.java failing on windows ! test/tools/jdeps/modules/GenModuleInfo.java From christian.tornqvist at oracle.com Thu Mar 10 20:19:03 2016 From: christian.tornqvist at oracle.com (christian.tornqvist at oracle.com) Date: Thu, 10 Mar 2016 20:19:03 +0000 Subject: hg: jigsaw/jake/hotspot: Renamed tests based on feedback Message-ID: <201603102019.u2AKJ43G026227@aojmv0008.oracle.com> Changeset: 7d54046f40aa Author: gtriantafill Date: 2016-03-10 12:17 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7d54046f40aa Renamed tests based on feedback + test/runtime/modules/AccessCheck/CheckRead.java + test/runtime/modules/AccessCheck/DiffCL_CheckRead.java + test/runtime/modules/AccessCheck/DiffCL_ExpQualOther.java + test/runtime/modules/AccessCheck/DiffCL_ExpQualToM1.java + test/runtime/modules/AccessCheck/DiffCL_ExpUnqual.java + test/runtime/modules/AccessCheck/DiffCL_PkgNotExp.java + test/runtime/modules/AccessCheck/DiffCL_Umod.java + test/runtime/modules/AccessCheck/DiffCL_UmodUpkg.java + test/runtime/modules/AccessCheck/ExpQualOther.java + test/runtime/modules/AccessCheck/ExpQualToM1.java + test/runtime/modules/AccessCheck/ExpUnqual.java - test/runtime/modules/AccessCheck/NmodNpkgDiffCL_CheckRead.java - test/runtime/modules/AccessCheck/NmodNpkgDiffCL_PkgExpQualOther.java - test/runtime/modules/AccessCheck/NmodNpkgDiffCL_PkgExpQualToM1.java - test/runtime/modules/AccessCheck/NmodNpkgDiffCL_PkgExpUnqual.java - test/runtime/modules/AccessCheck/NmodNpkgDiffCL_PkgNotExp.java - test/runtime/modules/AccessCheck/NmodNpkgDiffCL_UmodNpkg.java - test/runtime/modules/AccessCheck/NmodNpkgDiffCL_UmodUpkg.java - test/runtime/modules/AccessCheck/NmodNpkg_CheckRead.java - test/runtime/modules/AccessCheck/NmodNpkg_PkgExpQualOther.java - test/runtime/modules/AccessCheck/NmodNpkg_PkgExpQualToM1.java - test/runtime/modules/AccessCheck/NmodNpkg_PkgExpUnqual.java - test/runtime/modules/AccessCheck/NmodNpkg_PkgNotExp.java - test/runtime/modules/AccessCheck/NmodNpkg_UmodNpkg.java - test/runtime/modules/AccessCheck/NmodNpkg_UmodUPkg.java + test/runtime/modules/AccessCheck/PkgNotExp.java + test/runtime/modules/AccessCheck/Umod.java + test/runtime/modules/AccessCheck/UmodDiffCL_ExpQualOther.java + test/runtime/modules/AccessCheck/UmodDiffCL_ExpUnqual.java + test/runtime/modules/AccessCheck/UmodDiffCL_PkgNotExp.java + test/runtime/modules/AccessCheck/UmodDiffCL_Umod.java + test/runtime/modules/AccessCheck/UmodDiffCL_UmodUpkg.java - test/runtime/modules/AccessCheck/UmodNpkgDiffCL_PkgExpQualOther.java - test/runtime/modules/AccessCheck/UmodNpkgDiffCL_PkgExpUnqual.java - test/runtime/modules/AccessCheck/UmodNpkgDiffCL_PkgNotExp.java - test/runtime/modules/AccessCheck/UmodNpkgDiffCL_UmodNpkg.java - test/runtime/modules/AccessCheck/UmodNpkgDiffCL_UmodUpkg.java - test/runtime/modules/AccessCheck/UmodNpkg_PkgExpQualOther.java - test/runtime/modules/AccessCheck/UmodNpkg_PkgExpUnqual.java - test/runtime/modules/AccessCheck/UmodNpkg_PkgNotExp.java - test/runtime/modules/AccessCheck/UmodNpkg_UmodUpkg.java + test/runtime/modules/AccessCheck/UmodUPkg.java + test/runtime/modules/AccessCheck/UmodUpkgDiffCL_ExpQualOther.java + test/runtime/modules/AccessCheck/UmodUpkgDiffCL_NotExp.java - test/runtime/modules/AccessCheck/UmodUpkgDiffCL_PkgExpQualOther.java - test/runtime/modules/AccessCheck/UmodUpkgDiffCL_PkgNotExp.java + test/runtime/modules/AccessCheck/UmodUpkgDiffCL_Umod.java - test/runtime/modules/AccessCheck/UmodUpkgDiffCL_UmodNpkg.java + test/runtime/modules/AccessCheck/UmodUpkg_ExpQualOther.java + test/runtime/modules/AccessCheck/UmodUpkg_NotExp.java - test/runtime/modules/AccessCheck/UmodUpkg_PkgExpQualOther.java - test/runtime/modules/AccessCheck/UmodUpkg_PkgNotExp.java + test/runtime/modules/AccessCheck/UmodUpkg_Umod.java - test/runtime/modules/AccessCheck/UmodUpkg_UmodNpkg.java + test/runtime/modules/AccessCheck/Umod_ExpQualOther.java + test/runtime/modules/AccessCheck/Umod_ExpUnqual.java + test/runtime/modules/AccessCheck/Umod_PkgNotExp.java + test/runtime/modules/AccessCheck/Umod_UmodUpkg.java From alex.buckley at oracle.com Thu Mar 10 20:30:21 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 10 Mar 2016 12:30:21 -0800 Subject: Unnamed module and duplicate package In-Reply-To: References: <56E089E3.8040204@oracle.com> <56E097B5.9040201@oracle.com> <56E0AE10.80300@oracle.com> Message-ID: <56E1D95D.4090209@oracle.com> I see xml-apis.jar (2.0.2) contains: - a javax.xml.parser package, which includes a FactoryFinder class that's not in Java SE, and - a javax.xml.transform package hierarchy, whose types at first glance look identical to those in Java SE except for yet another FactoryFinder class in javax.xml.transform. If you put xml-apis.jar on the classpath, its javax.xml.** packages will be ignored. The unnamed module reads the java.xml module which exports javax.xml.** packages (assuming java.xml in the system image, of course), so the application class loader delegates for javax.xml.** packages to the loader responsible for the java.xml module. User code that tries to access FactoryFinder will get a NoClassDefFoundError. There's nothing special about JDK modules here. The same NoClassDefFoundError would occur if the system image contained a module exporting some package, and a JAR on the classpath contained the same package with extra classes, and some code on the classpath tried to access those extra classes. Since the module in the system image is probably the rightful owner/exporter of the package, hard questions should be asked about the provenance of the JAR on the classpath. There has been some discussion of a jdeps-like tool that detects when a JAR on your classpath is trying to split a JDK package: http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-November/005227.html. Alex On 3/10/2016 10:27 AM, Paul Benedict wrote: > Alex, there are JARs that contain javax packages. Anyone in the web > development community knows how many people have included xml-apis in > their WEB-INF :-) only to find out it wasn't loaded or it took precedent > over the JDK versions. > > Has Jigsaw introduced any restrictions here on this front? Honestly, I > think the JDK should make it illegal for the classpath to contain ANY > packages that the jdk has. Please opine when it is convenient for you. > > Cheers, > Paul > > On Wed, Mar 9, 2016 at 5:13 PM, Alex Buckley > wrote: > > Paul, thank you for asking. The module system's treatment of the > unnamed module vis-a-vis named modules is probably the biggest > factor affecting usability of the module system. This is true almost > by definition because at JDK 9 GA the only named modules in the > world will be the JDK's while every other class will be in the > unnamed module of the application class loader. > > So please, ask more questions about the unnamed module. I am > especially interested to know if anyone has JARs that contain javax > packages (or heaven forbid, sun or com.sun packages) found in the > JDK -- such JARs are a mortal danger to interop between unnamed and > named modules. > > Alex > > On 3/9/2016 1:47 PM, Paul Benedict wrote: > > Thank you Alex. Since it's roughly the same as JDK 8, then it's > also not > worse. I defer to your explanation on that point. > > Cheers, > Paul > > On Wed, Mar 9, 2016 at 3:37 PM, Alex Buckley > > >> wrote: > > Presumably you would count the equivalent scenario on JDK 8 > -- my > package A is in Alex.jar on the classpath and your package > A is in > Paul.jar on the classpath -- as a security issue too, > because some > of my classes may substitute for yours (or some of yours > for mine, > depending on how the classpath is constructed). > > On JDK 9, we do the "substitution" cleanly. Package A is > not split. > That avoids one category of error (ClassCastException). > What about > poor package B that finds itself accessing a different > package A > than it was compiled with? Well, since package A is > exported by a > named module, it's reasonable to assume that the named > module "owns" > package A [*], and that the developer of package B > co-bundled some > version of package A without renaming it. Dangerous in JDK 8, > dangerous in JDK 9. (We're trying to encapsulate the > internals of a > module, which is different from trying to isolate modules > from each > other.) > > [*] Advanced scenario: the named module exporting A is > actually an > automatic module which happened to co-bundle package A. By > placing > this JAR on the modulepath to form an automatic module, it > dominates > the JAR left on the classpath which also co-bundled package A. > > Alex > > On 3/9/2016 1:17 PM, Paul Benedict wrote: > > But isn't what your proposing a security issue? Let's > say my > package A > is in the unnamed module and your package A is in a named > module. You > basically took over my code; your classes will be > substituted > for mine. > > Cheers, > Paul > > On Wed, Mar 9, 2016 at 2:38 PM, Alex Buckley > > > > > >>> wrote: > > On 3/9/2016 10:36 AM, Paul Benedict wrote: > > From the doc: > "If a package is defined in both a named > module and the > unnamed > module then > the package in the unnamed module is ignored. This > preserves > reliable > configuration even in the face of the chaos of the > class path, > ensuring > that every module still reads at most one > module defining a > given package. > If, in our example above, a JAR file on the > class path > contains > a class > file named > com/foo/bar/alpha/AlphaFactory.class then > that file > will never > be loaded, since the com.foo.bar.alpha package is > exported by the > com.foo.bar module." > > I would like some clarification. Correct me if > wrong, but I > think this > entire paragraph is really meant to be about the > perspective from a > modularized JAR? If a module has package A, > and the unnamed > module has > package A, then of course the module's package > A should > win. > > However, if it is meant to be absolute > language, then I > disagree. > > The unnamed module should be coherent among > itself. If the > unnamed module > has package B and relies on classes from > package A, it > should > still be able > to see its own package A. I don't think > modules should > be able > to impact > how the unnamed module sees itself. That's a > surprising > situation. > > > The unnamed module is not a root module during > resolution. > If your > main class is in the unnamed module (i.e. you did > java -jar > MyApp.jar rather than java -m MyApp), then the > module graph is > created by resolving various root modules (what > are they? > separate > discussion) and only then is the unnamed module > hooked up > to read > every module in the graph. > > Hope we're OK so far. > > If some named module in the graph exports package > A (more > than one > module exporting A? separate discussion), then > since the > unnamed > module reads that named module, the unnamed module > will > access A.* > types from that named module. > > It's hard to imagine the unnamed module NOT > accessing A.* > types from > that named module. Primarily, we need to avoid a > split package > situation where code in the unnamed module sometimes > accesses A.* > types from the named module and sometimes from the > unnamed > module. > > You might say, OK, let code in the unnamed module > exclusively access > A.* in the unnamed module rather than exclusively > access > A.* in the > named module. Then you have two problems: > > 1. There are issues for named modules in the same > class > loader as > the unnamed module -- such named modules MUST get > A.* from > the named > module rather than the unnamed module, and the > class loading > mechanism is incapable of switching based on > accessor. It'll be > common for named modules to exist in the same > class loader > as the > unnamed module, as modular JARs on the modulepath and > non-modular > JARs on the classpath all end up in the > application class > loader > (modular JARs as named modules; non-modular JARs > jointly as the > unnamed module). > > 2. While the module system is sure that package A > exists in the > named module, how would the module system possibly > know > that package > A exists in the unnamed module? Scanning every > class file > in every > non-modular JAR on the classpath at startup sounds > bad. > > Alex > > > > From alex.buckley at oracle.com Thu Mar 10 21:22:25 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 10 Mar 2016 13:22:25 -0800 Subject: Unnamed module and duplicate package In-Reply-To: References: <56E089E3.8040204@oracle.com> <56E097B5.9040201@oracle.com> <3AD054BA-035F-44A6-9636-8238016E049F@oracle.com> <56E0D466.9090605@oracle.com> Message-ID: <56E1E591.9060801@oracle.com> Yes, we can keep tightening the split package scenario to ensure safety without scanning the classpath. First, you have to promise that the JAR on the classpath never has classes that overlap with a module in the system image. Second, the named module of interest in the system image can't be a framework that reflects over classes in the unnamed module (thus sidestepping bugs about "Where did this class in my package come from? It's not my codesource! I can't load it starting from my loader!"). To put it mildly, this isn't what we had in mind for "reliable dependencies". You also have to consider why the split package occurs at all. Your classpath JAR might simply be adding public types that you feel a module in the image should have had all along. Other people will offer up a classpath JAR that adds public types to access and return package-private content of a module in the image. This won't work for most JDK modules, since they're defined by a different loader than the unnamed module, but it would work for some JDK modules and for all user modules. To put it mildly, this isn't what we had in mind for "strong encapsulation". Alex On 3/9/2016 7:14 PM, Russell Gold wrote: > This should, however, be completely safe in the case when one of > those modules is part of the JDK itself, isn?t it? It is not clear to > me how you could ever get a circular dependency in that case. > > In fact, this should be true of any library as well - the only > scenario that I can think of where you could get this mess is if a > developer compiles a bunch of classes, and then deliberately creates > circularity between modules by putting some of those classes into a > named module and some into the unnamed module, which seems incredibly > unlikely. > > If there an actual plausible scenario from which you are hoping to > protect developers with this restriction? > > - Russ > >> On Mar 9, 2016, at 8:56 PM, Alex Buckley >> wrote: >> >> Yes, a ClassCastException could only arise when (sticking with >> Paul's scenario) the same class exists in both the named module and >> the unnamed module. >> >> It would be "safe" for the module system to allow a package that is >> split perfectly between modules: no overlap of classes and no >> cyclic references between members. This is checkable when a package >> is split between two named modules that the resolver can observe in >> great detail. (You don't even need to check no-cyclic-references, >> since it's dominated by the no-cyclic-dependencies rule for the >> modules -- basically the split has to be perfect for the package to >> work at all.) >> >> But in the case of a package split between a named module and the >> unnamed module, the check is basically impossible, since the >> resolver can't enumerate the A.* types in the unnamed module >> without scanning the classpath, which sounds bad. >> >> tl;dr We don't want a lot of gymnastics in the module system to >> support a known-bad idiom which most Java developers will never >> come across. ("most" means "in the millions".) >> >> Alex >> >> On 3/9/2016 5:16 PM, Russell Gold wrote: >>> Doesn?t this kind of error only happen when a second module >>> exports the same _class_? What is the problem with another class >>> being defined in the same package, given that package B isn?t >>> going to access that new class at all? >>> >>> - Russ >>> >>>> On Mar 9, 2016, at 4:37 PM, Alex Buckley >>>> wrote: >>>> >>>> Presumably you would count the equivalent scenario on JDK 8 -- >>>> my package A is in Alex.jar on the classpath and your package A >>>> is in Paul.jar on the classpath -- as a security issue too, >>>> because some of my classes may substitute for yours (or some of >>>> yours for mine, depending on how the classpath is >>>> constructed). >>>> >>>> On JDK 9, we do the "substitution" cleanly. Package A is not >>>> split. That avoids one category of error (ClassCastException). >>>> What about poor package B that finds itself accessing a >>>> different package A than it was compiled with? Well, since >>>> package A is exported by a named module, it's reasonable to >>>> assume that the named module "owns" package A [*], and that the >>>> developer of package B co-bundled some version of package A >>>> without renaming it. Dangerous in JDK 8, dangerous in JDK 9. >>>> (We're trying to encapsulate the internals of a module, which >>>> is different from trying to isolate modules from each other.) >>>> >>>> [*] Advanced scenario: the named module exporting A is actually >>>> an automatic module which happened to co-bundle package A. By >>>> placing this JAR on the modulepath to form an automatic module, >>>> it dominates the JAR left on the classpath which also >>>> co-bundled package A. >>>> >>>> Alex >>>> >>>> On 3/9/2016 1:17 PM, Paul Benedict wrote: >>>>> But isn't what your proposing a security issue? Let's say my >>>>> package A is in the unnamed module and your package A is in >>>>> a named module. You basically took over my code; your classes >>>>> will be substituted for mine. >>>>> >>>>> Cheers, Paul >>>>> >>>>> On Wed, Mar 9, 2016 at 2:38 PM, Alex Buckley >>>>> > >>>>> wrote: >>>>> >>>>> On 3/9/2016 10:36 AM, Paul Benedict wrote: >>>>> >>>>> From the doc: "If a package is defined in both a named module >>>>> and the unnamed module then the package in the unnamed module >>>>> is ignored. This preserves reliable configuration even in the >>>>> face of the chaos of the class path, ensuring that every >>>>> module still reads at most one module defining a given >>>>> package. If, in our example above, a JAR file on the class >>>>> path contains a class file named >>>>> com/foo/bar/alpha/AlphaFactory.class then that file will >>>>> never be loaded, since the com.foo.bar.alpha package is >>>>> exported by the com.foo.bar module." >>>>> >>>>> I would like some clarification. Correct me if wrong, but I >>>>> think this entire paragraph is really meant to be about the >>>>> perspective from a modularized JAR? If a module has package >>>>> A, and the unnamed module has package A, then of course the >>>>> module's package A should win. >>>>> >>>>> However, if it is meant to be absolute language, then I >>>>> disagree. >>>>> >>>>> The unnamed module should be coherent among itself. If the >>>>> unnamed module has package B and relies on classes from >>>>> package A, it should still be able to see its own package A. >>>>> I don't think modules should be able to impact how the >>>>> unnamed module sees itself. That's a surprising situation. >>>>> >>>>> >>>>> The unnamed module is not a root module during resolution. >>>>> If your main class is in the unnamed module (i.e. you did >>>>> java -jar MyApp.jar rather than java -m MyApp), then the >>>>> module graph is created by resolving various root modules >>>>> (what are they? separate discussion) and only then is the >>>>> unnamed module hooked up to read every module in the graph. >>>>> >>>>> Hope we're OK so far. >>>>> >>>>> If some named module in the graph exports package A (more >>>>> than one module exporting A? separate discussion), then since >>>>> the unnamed module reads that named module, the unnamed >>>>> module will access A.* types from that named module. >>>>> >>>>> It's hard to imagine the unnamed module NOT accessing A.* >>>>> types from that named module. Primarily, we need to avoid a >>>>> split package situation where code in the unnamed module >>>>> sometimes accesses A.* types from the named module and >>>>> sometimes from the unnamed module. >>>>> >>>>> You might say, OK, let code in the unnamed module >>>>> exclusively access A.* in the unnamed module rather than >>>>> exclusively access A.* in the named module. Then you have two >>>>> problems: >>>>> >>>>> 1. There are issues for named modules in the same class >>>>> loader as the unnamed module -- such named modules MUST get >>>>> A.* from the named module rather than the unnamed module, and >>>>> the class loading mechanism is incapable of switching based >>>>> on accessor. It'll be common for named modules to exist in >>>>> the same class loader as the unnamed module, as modular JARs >>>>> on the modulepath and non-modular JARs on the classpath all >>>>> end up in the application class loader (modular JARs as named >>>>> modules; non-modular JARs jointly as the unnamed module). >>>>> >>>>> 2. While the module system is sure that package A exists in >>>>> the named module, how would the module system possibly know >>>>> that package A exists in the unnamed module? Scanning every >>>>> class file in every non-modular JAR on the classpath at >>>>> startup sounds bad. >>>>> >>>>> Alex >>>>> >>>>> >>> > From pbenedict at apache.org Thu Mar 10 21:25:27 2016 From: pbenedict at apache.org (Paul Benedict) Date: Thu, 10 Mar 2016 15:25:27 -0600 Subject: Unnamed module and duplicate package Message-ID: Alex, For the sake of usability, however, it would be nice if the JDK verified that jars do not contain any exported JDK packages. This would be an RFE. I understand that in order to avoid split packages between modules and classpath, the module version takes precedent. For developer vs. developer code, I find that reasoning fine. However, I really would like to treat the JDK as "special" (your words) because in my experience, I see developers constantly perplexed by NoClassDefFoundError when something occurred like you just detailed. I'd like to refer you to the Servlet 3.1 spec [1], section 10.7.2, as an analogous concern to mine. This is the so-called "prohibited classes" violation clause: "As described in the Java EE license agreement, servlet containers that are not part of a Java EE product should not allow the application to override Java SE platform classes, such as those in the java.* and javax.* namespaces, that Java SE does not allow to be modified. The container should not allow applications to override or access the container?s implementation classes." I don't think it's good usability to let JDK packages in the classpath go silently unchallenged and unloaded. I recommend they are reported as an error. [1] https://java.net/downloads/servlet-spec/Final/servlet-3_1-final.pdf Cheers, Paul On Thu, Mar 10, 2016 at 2:30 PM, Alex Buckley wrote: > I see xml-apis.jar (2.0.2) contains: > > - a javax.xml.parser package, which includes a FactoryFinder class that's > not in Java SE, and > > - a javax.xml.transform package hierarchy, whose types at first glance > look identical to those in Java SE except for yet another FactoryFinder > class in javax.xml.transform. > > If you put xml-apis.jar on the classpath, its javax.xml.** packages will > be ignored. The unnamed module reads the java.xml module which exports > javax.xml.** packages (assuming java.xml in the system image, of course), > so the application class loader delegates for javax.xml.** packages to the > loader responsible for the java.xml module. User code that tries to access > FactoryFinder will get a NoClassDefFoundError. > > There's nothing special about JDK modules here. The same > NoClassDefFoundError would occur if the system image contained a module > exporting some package, and a JAR on the classpath contained the same > package with extra classes, and some code on the classpath tried to access > those extra classes. Since the module in the system image is probably the > rightful owner/exporter of the package, hard questions should be asked > about the provenance of the JAR on the classpath. > > There has been some discussion of a jdeps-like tool that detects when a > JAR on your classpath is trying to split a JDK package: > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-November/005227.html > . > > Alex > > On 3/10/2016 10:27 AM, Paul Benedict wrote: > >> Alex, there are JARs that contain javax packages. Anyone in the web >> development community knows how many people have included xml-apis in >> their WEB-INF :-) only to find out it wasn't loaded or it took precedent >> over the JDK versions. >> >> Has Jigsaw introduced any restrictions here on this front? Honestly, I >> think the JDK should make it illegal for the classpath to contain ANY >> packages that the jdk has. Please opine when it is convenient for you. >> >> Cheers, >> Paul >> >> On Wed, Mar 9, 2016 at 5:13 PM, Alex Buckley > > wrote: >> >> Paul, thank you for asking. The module system's treatment of the >> unnamed module vis-a-vis named modules is probably the biggest >> factor affecting usability of the module system. This is true almost >> by definition because at JDK 9 GA the only named modules in the >> world will be the JDK's while every other class will be in the >> unnamed module of the application class loader. >> >> So please, ask more questions about the unnamed module. I am >> especially interested to know if anyone has JARs that contain javax >> packages (or heaven forbid, sun or com.sun packages) found in the >> JDK -- such JARs are a mortal danger to interop between unnamed and >> named modules. >> >> Alex >> >> On 3/9/2016 1:47 PM, Paul Benedict wrote: >> >> Thank you Alex. Since it's roughly the same as JDK 8, then it's >> also not >> worse. I defer to your explanation on that point. >> >> Cheers, >> Paul >> >> On Wed, Mar 9, 2016 at 3:37 PM, Alex Buckley >> >> > >> wrote: >> >> Presumably you would count the equivalent scenario on JDK 8 >> -- my >> package A is in Alex.jar on the classpath and your package >> A is in >> Paul.jar on the classpath -- as a security issue too, >> because some >> of my classes may substitute for yours (or some of yours >> for mine, >> depending on how the classpath is constructed). >> >> On JDK 9, we do the "substitution" cleanly. Package A is >> not split. >> That avoids one category of error (ClassCastException). >> What about >> poor package B that finds itself accessing a different >> package A >> than it was compiled with? Well, since package A is >> exported by a >> named module, it's reasonable to assume that the named >> module "owns" >> package A [*], and that the developer of package B >> co-bundled some >> version of package A without renaming it. Dangerous in JDK 8, >> dangerous in JDK 9. (We're trying to encapsulate the >> internals of a >> module, which is different from trying to isolate modules >> from each >> other.) >> >> [*] Advanced scenario: the named module exporting A is >> actually an >> automatic module which happened to co-bundle package A. By >> placing >> this JAR on the modulepath to form an automatic module, it >> dominates >> the JAR left on the classpath which also co-bundled package >> A. >> >> Alex >> >> On 3/9/2016 1:17 PM, Paul Benedict wrote: >> >> But isn't what your proposing a security issue? Let's >> say my >> package A >> is in the unnamed module and your package A is in a named >> module. You >> basically took over my code; your classes will be >> substituted >> for mine. >> >> Cheers, >> Paul >> >> On Wed, Mar 9, 2016 at 2:38 PM, Alex Buckley >> > > > >> > >> >> > >>> wrote: >> >> On 3/9/2016 10:36 AM, Paul Benedict wrote: >> >> From the doc: >> "If a package is defined in both a named >> module and the >> unnamed >> module then >> the package in the unnamed module is ignored. >> This >> preserves >> reliable >> configuration even in the face of the chaos of >> the >> class path, >> ensuring >> that every module still reads at most one >> module defining a >> given package. >> If, in our example above, a JAR file on the >> class path >> contains >> a class >> file named >> com/foo/bar/alpha/AlphaFactory.class then >> that file >> will never >> be loaded, since the com.foo.bar.alpha package >> is >> exported by the >> com.foo.bar module." >> >> I would like some clarification. Correct me if >> wrong, but I >> think this >> entire paragraph is really meant to be about the >> perspective from a >> modularized JAR? If a module has package A, >> and the unnamed >> module has >> package A, then of course the module's package >> A should >> win. >> >> However, if it is meant to be absolute >> language, then I >> disagree. >> >> The unnamed module should be coherent among >> itself. If the >> unnamed module >> has package B and relies on classes from >> package A, it >> should >> still be able >> to see its own package A. I don't think >> modules should >> be able >> to impact >> how the unnamed module sees itself. That's a >> surprising >> situation. >> >> >> The unnamed module is not a root module during >> resolution. >> If your >> main class is in the unnamed module (i.e. you did >> java -jar >> MyApp.jar rather than java -m MyApp), then the >> module graph is >> created by resolving various root modules (what >> are they? >> separate >> discussion) and only then is the unnamed module >> hooked up >> to read >> every module in the graph. >> >> Hope we're OK so far. >> >> If some named module in the graph exports package >> A (more >> than one >> module exporting A? separate discussion), then >> since the >> unnamed >> module reads that named module, the unnamed module >> will >> access A.* >> types from that named module. >> >> It's hard to imagine the unnamed module NOT >> accessing A.* >> types from >> that named module. Primarily, we need to avoid a >> split package >> situation where code in the unnamed module sometimes >> accesses A.* >> types from the named module and sometimes from the >> unnamed >> module. >> >> You might say, OK, let code in the unnamed module >> exclusively access >> A.* in the unnamed module rather than exclusively >> access >> A.* in the >> named module. Then you have two problems: >> >> 1. There are issues for named modules in the same >> class >> loader as >> the unnamed module -- such named modules MUST get >> A.* from >> the named >> module rather than the unnamed module, and the >> class loading >> mechanism is incapable of switching based on >> accessor. It'll be >> common for named modules to exist in the same >> class loader >> as the >> unnamed module, as modular JARs on the modulepath >> and >> non-modular >> JARs on the classpath all end up in the >> application class >> loader >> (modular JARs as named modules; non-modular JARs >> jointly as the >> unnamed module). >> >> 2. While the module system is sure that package A >> exists in the >> named module, how would the module system possibly >> know >> that package >> A exists in the unnamed module? Scanning every >> class file >> in every >> non-modular JAR on the classpath at startup sounds >> bad. >> >> Alex >> >> >> >> >> From pbenedict at apache.org Thu Mar 10 21:40:32 2016 From: pbenedict at apache.org (Paul Benedict) Date: Thu, 10 Mar 2016 15:40:32 -0600 Subject: Unnamed module and duplicate package In-Reply-To: References: Message-ID: My apologies for omitting some key qualifiers in my explanation. Read everything as a proposal to prohibit classpath jars from silently splitting whatever packages the JDK exports. -- Thanks On Thu, Mar 10, 2016 at 3:25 PM, Paul Benedict wrote: > Alex, > > For the sake of usability, however, it would be nice if the JDK verified > that jars do not contain any exported JDK packages. This would be an RFE. I > understand that in order to avoid split packages between modules and > classpath, the module version takes precedent. For developer vs. developer > code, I find that reasoning fine. However, I really would like to treat the > JDK as "special" (your words) because in my experience, I see developers > constantly perplexed by NoClassDefFoundError when something occurred like > you just detailed. > > I'd like to refer you to the Servlet 3.1 spec [1], section 10.7.2, as an > analogous concern to mine. This is the so-called "prohibited classes" > violation clause: > > "As described in the Java EE license agreement, servlet containers that > are not part of a Java EE product should not allow the application to > override Java SE platform classes, such as those in the java.* and javax.* > namespaces, that Java SE does not allow to be modified. The container > should not allow applications to override or access the container?s > implementation classes." > > I don't think it's good usability to let JDK packages in the classpath go > silently unchallenged and unloaded. I recommend they are reported as an > error. > > > [1] https://java.net/downloads/servlet-spec/Final/servlet-3_1-final.pdf > > Cheers, > Paul > > On Thu, Mar 10, 2016 at 2:30 PM, Alex Buckley > wrote: > >> I see xml-apis.jar (2.0.2) contains: >> >> - a javax.xml.parser package, which includes a FactoryFinder class that's >> not in Java SE, and >> >> - a javax.xml.transform package hierarchy, whose types at first glance >> look identical to those in Java SE except for yet another FactoryFinder >> class in javax.xml.transform. >> >> If you put xml-apis.jar on the classpath, its javax.xml.** packages will >> be ignored. The unnamed module reads the java.xml module which exports >> javax.xml.** packages (assuming java.xml in the system image, of course), >> so the application class loader delegates for javax.xml.** packages to the >> loader responsible for the java.xml module. User code that tries to access >> FactoryFinder will get a NoClassDefFoundError. >> >> There's nothing special about JDK modules here. The same >> NoClassDefFoundError would occur if the system image contained a module >> exporting some package, and a JAR on the classpath contained the same >> package with extra classes, and some code on the classpath tried to access >> those extra classes. Since the module in the system image is probably the >> rightful owner/exporter of the package, hard questions should be asked >> about the provenance of the JAR on the classpath. >> >> There has been some discussion of a jdeps-like tool that detects when a >> JAR on your classpath is trying to split a JDK package: >> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-November/005227.html >> . >> >> Alex >> >> On 3/10/2016 10:27 AM, Paul Benedict wrote: >> >>> Alex, there are JARs that contain javax packages. Anyone in the web >>> development community knows how many people have included xml-apis in >>> their WEB-INF :-) only to find out it wasn't loaded or it took precedent >>> over the JDK versions. >>> >>> Has Jigsaw introduced any restrictions here on this front? Honestly, I >>> think the JDK should make it illegal for the classpath to contain ANY >>> packages that the jdk has. Please opine when it is convenient for you. >>> >>> Cheers, >>> Paul >>> >>> On Wed, Mar 9, 2016 at 5:13 PM, Alex Buckley >> > wrote: >>> >>> Paul, thank you for asking. The module system's treatment of the >>> unnamed module vis-a-vis named modules is probably the biggest >>> factor affecting usability of the module system. This is true almost >>> by definition because at JDK 9 GA the only named modules in the >>> world will be the JDK's while every other class will be in the >>> unnamed module of the application class loader. >>> >>> So please, ask more questions about the unnamed module. I am >>> especially interested to know if anyone has JARs that contain javax >>> packages (or heaven forbid, sun or com.sun packages) found in the >>> JDK -- such JARs are a mortal danger to interop between unnamed and >>> named modules. >>> >>> Alex >>> >>> On 3/9/2016 1:47 PM, Paul Benedict wrote: >>> >>> Thank you Alex. Since it's roughly the same as JDK 8, then it's >>> also not >>> worse. I defer to your explanation on that point. >>> >>> Cheers, >>> Paul >>> >>> On Wed, Mar 9, 2016 at 3:37 PM, Alex Buckley >>> >>> >> >>> >> wrote: >>> >>> Presumably you would count the equivalent scenario on JDK 8 >>> -- my >>> package A is in Alex.jar on the classpath and your package >>> A is in >>> Paul.jar on the classpath -- as a security issue too, >>> because some >>> of my classes may substitute for yours (or some of yours >>> for mine, >>> depending on how the classpath is constructed). >>> >>> On JDK 9, we do the "substitution" cleanly. Package A is >>> not split. >>> That avoids one category of error (ClassCastException). >>> What about >>> poor package B that finds itself accessing a different >>> package A >>> than it was compiled with? Well, since package A is >>> exported by a >>> named module, it's reasonable to assume that the named >>> module "owns" >>> package A [*], and that the developer of package B >>> co-bundled some >>> version of package A without renaming it. Dangerous in JDK >>> 8, >>> dangerous in JDK 9. (We're trying to encapsulate the >>> internals of a >>> module, which is different from trying to isolate modules >>> from each >>> other.) >>> >>> [*] Advanced scenario: the named module exporting A is >>> actually an >>> automatic module which happened to co-bundle package A. By >>> placing >>> this JAR on the modulepath to form an automatic module, it >>> dominates >>> the JAR left on the classpath which also co-bundled package >>> A. >>> >>> Alex >>> >>> On 3/9/2016 1:17 PM, Paul Benedict wrote: >>> >>> But isn't what your proposing a security issue? Let's >>> say my >>> package A >>> is in the unnamed module and your package A is in a >>> named >>> module. You >>> basically took over my code; your classes will be >>> substituted >>> for mine. >>> >>> Cheers, >>> Paul >>> >>> On Wed, Mar 9, 2016 at 2:38 PM, Alex Buckley >>> >> >> > >>> >> >>> >>> >> >>> >>> wrote: >>> >>> On 3/9/2016 10:36 AM, Paul Benedict wrote: >>> >>> From the doc: >>> "If a package is defined in both a named >>> module and the >>> unnamed >>> module then >>> the package in the unnamed module is ignored. >>> This >>> preserves >>> reliable >>> configuration even in the face of the chaos of >>> the >>> class path, >>> ensuring >>> that every module still reads at most one >>> module defining a >>> given package. >>> If, in our example above, a JAR file on the >>> class path >>> contains >>> a class >>> file named >>> com/foo/bar/alpha/AlphaFactory.class then >>> that file >>> will never >>> be loaded, since the com.foo.bar.alpha package >>> is >>> exported by the >>> com.foo.bar module." >>> >>> I would like some clarification. Correct me if >>> wrong, but I >>> think this >>> entire paragraph is really meant to be about >>> the >>> perspective from a >>> modularized JAR? If a module has package A, >>> and the unnamed >>> module has >>> package A, then of course the module's package >>> A should >>> win. >>> >>> However, if it is meant to be absolute >>> language, then I >>> disagree. >>> >>> The unnamed module should be coherent among >>> itself. If the >>> unnamed module >>> has package B and relies on classes from >>> package A, it >>> should >>> still be able >>> to see its own package A. I don't think >>> modules should >>> be able >>> to impact >>> how the unnamed module sees itself. That's a >>> surprising >>> situation. >>> >>> >>> The unnamed module is not a root module during >>> resolution. >>> If your >>> main class is in the unnamed module (i.e. you did >>> java -jar >>> MyApp.jar rather than java -m MyApp), then the >>> module graph is >>> created by resolving various root modules (what >>> are they? >>> separate >>> discussion) and only then is the unnamed module >>> hooked up >>> to read >>> every module in the graph. >>> >>> Hope we're OK so far. >>> >>> If some named module in the graph exports package >>> A (more >>> than one >>> module exporting A? separate discussion), then >>> since the >>> unnamed >>> module reads that named module, the unnamed module >>> will >>> access A.* >>> types from that named module. >>> >>> It's hard to imagine the unnamed module NOT >>> accessing A.* >>> types from >>> that named module. Primarily, we need to avoid a >>> split package >>> situation where code in the unnamed module >>> sometimes >>> accesses A.* >>> types from the named module and sometimes from the >>> unnamed >>> module. >>> >>> You might say, OK, let code in the unnamed module >>> exclusively access >>> A.* in the unnamed module rather than exclusively >>> access >>> A.* in the >>> named module. Then you have two problems: >>> >>> 1. There are issues for named modules in the same >>> class >>> loader as >>> the unnamed module -- such named modules MUST get >>> A.* from >>> the named >>> module rather than the unnamed module, and the >>> class loading >>> mechanism is incapable of switching based on >>> accessor. It'll be >>> common for named modules to exist in the same >>> class loader >>> as the >>> unnamed module, as modular JARs on the modulepath >>> and >>> non-modular >>> JARs on the classpath all end up in the >>> application class >>> loader >>> (modular JARs as named modules; non-modular JARs >>> jointly as the >>> unnamed module). >>> >>> 2. While the module system is sure that package A >>> exists in the >>> named module, how would the module system possibly >>> know >>> that package >>> A exists in the unnamed module? Scanning every >>> class file >>> in every >>> non-modular JAR on the classpath at startup sounds >>> bad. >>> >>> Alex >>> >>> >>> >>> >>> > From david.lloyd at redhat.com Thu Mar 10 21:41:55 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 10 Mar 2016 15:41:55 -0600 Subject: Unnamed module and duplicate package In-Reply-To: <56E0AE10.80300@oracle.com> References: <56E089E3.8040204@oracle.com> <56E097B5.9040201@oracle.com> <56E0AE10.80300@oracle.com> Message-ID: <56E1EA23.3030309@redhat.com> One case to consider is javax.transaction.xa, which is part of the JDK and also in the JTA API along with javax.transaction. On 03/09/2016 05:13 PM, Alex Buckley wrote: > Paul, thank you for asking. The module system's treatment of the unnamed > module vis-a-vis named modules is probably the biggest factor affecting > usability of the module system. This is true almost by definition > because at JDK 9 GA the only named modules in the world will be the > JDK's while every other class will be in the unnamed module of the > application class loader. > > So please, ask more questions about the unnamed module. I am especially > interested to know if anyone has JARs that contain javax packages (or > heaven forbid, sun or com.sun packages) found in the JDK -- such JARs > are a mortal danger to interop between unnamed and named modules. > > Alex > > On 3/9/2016 1:47 PM, Paul Benedict wrote: >> Thank you Alex. Since it's roughly the same as JDK 8, then it's also not >> worse. I defer to your explanation on that point. >> >> Cheers, >> Paul >> >> On Wed, Mar 9, 2016 at 3:37 PM, Alex Buckley > > wrote: >> >> Presumably you would count the equivalent scenario on JDK 8 -- my >> package A is in Alex.jar on the classpath and your package A is in >> Paul.jar on the classpath -- as a security issue too, because some >> of my classes may substitute for yours (or some of yours for mine, >> depending on how the classpath is constructed). >> >> On JDK 9, we do the "substitution" cleanly. Package A is not split. >> That avoids one category of error (ClassCastException). What about >> poor package B that finds itself accessing a different package A >> than it was compiled with? Well, since package A is exported by a >> named module, it's reasonable to assume that the named module "owns" >> package A [*], and that the developer of package B co-bundled some >> version of package A without renaming it. Dangerous in JDK 8, >> dangerous in JDK 9. (We're trying to encapsulate the internals of a >> module, which is different from trying to isolate modules from each >> other.) >> >> [*] Advanced scenario: the named module exporting A is actually an >> automatic module which happened to co-bundle package A. By placing >> this JAR on the modulepath to form an automatic module, it dominates >> the JAR left on the classpath which also co-bundled package A. >> >> Alex >> >> On 3/9/2016 1:17 PM, Paul Benedict wrote: >> >> But isn't what your proposing a security issue? Let's say my >> package A >> is in the unnamed module and your package A is in a named >> module. You >> basically took over my code; your classes will be substituted >> for mine. >> >> Cheers, >> Paul >> >> On Wed, Mar 9, 2016 at 2:38 PM, Alex Buckley >> >> > >> wrote: >> >> On 3/9/2016 10:36 AM, Paul Benedict wrote: >> >> From the doc: >> "If a package is defined in both a named module and the >> unnamed >> module then >> the package in the unnamed module is ignored. This >> preserves >> reliable >> configuration even in the face of the chaos of the >> class path, >> ensuring >> that every module still reads at most one module >> defining a >> given package. >> If, in our example above, a JAR file on the class path >> contains >> a class >> file named com/foo/bar/alpha/AlphaFactory.class then >> that file >> will never >> be loaded, since the com.foo.bar.alpha package is >> exported by the >> com.foo.bar module." >> >> I would like some clarification. Correct me if wrong, >> but I >> think this >> entire paragraph is really meant to be about the >> perspective from a >> modularized JAR? If a module has package A, and the >> unnamed >> module has >> package A, then of course the module's package A should >> win. >> >> However, if it is meant to be absolute language, then I >> disagree. >> >> The unnamed module should be coherent among itself. >> If the >> unnamed module >> has package B and relies on classes from package A, it >> should >> still be able >> to see its own package A. I don't think modules should >> be able >> to impact >> how the unnamed module sees itself. That's a surprising >> situation. >> >> >> The unnamed module is not a root module during resolution. >> If your >> main class is in the unnamed module (i.e. you did java -jar >> MyApp.jar rather than java -m MyApp), then the module >> graph is >> created by resolving various root modules (what are they? >> separate >> discussion) and only then is the unnamed module hooked up >> to read >> every module in the graph. >> >> Hope we're OK so far. >> >> If some named module in the graph exports package A (more >> than one >> module exporting A? separate discussion), then since the >> unnamed >> module reads that named module, the unnamed module will >> access A.* >> types from that named module. >> >> It's hard to imagine the unnamed module NOT accessing A.* >> types from >> that named module. Primarily, we need to avoid a split >> package >> situation where code in the unnamed module sometimes >> accesses A.* >> types from the named module and sometimes from the unnamed >> module. >> >> You might say, OK, let code in the unnamed module >> exclusively access >> A.* in the unnamed module rather than exclusively access >> A.* in the >> named module. Then you have two problems: >> >> 1. There are issues for named modules in the same class >> loader as >> the unnamed module -- such named modules MUST get A.* from >> the named >> module rather than the unnamed module, and the class loading >> mechanism is incapable of switching based on accessor. >> It'll be >> common for named modules to exist in the same class loader >> as the >> unnamed module, as modular JARs on the modulepath and >> non-modular >> JARs on the classpath all end up in the application class >> loader >> (modular JARs as named modules; non-modular JARs jointly >> as the >> unnamed module). >> >> 2. While the module system is sure that package A exists >> in the >> named module, how would the module system possibly know >> that package >> A exists in the unnamed module? Scanning every class file >> in every >> non-modular JAR on the classpath at startup sounds bad. >> >> Alex >> >> >> -- - DML From stephen.felts at oracle.com Thu Mar 10 21:47:35 2016 From: stephen.felts at oracle.com (Stephen Felts) Date: Thu, 10 Mar 2016 13:47:35 -0800 (PST) Subject: Unnamed module and duplicate package In-Reply-To: References: Message-ID: <6fc7a369-2ce7-433d-b707-aa9bb60a647f@default> We allowed classes in the classpath that were provided by the JDK to go silently unchallenged. I think making this an error will be a big problem. -----Original Message----- From: Paul Benedict [mailto:pbenedict at apache.org] Sent: Thursday, March 10, 2016 4:25 PM To: Alex Buckley Cc: jigsaw-dev at openjdk.java.net Subject: Re: Unnamed module and duplicate package Alex, For the sake of usability, however, it would be nice if the JDK verified that jars do not contain any exported JDK packages. This would be an RFE. I understand that in order to avoid split packages between modules and classpath, the module version takes precedent. For developer vs. developer code, I find that reasoning fine. However, I really would like to treat the JDK as "special" (your words) because in my experience, I see developers constantly perplexed by NoClassDefFoundError when something occurred like you just detailed. I'd like to refer you to the Servlet 3.1 spec [1], section 10.7.2, as an analogous concern to mine. This is the so-called "prohibited classes" violation clause: "As described in the Java EE license agreement, servlet containers that are not part of a Java EE product should not allow the application to override Java SE platform classes, such as those in the java.* and javax.* namespaces, that Java SE does not allow to be modified. The container should not allow applications to override or access the container?s implementation classes." I don't think it's good usability to let JDK packages in the classpath go silently unchallenged and unloaded. I recommend they are reported as an error. [1] https://java.net/downloads/servlet-spec/Final/servlet-3_1-final.pdf Cheers, Paul On Thu, Mar 10, 2016 at 2:30 PM, Alex Buckley wrote: > I see xml-apis.jar (2.0.2) contains: > > - a javax.xml.parser package, which includes a FactoryFinder class > that's not in Java SE, and > > - a javax.xml.transform package hierarchy, whose types at first glance > look identical to those in Java SE except for yet another > FactoryFinder class in javax.xml.transform. > > If you put xml-apis.jar on the classpath, its javax.xml.** packages > will be ignored. The unnamed module reads the java.xml module which > exports > javax.xml.** packages (assuming java.xml in the system image, of > course), so the application class loader delegates for javax.xml.** > packages to the loader responsible for the java.xml module. User code > that tries to access FactoryFinder will get a NoClassDefFoundError. > > There's nothing special about JDK modules here. The same > NoClassDefFoundError would occur if the system image contained a > module exporting some package, and a JAR on the classpath contained > the same package with extra classes, and some code on the classpath > tried to access those extra classes. Since the module in the system > image is probably the rightful owner/exporter of the package, hard > questions should be asked about the provenance of the JAR on the classpath. > > There has been some discussion of a jdeps-like tool that detects when > a JAR on your classpath is trying to split a JDK package: > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-November/005227 > .html > . > > Alex > > On 3/10/2016 10:27 AM, Paul Benedict wrote: > >> Alex, there are JARs that contain javax packages. Anyone in the web >> development community knows how many people have included xml-apis in >> their WEB-INF :-) only to find out it wasn't loaded or it took >> precedent over the JDK versions. >> >> Has Jigsaw introduced any restrictions here on this front? Honestly, >> I think the JDK should make it illegal for the classpath to contain >> ANY packages that the jdk has. Please opine when it is convenient for you. >> >> Cheers, >> Paul >> >> On Wed, Mar 9, 2016 at 5:13 PM, Alex Buckley > > wrote: >> >> Paul, thank you for asking. The module system's treatment of the >> unnamed module vis-a-vis named modules is probably the biggest >> factor affecting usability of the module system. This is true almost >> by definition because at JDK 9 GA the only named modules in the >> world will be the JDK's while every other class will be in the >> unnamed module of the application class loader. >> >> So please, ask more questions about the unnamed module. I am >> especially interested to know if anyone has JARs that contain javax >> packages (or heaven forbid, sun or com.sun packages) found in the >> JDK -- such JARs are a mortal danger to interop between unnamed and >> named modules. >> >> Alex >> >> On 3/9/2016 1:47 PM, Paul Benedict wrote: >> >> Thank you Alex. Since it's roughly the same as JDK 8, then it's >> also not >> worse. I defer to your explanation on that point. >> >> Cheers, >> Paul >> >> On Wed, Mar 9, 2016 at 3:37 PM, Alex Buckley >> >> > >> wrote: >> >> Presumably you would count the equivalent scenario on JDK 8 >> -- my >> package A is in Alex.jar on the classpath and your package >> A is in >> Paul.jar on the classpath -- as a security issue too, >> because some >> of my classes may substitute for yours (or some of yours >> for mine, >> depending on how the classpath is constructed). >> >> On JDK 9, we do the "substitution" cleanly. Package A is >> not split. >> That avoids one category of error (ClassCastException). >> What about >> poor package B that finds itself accessing a different >> package A >> than it was compiled with? Well, since package A is >> exported by a >> named module, it's reasonable to assume that the named >> module "owns" >> package A [*], and that the developer of package B >> co-bundled some >> version of package A without renaming it. Dangerous in JDK 8, >> dangerous in JDK 9. (We're trying to encapsulate the >> internals of a >> module, which is different from trying to isolate modules >> from each >> other.) >> >> [*] Advanced scenario: the named module exporting A is >> actually an >> automatic module which happened to co-bundle package A. By >> placing >> this JAR on the modulepath to form an automatic module, it >> dominates >> the JAR left on the classpath which also co-bundled >> package A. >> >> Alex >> >> On 3/9/2016 1:17 PM, Paul Benedict wrote: >> >> But isn't what your proposing a security issue? Let's >> say my >> package A >> is in the unnamed module and your package A is in a named >> module. You >> basically took over my code; your classes will be >> substituted >> for mine. >> >> Cheers, >> Paul >> >> On Wed, Mar 9, 2016 at 2:38 PM, Alex Buckley >> > > > >> > >> >> > >>> wrote: >> >> On 3/9/2016 10:36 AM, Paul Benedict wrote: >> >> From the doc: >> "If a package is defined in both a named >> module and the >> unnamed >> module then >> the package in the unnamed module is ignored. >> This >> preserves >> reliable >> configuration even in the face of the chaos >> of the >> class path, >> ensuring >> that every module still reads at most one >> module defining a >> given package. >> If, in our example above, a JAR file on the >> class path >> contains >> a class >> file named >> com/foo/bar/alpha/AlphaFactory.class then >> that file >> will never >> be loaded, since the com.foo.bar.alpha >> package is >> exported by the >> com.foo.bar module." >> >> I would like some clarification. Correct me if >> wrong, but I >> think this >> entire paragraph is really meant to be about the >> perspective from a >> modularized JAR? If a module has package A, >> and the unnamed >> module has >> package A, then of course the module's package >> A should >> win. >> >> However, if it is meant to be absolute >> language, then I >> disagree. >> >> The unnamed module should be coherent among >> itself. If the >> unnamed module >> has package B and relies on classes from >> package A, it >> should >> still be able >> to see its own package A. I don't think >> modules should >> be able >> to impact >> how the unnamed module sees itself. That's a >> surprising >> situation. >> >> >> The unnamed module is not a root module during >> resolution. >> If your >> main class is in the unnamed module (i.e. you did >> java -jar >> MyApp.jar rather than java -m MyApp), then the >> module graph is >> created by resolving various root modules (what >> are they? >> separate >> discussion) and only then is the unnamed module >> hooked up >> to read >> every module in the graph. >> >> Hope we're OK so far. >> >> If some named module in the graph exports package >> A (more >> than one >> module exporting A? separate discussion), then >> since the >> unnamed >> module reads that named module, the unnamed module >> will >> access A.* >> types from that named module. >> >> It's hard to imagine the unnamed module NOT >> accessing A.* >> types from >> that named module. Primarily, we need to avoid a >> split package >> situation where code in the unnamed module sometimes >> accesses A.* >> types from the named module and sometimes from the >> unnamed >> module. >> >> You might say, OK, let code in the unnamed module >> exclusively access >> A.* in the unnamed module rather than exclusively >> access >> A.* in the >> named module. Then you have two problems: >> >> 1. There are issues for named modules in the same >> class >> loader as >> the unnamed module -- such named modules MUST get >> A.* from >> the named >> module rather than the unnamed module, and the >> class loading >> mechanism is incapable of switching based on >> accessor. It'll be >> common for named modules to exist in the same >> class loader >> as the >> unnamed module, as modular JARs on the >> modulepath and >> non-modular >> JARs on the classpath all end up in the >> application class >> loader >> (modular JARs as named modules; non-modular JARs >> jointly as the >> unnamed module). >> >> 2. While the module system is sure that package A >> exists in the >> named module, how would the module system possibly >> know >> that package >> A exists in the unnamed module? Scanning every >> class file >> in every >> non-modular JAR on the classpath at startup sounds >> bad. >> >> Alex >> >> >> >> >> From alex.buckley at oracle.com Thu Mar 10 21:55:44 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 10 Mar 2016 13:55:44 -0800 Subject: Unnamed module and duplicate package In-Reply-To: References: Message-ID: <56E1ED60.5090704@oracle.com> This would entail the module system enumerating every JAR on the classpath after creating the module graph, in order to detect whether the unnamed module splits any package exported by any named module. There's no reason to special case JDK modules -- augmenting a user module would lead to errors just as confusing. (Suppose the system image contains just the java.base and spring.boot modules -- I'm sure the latter's owners are just as concerned about third-party augmentation as we are about the former. In fact, they should be more concerned, since their module is in the application loader so its package-private content would be accessible by a classpath JAR also in the application loader. In contrast, the java.base module is safely in the ivory tower of the bootstrap loader, hence a different run-time package from anything in the application loader.) There's an obvious bikeshed around this validation behavior -- enabled by default? can I choose the modules to be coated with anti-split paint? can I tweak which parts of the classpath get scanned? can I have a manifest attribute to opt out of being scanned? -- so I suggest you simply record the proposal on jpms-spec-comments. Alex On 3/10/2016 1:40 PM, Paul Benedict wrote: > My apologies for omitting some key qualifiers in my explanation. Read > everything as a proposal to prohibit classpath jars from silently > splitting whatever packages the JDK exports. -- Thanks > > On Thu, Mar 10, 2016 at 3:25 PM, Paul Benedict > wrote: > > Alex, > > For the sake of usability, however, it would be nice if the JDK > verified that jars do not contain any exported JDK packages. This > would be an RFE. I understand that in order to avoid split packages > between modules and classpath, the module version takes precedent. > For developer vs. developer code, I find that reasoning fine. > However, I really would like to treat the JDK as "special" (your > words) because in my experience, I see developers constantly > perplexed by NoClassDefFoundError when something occurred like you > just detailed. > > I'd like to refer you to the Servlet 3.1 spec [1], section 10.7.2, > as an analogous concern to mine. This is the so-called "prohibited > classes" violation clause: > > "As described in the Java EE license agreement, servlet containers > that are not part of a Java EE product should not allow the > application to override Java SE platform classes, such as those in > the java.* and javax.* namespaces, that Java SE does not allow to be > modified. The container should not allow applications to override or > access the container?s implementation classes." > > I don't think it's good usability to let JDK packages in the > classpath go silently unchallenged and unloaded. I recommend they > are reported as an error. > > > [1] https://java.net/downloads/servlet-spec/Final/servlet-3_1-final.pdf > > Cheers, > Paul > > On Thu, Mar 10, 2016 at 2:30 PM, Alex Buckley > > wrote: > > I see xml-apis.jar (2.0.2) contains: > > - a javax.xml.parser package, which includes a FactoryFinder > class that's not in Java SE, and > > - a javax.xml.transform package hierarchy, whose types at first > glance look identical to those in Java SE except for yet another > FactoryFinder class in javax.xml.transform. > > If you put xml-apis.jar on the classpath, its javax.xml.** > packages will be ignored. The unnamed module reads the java.xml > module which exports javax.xml.** packages (assuming java.xml in > the system image, of course), so the application class loader > delegates for javax.xml.** packages to the loader responsible > for the java.xml module. User code that tries to access > FactoryFinder will get a NoClassDefFoundError. > > There's nothing special about JDK modules here. The same > NoClassDefFoundError would occur if the system image contained a > module exporting some package, and a JAR on the classpath > contained the same package with extra classes, and some code on > the classpath tried to access those extra classes. Since the > module in the system image is probably the rightful > owner/exporter of the package, hard questions should be asked > about the provenance of the JAR on the classpath. > > There has been some discussion of a jdeps-like tool that detects > when a JAR on your classpath is trying to split a JDK package: > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-November/005227.html. > > Alex > > On 3/10/2016 10:27 AM, Paul Benedict wrote: > > Alex, there are JARs that contain javax packages. Anyone in > the web > development community knows how many people have included > xml-apis in > their WEB-INF :-) only to find out it wasn't loaded or it > took precedent > over the JDK versions. > > Has Jigsaw introduced any restrictions here on this front? > Honestly, I > think the JDK should make it illegal for the classpath to > contain ANY > packages that the jdk has. Please opine when it is > convenient for you. > > Cheers, > Paul > > On Wed, Mar 9, 2016 at 5:13 PM, Alex Buckley > > >> wrote: > > Paul, thank you for asking. The module system's > treatment of the > unnamed module vis-a-vis named modules is probably the > biggest > factor affecting usability of the module system. This > is true almost > by definition because at JDK 9 GA the only named > modules in the > world will be the JDK's while every other class will be > in the > unnamed module of the application class loader. > > So please, ask more questions about the unnamed module. > I am > especially interested to know if anyone has JARs that > contain javax > packages (or heaven forbid, sun or com.sun packages) > found in the > JDK -- such JARs are a mortal danger to interop between > unnamed and > named modules. > > Alex > > On 3/9/2016 1:47 PM, Paul Benedict wrote: > > Thank you Alex. Since it's roughly the same as JDK > 8, then it's > also not > worse. I defer to your explanation on that point. > > Cheers, > Paul > > On Wed, Mar 9, 2016 at 3:37 PM, Alex Buckley > > > > > > >>> wrote: > > Presumably you would count the equivalent > scenario on JDK 8 > -- my > package A is in Alex.jar on the classpath and > your package > A is in > Paul.jar on the classpath -- as a security > issue too, > because some > of my classes may substitute for yours (or > some of yours > for mine, > depending on how the classpath is constructed). > > On JDK 9, we do the "substitution" cleanly. > Package A is > not split. > That avoids one category of error > (ClassCastException). > What about > poor package B that finds itself accessing a > different > package A > than it was compiled with? Well, since package > A is > exported by a > named module, it's reasonable to assume that > the named > module "owns" > package A [*], and that the developer of package B > co-bundled some > version of package A without renaming it. > Dangerous in JDK 8, > dangerous in JDK 9. (We're trying to > encapsulate the > internals of a > module, which is different from trying to > isolate modules > from each > other.) > > [*] Advanced scenario: the named module > exporting A is > actually an > automatic module which happened to co-bundle > package A. By > placing > this JAR on the modulepath to form an > automatic module, it > dominates > the JAR left on the classpath which also > co-bundled package A. > > Alex > > On 3/9/2016 1:17 PM, Paul Benedict wrote: > > But isn't what your proposing a security > issue? Let's > say my > package A > is in the unnamed module and your package > A is in a named > module. You > basically took over my code; your classes > will be > substituted > for mine. > > Cheers, > Paul > > On Wed, Mar 9, 2016 at 2:38 PM, Alex Buckley > > > > > >> > > > > > > > >>>> wrote: > > On 3/9/2016 10:36 AM, Paul Benedict > wrote: > > From the doc: > "If a package is defined in both > a named > module and the > unnamed > module then > the package in the unnamed module > is ignored. This > preserves > reliable > configuration even in the face of > the chaos of the > class path, > ensuring > that every module still reads at > most one > module defining a > given package. > If, in our example above, a JAR > file on the > class path > contains > a class > file named > com/foo/bar/alpha/AlphaFactory.class then > that file > will never > be loaded, since the > com.foo.bar.alpha package is > exported by the > com.foo.bar module." > > I would like some clarification. > Correct me if > wrong, but I > think this > entire paragraph is really meant > to be about the > perspective from a > modularized JAR? If a module has > package A, > and the unnamed > module has > package A, then of course the > module's package > A should > win. > > However, if it is meant to be > absolute > language, then I > disagree. > > The unnamed module should be > coherent among > itself. If the > unnamed module > has package B and relies on > classes from > package A, it > should > still be able > to see its own package A. I don't > think > modules should > be able > to impact > how the unnamed module sees > itself. That's a > surprising > situation. > > > The unnamed module is not a root > module during > resolution. > If your > main class is in the unnamed module > (i.e. you did > java -jar > MyApp.jar rather than java -m MyApp), > then the > module graph is > created by resolving various root > modules (what > are they? > separate > discussion) and only then is the > unnamed module > hooked up > to read > every module in the graph. > > Hope we're OK so far. > > If some named module in the graph > exports package > A (more > than one > module exporting A? separate > discussion), then > since the > unnamed > module reads that named module, the > unnamed module > will > access A.* > types from that named module. > > It's hard to imagine the unnamed > module NOT > accessing A.* > types from > that named module. Primarily, we need > to avoid a > split package > situation where code in the unnamed > module sometimes > accesses A.* > types from the named module and > sometimes from the > unnamed > module. > > You might say, OK, let code in the > unnamed module > exclusively access > A.* in the unnamed module rather than > exclusively > access > A.* in the > named module. Then you have two problems: > > 1. There are issues for named modules > in the same > class > loader as > the unnamed module -- such named > modules MUST get > A.* from > the named > module rather than the unnamed > module, and the > class loading > mechanism is incapable of switching > based on > accessor. It'll be > common for named modules to exist in > the same > class loader > as the > unnamed module, as modular JARs on > the modulepath and > non-modular > JARs on the classpath all end up in the > application class > loader > (modular JARs as named modules; > non-modular JARs > jointly as the > unnamed module). > > 2. While the module system is sure > that package A > exists in the > named module, how would the module > system possibly > know > that package > A exists in the unnamed module? > Scanning every > class file > in every > non-modular JAR on the classpath at > startup sounds > bad. > > Alex > > > > > > From alex.buckley at oracle.com Thu Mar 10 21:59:23 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 10 Mar 2016 13:59:23 -0800 Subject: Unnamed module and duplicate package In-Reply-To: <56E1EA23.3030309@redhat.com> References: <56E089E3.8040204@oracle.com> <56E097B5.9040201@oracle.com> <56E0AE10.80300@oracle.com> <56E1EA23.3030309@redhat.com> Message-ID: <56E1EE3B.1000707@oracle.com> Yes -- and also the javax.** APIs in the modules directly required by java.se.ee (see http://openjdk.java.net/jeps/200). Alex On 3/10/2016 1:41 PM, David M. Lloyd wrote: > One case to consider is javax.transaction.xa, which is part of the JDK > and also in the JTA API along with javax.transaction. > > On 03/09/2016 05:13 PM, Alex Buckley wrote: >> Paul, thank you for asking. The module system's treatment of the unnamed >> module vis-a-vis named modules is probably the biggest factor affecting >> usability of the module system. This is true almost by definition >> because at JDK 9 GA the only named modules in the world will be the >> JDK's while every other class will be in the unnamed module of the >> application class loader. >> >> So please, ask more questions about the unnamed module. I am especially >> interested to know if anyone has JARs that contain javax packages (or >> heaven forbid, sun or com.sun packages) found in the JDK -- such JARs >> are a mortal danger to interop between unnamed and named modules. >> >> Alex >> >> On 3/9/2016 1:47 PM, Paul Benedict wrote: >>> Thank you Alex. Since it's roughly the same as JDK 8, then it's also not >>> worse. I defer to your explanation on that point. >>> >>> Cheers, >>> Paul >>> >>> On Wed, Mar 9, 2016 at 3:37 PM, Alex Buckley >> > wrote: >>> >>> Presumably you would count the equivalent scenario on JDK 8 -- my >>> package A is in Alex.jar on the classpath and your package A is in >>> Paul.jar on the classpath -- as a security issue too, because some >>> of my classes may substitute for yours (or some of yours for mine, >>> depending on how the classpath is constructed). >>> >>> On JDK 9, we do the "substitution" cleanly. Package A is not split. >>> That avoids one category of error (ClassCastException). What about >>> poor package B that finds itself accessing a different package A >>> than it was compiled with? Well, since package A is exported by a >>> named module, it's reasonable to assume that the named module "owns" >>> package A [*], and that the developer of package B co-bundled some >>> version of package A without renaming it. Dangerous in JDK 8, >>> dangerous in JDK 9. (We're trying to encapsulate the internals of a >>> module, which is different from trying to isolate modules from each >>> other.) >>> >>> [*] Advanced scenario: the named module exporting A is actually an >>> automatic module which happened to co-bundle package A. By placing >>> this JAR on the modulepath to form an automatic module, it dominates >>> the JAR left on the classpath which also co-bundled package A. >>> >>> Alex >>> >>> On 3/9/2016 1:17 PM, Paul Benedict wrote: >>> >>> But isn't what your proposing a security issue? Let's say my >>> package A >>> is in the unnamed module and your package A is in a named >>> module. You >>> basically took over my code; your classes will be substituted >>> for mine. >>> >>> Cheers, >>> Paul >>> >>> On Wed, Mar 9, 2016 at 2:38 PM, Alex Buckley >>> >>> >> >> wrote: >>> >>> On 3/9/2016 10:36 AM, Paul Benedict wrote: >>> >>> From the doc: >>> "If a package is defined in both a named module and the >>> unnamed >>> module then >>> the package in the unnamed module is ignored. This >>> preserves >>> reliable >>> configuration even in the face of the chaos of the >>> class path, >>> ensuring >>> that every module still reads at most one module >>> defining a >>> given package. >>> If, in our example above, a JAR file on the class path >>> contains >>> a class >>> file named com/foo/bar/alpha/AlphaFactory.class then >>> that file >>> will never >>> be loaded, since the com.foo.bar.alpha package is >>> exported by the >>> com.foo.bar module." >>> >>> I would like some clarification. Correct me if wrong, >>> but I >>> think this >>> entire paragraph is really meant to be about the >>> perspective from a >>> modularized JAR? If a module has package A, and the >>> unnamed >>> module has >>> package A, then of course the module's package A should >>> win. >>> >>> However, if it is meant to be absolute language, then I >>> disagree. >>> >>> The unnamed module should be coherent among itself. >>> If the >>> unnamed module >>> has package B and relies on classes from package A, it >>> should >>> still be able >>> to see its own package A. I don't think modules should >>> be able >>> to impact >>> how the unnamed module sees itself. That's a surprising >>> situation. >>> >>> >>> The unnamed module is not a root module during resolution. >>> If your >>> main class is in the unnamed module (i.e. you did java -jar >>> MyApp.jar rather than java -m MyApp), then the module >>> graph is >>> created by resolving various root modules (what are they? >>> separate >>> discussion) and only then is the unnamed module hooked up >>> to read >>> every module in the graph. >>> >>> Hope we're OK so far. >>> >>> If some named module in the graph exports package A (more >>> than one >>> module exporting A? separate discussion), then since the >>> unnamed >>> module reads that named module, the unnamed module will >>> access A.* >>> types from that named module. >>> >>> It's hard to imagine the unnamed module NOT accessing A.* >>> types from >>> that named module. Primarily, we need to avoid a split >>> package >>> situation where code in the unnamed module sometimes >>> accesses A.* >>> types from the named module and sometimes from the unnamed >>> module. >>> >>> You might say, OK, let code in the unnamed module >>> exclusively access >>> A.* in the unnamed module rather than exclusively access >>> A.* in the >>> named module. Then you have two problems: >>> >>> 1. There are issues for named modules in the same class >>> loader as >>> the unnamed module -- such named modules MUST get A.* from >>> the named >>> module rather than the unnamed module, and the class >>> loading >>> mechanism is incapable of switching based on accessor. >>> It'll be >>> common for named modules to exist in the same class loader >>> as the >>> unnamed module, as modular JARs on the modulepath and >>> non-modular >>> JARs on the classpath all end up in the application class >>> loader >>> (modular JARs as named modules; non-modular JARs jointly >>> as the >>> unnamed module). >>> >>> 2. While the module system is sure that package A exists >>> in the >>> named module, how would the module system possibly know >>> that package >>> A exists in the unnamed module? Scanning every class file >>> in every >>> non-modular JAR on the classpath at startup sounds bad. >>> >>> Alex >>> >>> >>> > From mandy.chung at oracle.com Thu Mar 10 22:11:32 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 10 Mar 2016 22:11:32 +0000 Subject: hg: jigsaw/jake: 2 new changesets Message-ID: <201603102211.u2AMBWEO012822@aojmv0008.oracle.com> Changeset: b0d82bafd78d Author: lana Date: 2016-03-10 09:28 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/b0d82bafd78d Added tag jdk-9+109 for changeset 1787bdaabb2b ! .hgtags Changeset: 579099c4d41d Author: mchung Date: 2016-03-10 14:08 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/579099c4d41d Merge - make/CheckModules.gmk - make/GenerateModuleDeps.gmk - modules.xml From mandy.chung at oracle.com Thu Mar 10 22:11:37 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 10 Mar 2016 22:11:37 +0000 Subject: hg: jigsaw/jake/corba: 2 new changesets Message-ID: <201603102211.u2AMBcxp012936@aojmv0008.oracle.com> Changeset: 9666775734fb Author: lana Date: 2016-03-10 09:28 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/9666775734fb Added tag jdk-9+109 for changeset b75afa17aefe ! .hgtags Changeset: 2dca1f095652 Author: mchung Date: 2016-03-10 14:08 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/2dca1f095652 Merge From mandy.chung at oracle.com Thu Mar 10 22:11:44 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 10 Mar 2016 22:11:44 +0000 Subject: hg: jigsaw/jake/hotspot: 2 new changesets Message-ID: <201603102211.u2AMBiYP013083@aojmv0008.oracle.com> Changeset: 407003fcbdb9 Author: lana Date: 2016-03-10 09:28 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/407003fcbdb9 Added tag jdk-9+109 for changeset 7e7e50ac4faf ! .hgtags Changeset: 81db3766ab04 Author: mchung Date: 2016-03-10 14:09 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/81db3766ab04 Merge ! .hgtags - src/jdk.vm.ci/share/classes/META-INF/services/jdk.vm.ci.hotspot.HotSpotJVMCIBackendFactory - test/compiler/jsr292/NonInlinedCall/NonInlinedReinvoker.java - test/compiler/jvmci/common/CompilerToVMHelper.java - test/compiler/jvmci/common/PublicMetaspaceWrapperObject.java - test/compiler/jvmci/events/MetaAccessWrapper.java - test/runtime/BadObjectClass/Object.java - test/testlibrary/jdk/test/lib/PerfCounter.java - test/testlibrary/jdk/test/lib/PerfCounters.java From mandy.chung at oracle.com Thu Mar 10 22:11:49 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 10 Mar 2016 22:11:49 +0000 Subject: hg: jigsaw/jake/jaxp: 2 new changesets Message-ID: <201603102211.u2AMBnvR013137@aojmv0008.oracle.com> Changeset: d9afbcf9f454 Author: lana Date: 2016-03-10 09:28 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/d9afbcf9f454 Added tag jdk-9+109 for changeset 24e247ee1fff ! .hgtags Changeset: 6ac32375d722 Author: mchung Date: 2016-03-10 14:08 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/6ac32375d722 Merge From mandy.chung at oracle.com Thu Mar 10 22:11:52 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 10 Mar 2016 22:11:52 +0000 Subject: hg: jigsaw/jake/jaxws: 2 new changesets Message-ID: <201603102211.u2AMBqeB013195@aojmv0008.oracle.com> Changeset: 0db939c930f3 Author: lana Date: 2016-03-10 09:28 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/0db939c930f3 Added tag jdk-9+109 for changeset 4b0697e4ce89 ! .hgtags Changeset: 0b5ceffe466b Author: mchung Date: 2016-03-10 14:09 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/0b5ceffe466b Merge From mandy.chung at oracle.com Thu Mar 10 22:11:59 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 10 Mar 2016 22:11:59 +0000 Subject: hg: jigsaw/jake/jdk: 2 new changesets Message-ID: <201603102211.u2AMBxRN013263@aojmv0008.oracle.com> Changeset: 780e06e3572b Author: lana Date: 2016-03-10 09:28 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/780e06e3572b Added tag jdk-9+109 for changeset 1c7bad079890 ! .hgtags Changeset: f4d2641ccce8 Author: mchung Date: 2016-03-10 14:09 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f4d2641ccce8 Merge ! .hgtags - make/gendata/Gendata-jdk.jdeps.gmk - make/gensrc/Gensrc-jdk.dev.gmk - make/gensrc/Gensrc-jdk.jvmstat.gmk - make/launcher/Launcher-jdk.dev.gmk - make/scripts/localelist.sh - make/src/classes/build/tools/module/GenJdepsModulesXml.java - make/src/classes/build/tools/module/GenModulesList.java - make/src/classes/build/tools/module/ImageBuilder.java - make/src/classes/build/tools/module/ModuleArchive.java - make/src/classes/build/tools/module/boot.modules - make/src/classes/build/tools/module/ext.modules - src/java.base/share/classes/jdk/internal/jimage/Archive.java - src/java.base/share/classes/jdk/internal/jimage/BasicImageWriter.java - src/java.base/share/classes/jdk/internal/jimage/ExternalFilesWriter.java - src/java.base/share/classes/jdk/internal/jimage/ImageFileCreator.java - src/java.base/share/classes/jdk/internal/jimage/ImageJavaSubstrate.java - src/java.base/share/classes/jdk/internal/jimage/ImageLocationWriter.java - src/java.base/share/classes/jdk/internal/jimage/ImageModuleDataWriter.java - src/java.base/share/classes/jdk/internal/jimage/ImageNativeSubstrate.java - src/java.base/share/classes/jdk/internal/jimage/ImageResourcesTree.java - src/java.base/share/classes/jdk/internal/jimage/ImageStringsWriter.java - src/java.base/share/classes/jdk/internal/jimage/ImageSubstrate.java - src/java.base/share/classes/jdk/internal/jimage/PerfectHashBuilder.java - src/java.base/share/classes/jdk/internal/jimage/ResourcePool.java - src/java.base/share/classes/jdk/internal/jimage/ResourcePoolImpl.java - src/java.base/share/classes/jdk/internal/jimage/StringTable.java - src/java.base/share/classes/jdk/internal/jimage/UTF8String.java - src/java.base/share/classes/sun/misc/Launcher.java - src/java.base/share/classes/sun/util/CoreResourceBundleControl-XLocales.java.template - src/java.base/share/native/libjava/Package.c - src/java.base/share/native/libjava/Proxy.c - src/java.base/share/native/libjimage/ImageNativeSubstrate.cpp - src/java.desktop/share/classes/META-INF/services/java.net.ContentHandlerFactory - src/java.desktop/share/classes/META-INF/services/javax.print.PrintServiceLookup - src/java.desktop/share/classes/META-INF/services/javax.print.StreamPrintServiceFactory - src/java.desktop/share/classes/META-INF/services/javax.sound.midi.spi.MidiDeviceProvider - src/java.desktop/share/classes/META-INF/services/javax.sound.midi.spi.MidiFileReader - src/java.desktop/share/classes/META-INF/services/javax.sound.midi.spi.MidiFileWriter - src/java.desktop/share/classes/META-INF/services/javax.sound.midi.spi.SoundbankReader - src/java.desktop/share/classes/META-INF/services/javax.sound.sampled.spi.AudioFileReader - src/java.desktop/share/classes/META-INF/services/javax.sound.sampled.spi.AudioFileWriter - src/java.desktop/share/classes/META-INF/services/javax.sound.sampled.spi.FormatConversionProvider - src/java.desktop/share/classes/META-INF/services/javax.sound.sampled.spi.MixerProvider - src/java.desktop/share/classes/META-INF/services/sun.datatransfer.DesktopDatatransferService - src/java.logging/share/classes/META-INF/services/jdk.internal.logger.DefaultLoggerFinder - src/java.security.jgss/share/classes/META-INF/services/sun.security.ssl.ClientKeyExchangeService - src/jdk.accessibility/windows/classes/META-INF/services/javax.accessibility.AccessibilityProvider - src/jdk.attach/share/classes/META-INF/services/com.sun.tools.attach.spi.AttachProvider - src/jdk.charsets/share/classes/META-INF/services/java.nio.charset.spi.CharsetProvider - src/jdk.dev/share/classes/jdk/tools/jimage/ExtractedImage.java - src/jdk.dev/share/classes/jdk/tools/jimage/JImageTask.java - src/jdk.dev/share/classes/jdk/tools/jimage/Main.java - src/jdk.dev/share/classes/jdk/tools/jimage/TaskHelper.java - src/jdk.dev/share/classes/jdk/tools/jimage/resources/jimage.properties - src/jdk.jdi/share/classes/META-INF/services/com.sun.jdi.connect.Connector - src/jdk.jdi/share/classes/META-INF/services/com.sun.jdi.connect.spi.TransportService - src/jdk.jvmstat.rmi/share/classes/META-INF/services/sun.jvmstat.monitor.MonitoredHostService - src/jdk.jvmstat/share/classes/META-INF/services/sun.jvmstat.monitor.MonitoredHostService - src/jdk.localedata/share/classes/META-INF/services/sun.util.locale.provider.LocaleDataMetaInfo - src/jdk.management/share/classes/META-INF/services/sun.management.spi.PlatformMBeanProvider - src/jdk.naming.dns/share/classes/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - src/jdk.zipfs/share/classes/META-INF/services/java.nio.file.spi.FileSystemProvider - test/java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.sh - test/java/net/DatagramSocket/SetDatagramSocketImplFactory/java/net/MyDatagramSocketImplFactory.java - test/java/util/stream/bootlib/TEST.properties - test/jdk/internal/jimage/ExecutableTest.java - test/jdk/internal/jimage/JImageTest.java - test/jdk/internal/jimage/VerifyJimage.java - test/sun/security/krb5/config/NamingManager.java - test/sun/security/krb5/config/dns.sh - test/sun/security/mscapi/IsSunMSCAPIAvailable.sh - test/sun/security/ssl/StatusStapling/BogusStatusRequest.java - test/sun/security/ssl/StatusStapling/CertStatusReqExtensionTests.java - test/sun/security/ssl/StatusStapling/CertStatusReqItemV2Tests.java - test/sun/security/ssl/StatusStapling/CertStatusReqListV2ExtensionTests.java - test/sun/security/ssl/StatusStapling/OCSPStatusRequestTests.java - test/sun/security/ssl/StatusStapling/StatusResponseManagerTests.java - test/sun/security/ssl/StatusStapling/TestCase.java - test/sun/security/ssl/StatusStapling/TestUtils.java From mandy.chung at oracle.com Thu Mar 10 22:12:05 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 10 Mar 2016 22:12:05 +0000 Subject: hg: jigsaw/jake/langtools: 2 new changesets Message-ID: <201603102212.u2AMC5WJ013321@aojmv0008.oracle.com> Changeset: 47206f242e0a Author: lana Date: 2016-03-10 09:28 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/47206f242e0a Added tag jdk-9+109 for changeset f5991c73ed73 ! .hgtags Changeset: a311acb5b771 Author: mchung Date: 2016-03-10 14:09 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/a311acb5b771 Merge ! .hgtags - src/jdk.compiler/share/classes/com/sun/tools/javac/sym/CreateSymbols.java - src/jdk.compiler/share/classes/com/sun/tools/javac/sym/Profiles.java - src/jdk.compiler/share/classes/com/sun/tools/javac/util/ServiceLoader.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/AbstractProfileIndexWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfileIndexFrameWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageFrameWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageIndexFrameWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageWriterImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfileWriterImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/ProfilePackageSummaryWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/ProfileSummaryWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ProfilePackageSummaryBuilder.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ProfileSummaryBuilder.java - src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModulesXmlReader.java - src/jdk.jdeps/share/classes/com/sun/tools/jdeps/PlatformClassPath.java - test/com/sun/javadoc/testLinkOption/java/lang/StringBuilderChild.java - test/com/sun/javadoc/testLinkOption/package-list - test/com/sun/javadoc/testProfiles/TestProfiles.java - test/com/sun/javadoc/testProfiles/TestProfilesConfiguration.java - test/com/sun/javadoc/testProfiles/pkg1/Class1Pkg1.java - test/com/sun/javadoc/testProfiles/pkg1/Class2Pkg1.java - test/com/sun/javadoc/testProfiles/pkg1/Class3Pkg1.java - test/com/sun/javadoc/testProfiles/pkg1/Interface1Pkg1.java - test/com/sun/javadoc/testProfiles/pkg2/Anno1Pkg2.java - test/com/sun/javadoc/testProfiles/pkg2/Anno2Pkg2.java - test/com/sun/javadoc/testProfiles/pkg2/Class1Pkg2.java - test/com/sun/javadoc/testProfiles/pkg2/ClassError.java - test/com/sun/javadoc/testProfiles/pkg2/ClassException.java - test/com/sun/javadoc/testProfiles/pkg3/Class1Pkg3.java - test/com/sun/javadoc/testProfiles/pkg3/Class2Pkg3.java - test/com/sun/javadoc/testProfiles/pkg3/Interface1Pkg3.java - test/com/sun/javadoc/testProfiles/pkg4/Anno1Pkg4.java - test/com/sun/javadoc/testProfiles/pkg4/Class1Pkg4.java - test/com/sun/javadoc/testProfiles/pkg5/Class1Pkg5.java - test/com/sun/javadoc/testProfiles/pkg5/Interface1Pkg5.java - test/com/sun/javadoc/testProfiles/pkgDeprecated/Class1PkgDeprecated.java - test/com/sun/javadoc/testProfiles/pkgDeprecated/package-info.java - test/com/sun/javadoc/testProfiles/profile-rtjar-includes-nopkgs.txt - test/com/sun/javadoc/testProfiles/profile-rtjar-includes.txt - test/jdk/javadoc/doclet/testLinkOption/java/lang/StringBuilderChild.java - test/jdk/javadoc/doclet/testLinkOption/package-list - test/tools/javac/Object1.java - test/tools/javac/Object1.out - test/tools/javac/Object2.java - test/tools/javac/Object2.out - test/tools/javac/profiles/ProfileTest.java - test/tools/javac/proprietary/WarnClass.java - test/tools/javac/proprietary/WarnClass.out - test/tools/javac/proprietary/WarnImport.java - test/tools/javac/proprietary/WarnImport.out - test/tools/javac/proprietary/WarnMethod.java - test/tools/javac/proprietary/WarnMethod.out - test/tools/javac/proprietary/WarnStaticImport.java - test/tools/javac/proprietary/WarnStaticImport.out - test/tools/javac/proprietary/WarnVariable.java - test/tools/javac/proprietary/WarnVariable.out - test/tools/javac/proprietary/WarnWildcard.java - test/tools/javac/proprietary/WarnWildcard.out - test/tools/javac/synthesize/Boolean.java - test/tools/javac/synthesize/Byte.java - test/tools/javac/synthesize/Character.java - test/tools/javac/synthesize/Cloneable.java - test/tools/javac/synthesize/Double.java - test/tools/javac/synthesize/Float.java - test/tools/javac/synthesize/Integer.java - test/tools/javac/synthesize/Long.java - test/tools/javac/synthesize/Number.java - test/tools/javac/synthesize/Object.java - test/tools/javac/synthesize/Serializable.java - test/tools/javac/synthesize/Short.java - test/tools/javac/synthesize/Test.java - test/tools/javac/synthesize/Void.java - test/tools/jdeps/VerboseFormat/use/indirect/DontUseUnsafe2.java - test/tools/jdeps/VerboseFormat/use/indirect/UseUnsafeIndirectly.java - test/tools/jdeps/VerboseFormat/use/indirect2/DontUseUnsafe3.java - test/tools/jdeps/VerboseFormat/use/indirect2/UseUnsafeIndirectly2.java - test/tools/jdeps/VerboseFormat/use/unsafe/DontUseUnsafe.java - test/tools/jdeps/VerboseFormat/use/unsafe/UseClassWithUnsafe.java - test/tools/jdeps/VerboseFormat/use/unsafe/UseUnsafeClass.java - test/tools/jdeps/VerboseFormat/use/unsafe/UseUnsafeClass2.java - test/tools/jdeps/javax/activity/NotCompactProfile.java From mandy.chung at oracle.com Thu Mar 10 22:25:24 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 10 Mar 2016 22:25:24 +0000 Subject: hg: jigsaw/jake/jdk: 2 new changesets Message-ID: <201603102225.u2AMPOTh019472@aojmv0008.oracle.com> Changeset: 3a45b4e73ac5 Author: mchung Date: 2016-03-10 14:24 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3a45b4e73ac5 java.lang.reflect review comment ! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java Changeset: 63693c17e651 Author: mchung Date: 2016-03-10 14:25 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/63693c17e651 launcher review comment by ksrini ! src/java.base/share/classes/sun/launcher/LauncherHelper.java From james.laskey at oracle.com Thu Mar 10 23:22:53 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Thu, 10 Mar 2016 19:22:53 -0400 Subject: Initial webrev with changes for JDK 9 - jimage In-Reply-To: <56DF14EE.1050102@Oracle.com> References: <56D84C7D.9020006@oracle.com> <56DF14EE.1050102@Oracle.com> Message-ID: Thank you Roger. Comments inline. In general, I will hold off changes until after merge so as not to destabilize. Note that ImageBufferCache and Decompression are not currently used. > On Mar 8, 2016, at 2:07 PM, Roger Riggs wrote: > > Hi, > > Review comments for the jimage code in java.base, mostly cleanup but perhaps a bug or two. > General: inconsistent style and not following guidelines, copyright dates may need an update. > Use of assert for error checking is not going to catch or help isolate errors in production builds. Noted. > > dir: jdk/src/java.base/share/classes/jdk/internal/jimage/ > > > BasicImageReader: > - readHeader() exception message should say not a jimage or wrong version > Other IOExceptions can occur if the file is corrupted or is too small, array index out of bounds, etc. Replaced with specific exceptions. > > - findLocation() should use a more explicit computation for the redirection > than rehashing; this would allow the hash seed to be encapsulated. As part of the review change set, I've documented the Minimal Perfect Hash Method (see PerfectHashBuilder.) The algorithm requires a one time one rehash when there is a collision. A new seed forces a different distribution of the colliding strings. If you started with the existing hashCode, you would not get a new distribution, merely a shift of all the colliding elements. Random distribution is the essence of algorithm. > > - slice() synchronizes on the ByteBuffer; does every other access? Byte buffer use here is immutable, however slicing of the ByteBuffer does require modifying position and limit. Wrapping or cloning the buffers would be of little benefit and would take a performance hit. The ByteBuffer API might have been well served with an atomic non-modifying slice operation. > > - getAllLocations() is unused and does not respect its sorted argument; > Best to remove the method for now. Removed. > > - getResourceBuffer(): unused - remove Removed. > > - getResourceStream(): unused - remove Removed. > > ImageStringsReader: > > - Is Modified UTF-8 really needed here; using normal UTF-8 would allow > re-use and better performance. Alternatively, Modified UTF-8 should be > added as a supported encoding. Modified UTF-8 is used to be more compact and to simplify use in native code. The jimage string table has overlapping use with constant pool compaction so is really an older revision of the Modified UTF-8 standard. Not sure why Modifed UTF-8 is not offered as an encoding. It would have made constant pool management easier. And note that relying on a particular encoding is problematic. Encoding standards do change, affecting the stability of the hash algorithm and may prevent the reading of older jimage files. > > - The ImageStringsReader.hashCode() should be defined so it can take advantage of 32 or 64 bit accesses; since it is used frequently. And it needs to be stable across revisions that may be accessing jimages from different JDK versions. > Reasonable and will consider. Not sure what you mean by stable across revisions. This is not string hashCode. This is a hashCode that is specific to MPHM and is deterministic. > - stringFromMUTF8(byte[]) - there may be some optimization to avoid expanding ascii to chars and then re-encoding in String. Will touch base with the Aleksey. > > - charsFromByteBufferLength/charsFromByteBuffer should throw an exception if no terminating null, not just when assertions are enabled Will throw InternalError instead. > > - inconsistent assert errors vs exceptions for malformed mutf8. > Use of assert will not detect errors in production builds Will throw InternalError instead. > > - mutf8FromChars allocates a new working buffer (byte[8]) potentially for every UNICODE char. Will hoist the buffer allocation and reuse. > > - mutf8FromString: should take advantage of new String(bytes, offset, length, charsetName) to avoid extra allocations. > (would need a Modified utf-8 charset). Modified UTF-8 not available. > > - hashCode(byte[0, seed) should be private; the hashcode algorithm should not be variable. > This is not String hashCode. see above. > ImageLocation: > - Merge ImageLocation functions into ImageLocationBase and rename. > ImageLocation does not have enough unique functionality to be a separate class. Merged. > > - It is a poor design to create an instance that may not be valid. > It would be better to have an ImageLocation factory method that encapsulated the creation and checking > Noted. > > ImageLocationBase: > - Failing asserts will not cause a runtime error in production. > But will degenerate into unpredictable other exceptions Will throw InternalError instead. > > ImageStream: > - compress(): Too heavyweight an object to be used and discarded just for compress / decompress of small values. compress()? I don?t see ImageStream used anywhere except for large buffers. As a note, dynamic ByteBuffers really should be part of the JDK. > > > ImageBufferCache: > - Comments on each method would make the intent clear Will add comments. > > - getBuffer: mixing for loop and explicit indexes is fragile > - releaseBuffer: check buffer.capacity before threadLocal.get() for early return > - Logic of i,j is flawed, i is never changed; j is/becomes 0 > The first buffer is removed if there are more than max > Its not clear what algorithm was intended. > A buffer that is in use can be removed. Rewrote using lambdas to clarify the algorithm. > > - ImageBufferCache constructor: the isUsed flag should be set in getBuffer() > when it is added to the list (not in the constructor) > It keeps it consistent with when it is set for a re-used buffer. > Modified. > ImageHeader: > - BADMAGIC is not used Removed. > > - readFrom could throw BufferUnderflowException - undocumented get(i) can IndexOutOfBoundsException [and get() BufferUnderflowException] Will add explicit check. > > ImageModuleData: > - ImageModuleData seems to be unused; allModuleNames() is unreferenced > Removed. > > ImageReader: > - ImageReader(path): unused - remove Removed. > > - Use of assert is non-reassuring, ineffective in production builds Added explicit check. > > - In a long running application the per thread buffers will get to the point wehere they are unused and should be released. > There is no support for soft or weak references to handle that case. > Alternatively, if the buffers were not per thread then they would have a lesser impact. The core libs team was concerned about the performance of class loading. The pattern used here is the one followed by NIO. We will probably come up with a shared NIO cache at some point. > Also, why should there be more than one buffer per thread? The image cache is only used by 32 bit systems and decompression. It is possible for a channel read buffer and a decompression buffer to be allocated at the same time. > > ImageReader.Resource: > - unused create method Removed. > > - unused parent argument (0) in Resource constructor (dir, loc, attr) Removed. > > ImageReader.LinkNode: > - constructor has unused parent arg > > Removed > decompress/CompressIndexes: > - readInt: wasteful allocation of a single byte array and then another small byte array; > and then another heap buffer allocation in the ByteBuffer. Removed all allocation. > > - decompress is hugely wasteful of allocations of ByteBuffers of small sizes. > Removed all allocation. > decompress/CompressedResourceHeader: > - MAGIC does not need to be public > > > decompress/Decompressor: > - IOException "Plugin name not found" should include the missing name > > - StringsProvider is an unnecessary interface; could use Supplier > > - Redundant public modifiers in interface declarations > > decompress/SignatureParser: > - Comments describing the input and output formats needed > > - style around operators does not consistently include spaces; and "if("... > > decompress/StringSharingDecompressor: > - Wasteful use of ByteBuffers and small arrays without re-use (safeAdd...) > > - StringSharingDecompressor constructor with unused argument - remove > > > decompress/ZipDecompressor: > - Should be more specific about the zip algorithms supported > since it needs to be stable across releases > > - decompress(): use try-with-resources for safer inflation > I think decompression needs significant reworking.. > src/java.base/share/native/libjimage/imageDecompressor.cpp > - "// If ptr is not aligned, sparc will fail." implies input argument must be aligned > > - General doubt about using assert; for example to check on malloc allocation failure > > - In production environment will exhibit as segv > Noted. From njbartlett at gmail.com Thu Mar 10 23:58:59 2016 From: njbartlett at gmail.com (Neil Bartlett) Date: Thu, 10 Mar 2016 23:58:59 +0000 Subject: Unnamed module and duplicate package In-Reply-To: References: Message-ID: Paul, This sounds like you are suggesting a backwards-incompatible change to the behaviour of the application classpath. For example, many apps include on their classpath a library containing javax.transaction.xa, since the version of this package provided by the JDK is broken (omits several types). In general it has always been permissible for applications to provide their own alternative implementations of the javax.* hierarchy, with only the java.* hierarchy being off-limits due to the SecurityException that would be thrown by ClassLoader.defineClass. Neil > On 10 Mar 2016, at 21:25, Paul Benedict wrote: > > Alex, > > For the sake of usability, however, it would be nice if the JDK verified > that jars do not contain any exported JDK packages. This would be an RFE. I > understand that in order to avoid split packages between modules and > classpath, the module version takes precedent. For developer vs. developer > code, I find that reasoning fine. However, I really would like to treat the > JDK as "special" (your words) because in my experience, I see developers > constantly perplexed by NoClassDefFoundError when something occurred like > you just detailed. > > I'd like to refer you to the Servlet 3.1 spec [1], section 10.7.2, as an > analogous concern to mine. This is the so-called "prohibited classes" > violation clause: > > "As described in the Java EE license agreement, servlet containers that are > not part of a Java EE product should not allow the application to override > Java SE platform classes, such as those in the java.* and javax.* > namespaces, that Java SE does not allow to be modified. The container > should not allow applications to override or access the container?s > implementation classes." > > I don't think it's good usability to let JDK packages in the classpath go > silently unchallenged and unloaded. I recommend they are reported as an > error. > > > [1] https://java.net/downloads/servlet-spec/Final/servlet-3_1-final.pdf > > Cheers, > Paul > > On Thu, Mar 10, 2016 at 2:30 PM, Alex Buckley > > wrote: > >> I see xml-apis.jar (2.0.2) contains: >> >> - a javax.xml.parser package, which includes a FactoryFinder class that's >> not in Java SE, and >> >> - a javax.xml.transform package hierarchy, whose types at first glance >> look identical to those in Java SE except for yet another FactoryFinder >> class in javax.xml.transform. >> >> If you put xml-apis.jar on the classpath, its javax.xml.** packages will >> be ignored. The unnamed module reads the java.xml module which exports >> javax.xml.** packages (assuming java.xml in the system image, of course), >> so the application class loader delegates for javax.xml.** packages to the >> loader responsible for the java.xml module. User code that tries to access >> FactoryFinder will get a NoClassDefFoundError. >> >> There's nothing special about JDK modules here. The same >> NoClassDefFoundError would occur if the system image contained a module >> exporting some package, and a JAR on the classpath contained the same >> package with extra classes, and some code on the classpath tried to access >> those extra classes. Since the module in the system image is probably the >> rightful owner/exporter of the package, hard questions should be asked >> about the provenance of the JAR on the classpath. >> >> There has been some discussion of a jdeps-like tool that detects when a >> JAR on your classpath is trying to split a JDK package: >> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-November/005227.html >> . >> >> Alex >> >> On 3/10/2016 10:27 AM, Paul Benedict wrote: >> >>> Alex, there are JARs that contain javax packages. Anyone in the web >>> development community knows how many people have included xml-apis in >>> their WEB-INF :-) only to find out it wasn't loaded or it took precedent >>> over the JDK versions. >>> >>> Has Jigsaw introduced any restrictions here on this front? Honestly, I >>> think the JDK should make it illegal for the classpath to contain ANY >>> packages that the jdk has. Please opine when it is convenient for you. >>> >>> Cheers, >>> Paul >>> >>> On Wed, Mar 9, 2016 at 5:13 PM, Alex Buckley >> >> wrote: >>> >>> Paul, thank you for asking. The module system's treatment of the >>> unnamed module vis-a-vis named modules is probably the biggest >>> factor affecting usability of the module system. This is true almost >>> by definition because at JDK 9 GA the only named modules in the >>> world will be the JDK's while every other class will be in the >>> unnamed module of the application class loader. >>> >>> So please, ask more questions about the unnamed module. I am >>> especially interested to know if anyone has JARs that contain javax >>> packages (or heaven forbid, sun or com.sun packages) found in the >>> JDK -- such JARs are a mortal danger to interop between unnamed and >>> named modules. >>> >>> Alex >>> >>> On 3/9/2016 1:47 PM, Paul Benedict wrote: >>> >>> Thank you Alex. Since it's roughly the same as JDK 8, then it's >>> also not >>> worse. I defer to your explanation on that point. >>> >>> Cheers, >>> Paul >>> >>> On Wed, Mar 9, 2016 at 3:37 PM, Alex Buckley >>> > >>> >>> >> wrote: >>> >>> Presumably you would count the equivalent scenario on JDK 8 >>> -- my >>> package A is in Alex.jar on the classpath and your package >>> A is in >>> Paul.jar on the classpath -- as a security issue too, >>> because some >>> of my classes may substitute for yours (or some of yours >>> for mine, >>> depending on how the classpath is constructed). >>> >>> On JDK 9, we do the "substitution" cleanly. Package A is >>> not split. >>> That avoids one category of error (ClassCastException). >>> What about >>> poor package B that finds itself accessing a different >>> package A >>> than it was compiled with? Well, since package A is >>> exported by a >>> named module, it's reasonable to assume that the named >>> module "owns" >>> package A [*], and that the developer of package B >>> co-bundled some >>> version of package A without renaming it. Dangerous in JDK 8, >>> dangerous in JDK 9. (We're trying to encapsulate the >>> internals of a >>> module, which is different from trying to isolate modules >>> from each >>> other.) >>> >>> [*] Advanced scenario: the named module exporting A is >>> actually an >>> automatic module which happened to co-bundle package A. By >>> placing >>> this JAR on the modulepath to form an automatic module, it >>> dominates >>> the JAR left on the classpath which also co-bundled package >>> A. >>> >>> Alex >>> >>> On 3/9/2016 1:17 PM, Paul Benedict wrote: >>> >>> But isn't what your proposing a security issue? Let's >>> say my >>> package A >>> is in the unnamed module and your package A is in a named >>> module. You >>> basically took over my code; your classes will be >>> substituted >>> for mine. >>> >>> Cheers, >>> Paul >>> >>> On Wed, Mar 9, 2016 at 2:38 PM, Alex Buckley >>> >>> > >>> >> >>> >>> >>> >>> >> >>> wrote: >>> >>> On 3/9/2016 10:36 AM, Paul Benedict wrote: >>> >>> From the doc: >>> "If a package is defined in both a named >>> module and the >>> unnamed >>> module then >>> the package in the unnamed module is ignored. >>> This >>> preserves >>> reliable >>> configuration even in the face of the chaos of >>> the >>> class path, >>> ensuring >>> that every module still reads at most one >>> module defining a >>> given package. >>> If, in our example above, a JAR file on the >>> class path >>> contains >>> a class >>> file named >>> com/foo/bar/alpha/AlphaFactory.class then >>> that file >>> will never >>> be loaded, since the com.foo.bar.alpha package >>> is >>> exported by the >>> com.foo.bar module." >>> >>> I would like some clarification. Correct me if >>> wrong, but I >>> think this >>> entire paragraph is really meant to be about the >>> perspective from a >>> modularized JAR? If a module has package A, >>> and the unnamed >>> module has >>> package A, then of course the module's package >>> A should >>> win. >>> >>> However, if it is meant to be absolute >>> language, then I >>> disagree. >>> >>> The unnamed module should be coherent among >>> itself. If the >>> unnamed module >>> has package B and relies on classes from >>> package A, it >>> should >>> still be able >>> to see its own package A. I don't think >>> modules should >>> be able >>> to impact >>> how the unnamed module sees itself. That's a >>> surprising >>> situation. >>> >>> >>> The unnamed module is not a root module during >>> resolution. >>> If your >>> main class is in the unnamed module (i.e. you did >>> java -jar >>> MyApp.jar rather than java -m MyApp), then the >>> module graph is >>> created by resolving various root modules (what >>> are they? >>> separate >>> discussion) and only then is the unnamed module >>> hooked up >>> to read >>> every module in the graph. >>> >>> Hope we're OK so far. >>> >>> If some named module in the graph exports package >>> A (more >>> than one >>> module exporting A? separate discussion), then >>> since the >>> unnamed >>> module reads that named module, the unnamed module >>> will >>> access A.* >>> types from that named module. >>> >>> It's hard to imagine the unnamed module NOT >>> accessing A.* >>> types from >>> that named module. Primarily, we need to avoid a >>> split package >>> situation where code in the unnamed module sometimes >>> accesses A.* >>> types from the named module and sometimes from the >>> unnamed >>> module. >>> >>> You might say, OK, let code in the unnamed module >>> exclusively access >>> A.* in the unnamed module rather than exclusively >>> access >>> A.* in the >>> named module. Then you have two problems: >>> >>> 1. There are issues for named modules in the same >>> class >>> loader as >>> the unnamed module -- such named modules MUST get >>> A.* from >>> the named >>> module rather than the unnamed module, and the >>> class loading >>> mechanism is incapable of switching based on >>> accessor. It'll be >>> common for named modules to exist in the same >>> class loader >>> as the >>> unnamed module, as modular JARs on the modulepath >>> and >>> non-modular >>> JARs on the classpath all end up in the >>> application class >>> loader >>> (modular JARs as named modules; non-modular JARs >>> jointly as the >>> unnamed module). >>> >>> 2. While the module system is sure that package A >>> exists in the >>> named module, how would the module system possibly >>> know >>> that package >>> A exists in the unnamed module? Scanning every >>> class file >>> in every >>> non-modular JAR on the classpath at startup sounds >>> bad. >>> >>> Alex From jonathan.gibbons at oracle.com Fri Mar 11 00:35:04 2016 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 11 Mar 2016 00:35:04 +0000 Subject: hg: jigsaw/jake/langtools: 2 new changesets Message-ID: <201603110035.u2B0Z4fI010852@aojmv0008.oracle.com> Changeset: ea916dd6ad45 Author: jjg Date: 2016-03-10 16:09 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/ea916dd6ad45 fix CSS issues and merge issues ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlStyle.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css ! test/com/sun/javadoc/testHtmlVersion/TestHtmlVersion.java ! test/com/sun/javadoc/testNavigation/TestNavigation.java ! test/jdk/javadoc/doclet/testHtmlVersion/TestHtmlVersion.java ! test/jdk/javadoc/doclet/testNavigation/TestNavigation.java Changeset: 150181ee7368 Author: jjg Date: 2016-03-10 16:34 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/150181ee7368 remove interim module support from old doclet - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/AbstractModuleIndexWriter.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/AbstractPackageIndexWriter.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ModuleIndexFrameWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ModulePackageIndexFrameWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ModuleWriterImpl.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/WriterFactoryImpl.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlConstants.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlStyle.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/ModuleSummaryWriter.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/WriterFactory.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/builders/BuilderFactory.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ModuleSummaryBuilder.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclet.xml ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets.properties ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPaths.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/util/MetaKeywords.java From jonathan.gibbons at oracle.com Fri Mar 11 01:10:48 2016 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 11 Mar 2016 01:10:48 +0000 Subject: hg: jigsaw/jake/langtools: prohibit -sourcepath and -modulesourcepath together Message-ID: <201603110110.u2B1AmEB024483@aojmv0008.oracle.com> Changeset: d34fb849c377 Author: jjg Date: 2016-03-10 17:10 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/d34fb849c377 prohibit -sourcepath and -modulesourcepath together ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Arguments.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties ! test/tools/javac/modules/ModuleSourcePathTest.java From jonathan.gibbons at oracle.com Fri Mar 11 01:26:31 2016 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 11 Mar 2016 01:26:31 +0000 Subject: hg: jigsaw/jake/langtools: suppress -sourcepath in internal Ant build Message-ID: <201603110126.u2B1QVox000580@aojmv0008.oracle.com> Changeset: 28556ee3299f Author: jjg Date: 2016-03-10 17:26 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/28556ee3299f suppress -sourcepath in internal Ant build ! make/build.xml From alex.buckley at oracle.com Fri Mar 11 02:14:45 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 10 Mar 2016 18:14:45 -0800 Subject: Unnamed module and duplicate package In-Reply-To: References: Message-ID: <56E22A15.2080402@oracle.com> The subtlety is that the Endorsed Standards Override Mechanism interpreted "alternative implementations of the javax.* hierarchy" as "wholesale replacements of entire javax.* packages placed in the location specified by java.endorsed.dirs". It was never permissible to simply throw a handful of javax.* types on the classpath and have them augment JDK packages. As unsupported as sun.misc.Unsafe, as the saying might go. Let's talk about the Java Transaction API, javax.transaction.xa plus some of javax.transaction. Unfortunately, JTA was never listed at http://docs.oracle.com/javase/8/docs/technotes/guides/standards/index.html as a Standalone Technology capable of being replaced wholesale by the Endorsed Standards Override Mechanism. We believe this was an oversight; to be fair, it does rather excuse throwing javax.transaction.xa types on to the classpath. Anyway, in Java SE 9, the concept of Standalone Technology has turned into the concept of upgradeable module (where you specify a wholesale replacement of a Java SE module to -upgrademodulepath), and the ill-documented Standalone Technology of JTA has turned into the upgradeable module java.transaction. tl;dr Since you were and are meant to replace javax.* packages in a wholesale fashion using a first-class mechanism, Paul's suggestion is morally backwards-compatible. Practically, it might be a different story. Alex On 3/10/2016 3:58 PM, Neil Bartlett wrote: > Paul, > > This sounds like you are suggesting a backwards-incompatible change to > the behaviour of the application classpath. > > For example, many apps include on their classpath a library containing > javax.transaction.xa, since the version of this package provided by the > JDK is broken (omits several types). > > In general it has always been permissible for applications to provide > their own alternative implementations of the javax.* hierarchy, with > only the java.* hierarchy being off-limits due to the SecurityException > that would be thrown by ClassLoader.defineClass. > > Neil > > >> On 10 Mar 2016, at 21:25, Paul Benedict > > wrote: >> >> Alex, >> >> For the sake of usability, however, it would be nice if the JDK verified >> that jars do not contain any exported JDK packages. This would be an >> RFE. I >> understand that in order to avoid split packages between modules and >> classpath, the module version takes precedent. For developer vs. developer >> code, I find that reasoning fine. However, I really would like to >> treat the >> JDK as "special" (your words) because in my experience, I see developers >> constantly perplexed by NoClassDefFoundError when something occurred like >> you just detailed. >> >> I'd like to refer you to the Servlet 3.1 spec [1], section 10.7.2, as an >> analogous concern to mine. This is the so-called "prohibited classes" >> violation clause: >> >> "As described in the Java EE license agreement, servlet containers >> that are >> not part of a Java EE product should not allow the application to override >> Java SE platform classes, such as those in the java.* and javax.* >> namespaces, that Java SE does not allow to be modified. The container >> should not allow applications to override or access the container?s >> implementation classes." >> >> I don't think it's good usability to let JDK packages in the classpath go >> silently unchallenged and unloaded. I recommend they are reported as an >> error. >> >> >> [1]https://java.net/downloads/servlet-spec/Final/servlet-3_1-final.pdf >> >> Cheers, >> Paul >> >> On Thu, Mar 10, 2016 at 2:30 PM, Alex Buckley > > >> wrote: >> >>> I see xml-apis.jar (2.0.2) contains: >>> >>> - a javax.xml.parser package, which includes a FactoryFinder class that's >>> not in Java SE, and >>> >>> - a javax.xml.transform package hierarchy, whose types at first glance >>> look identical to those in Java SE except for yet another FactoryFinder >>> class in javax.xml.transform. >>> >>> If you put xml-apis.jar on the classpath, its javax.xml.** packages will >>> be ignored. The unnamed module reads the java.xml module which exports >>> javax.xml.** packages (assuming java.xml in the system image, of course), >>> so the application class loader delegates for javax.xml.** packages >>> to the >>> loader responsible for the java.xml module. User code that tries to >>> access >>> FactoryFinder will get a NoClassDefFoundError. >>> >>> There's nothing special about JDK modules here. The same >>> NoClassDefFoundError would occur if the system image contained a module >>> exporting some package, and a JAR on the classpath contained the same >>> package with extra classes, and some code on the classpath tried to >>> access >>> those extra classes. Since the module in the system image is probably the >>> rightful owner/exporter of the package, hard questions should be asked >>> about the provenance of the JAR on the classpath. >>> >>> There has been some discussion of a jdeps-like tool that detects when a >>> JAR on your classpath is trying to split a JDK package: >>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-November/005227.html >>> . >>> >>> Alex >>> >>> On 3/10/2016 10:27 AM, Paul Benedict wrote: >>> >>>> Alex, there are JARs that contain javax packages. Anyone in the web >>>> development community knows how many people have included xml-apis in >>>> their WEB-INF :-) only to find out it wasn't loaded or it took precedent >>>> over the JDK versions. >>>> >>>> Has Jigsaw introduced any restrictions here on this front? Honestly, I >>>> think the JDK should make it illegal for the classpath to contain ANY >>>> packages that the jdk has. Please opine when it is convenient for you. >>>> >>>> Cheers, >>>> Paul >>>> >>>> On Wed, Mar 9, 2016 at 5:13 PM, Alex Buckley >>>> >>>> > wrote: >>>> >>>> Paul, thank you for asking. The module system's treatment of the >>>> unnamed module vis-a-vis named modules is probably the biggest >>>> factor affecting usability of the module system. This is true almost >>>> by definition because at JDK 9 GA the only named modules in the >>>> world will be the JDK's while every other class will be in the >>>> unnamed module of the application class loader. >>>> >>>> So please, ask more questions about the unnamed module. I am >>>> especially interested to know if anyone has JARs that contain javax >>>> packages (or heaven forbid, sun or com.sun packages) found in the >>>> JDK -- such JARs are a mortal danger to interop between unnamed and >>>> named modules. >>>> >>>> Alex >>>> >>>> On 3/9/2016 1:47 PM, Paul Benedict wrote: >>>> >>>> Thank you Alex. Since it's roughly the same as JDK 8, then it's >>>> also not >>>> worse. I defer to your explanation on that point. >>>> >>>> Cheers, >>>> Paul >>>> >>>> On Wed, Mar 9, 2016 at 3:37 PM, Alex Buckley >>>> >>> >>>> >>> >> wrote: >>>> >>>> Presumably you would count the equivalent scenario on JDK 8 >>>> -- my >>>> package A is in Alex.jar on the classpath and your package >>>> A is in >>>> Paul.jar on the classpath -- as a security issue too, >>>> because some >>>> of my classes may substitute for yours (or some of yours >>>> for mine, >>>> depending on how the classpath is constructed). >>>> >>>> On JDK 9, we do the "substitution" cleanly. Package A is >>>> not split. >>>> That avoids one category of error (ClassCastException). >>>> What about >>>> poor package B that finds itself accessing a different >>>> package A >>>> than it was compiled with? Well, since package A is >>>> exported by a >>>> named module, it's reasonable to assume that the named >>>> module "owns" >>>> package A [*], and that the developer of package B >>>> co-bundled some >>>> version of package A without renaming it. Dangerous in >>>> JDK 8, >>>> dangerous in JDK 9. (We're trying to encapsulate the >>>> internals of a >>>> module, which is different from trying to isolate modules >>>> from each >>>> other.) >>>> >>>> [*] Advanced scenario: the named module exporting A is >>>> actually an >>>> automatic module which happened to co-bundle package A. By >>>> placing >>>> this JAR on the modulepath to form an automatic module, it >>>> dominates >>>> the JAR left on the classpath which also co-bundled package >>>> A. >>>> >>>> Alex >>>> >>>> On 3/9/2016 1:17 PM, Paul Benedict wrote: >>>> >>>> But isn't what your proposing a security issue? Let's >>>> say my >>>> package A >>>> is in the unnamed module and your package A is in a >>>> named >>>> module. You >>>> basically took over my code; your classes will be >>>> substituted >>>> for mine. >>>> >>>> Cheers, >>>> Paul >>>> >>>> On Wed, Mar 9, 2016 at 2:38 PM, Alex Buckley >>>> >>> >>>> >>> > >>>> >>> >>>> >>>> >>> >>> wrote: >>>> >>>> On 3/9/2016 10:36 AM, Paul Benedict wrote: >>>> >>>> From the doc: >>>> "If a package is defined in both a named >>>> module and the >>>> unnamed >>>> module then >>>> the package in the unnamed module is ignored. >>>> This >>>> preserves >>>> reliable >>>> configuration even in the face of the chaos of >>>> the >>>> class path, >>>> ensuring >>>> that every module still reads at most one >>>> module defining a >>>> given package. >>>> If, in our example above, a JAR file on the >>>> class path >>>> contains >>>> a class >>>> file named >>>> com/foo/bar/alpha/AlphaFactory.class then >>>> that file >>>> will never >>>> be loaded, since the com.foo.bar.alpha package >>>> is >>>> exported by the >>>> com.foo.bar module." >>>> >>>> I would like some clarification. Correct me if >>>> wrong, but I >>>> think this >>>> entire paragraph is really meant to be >>>> about the >>>> perspective from a >>>> modularized JAR? If a module has package A, >>>> and the unnamed >>>> module has >>>> package A, then of course the module's package >>>> A should >>>> win. >>>> >>>> However, if it is meant to be absolute >>>> language, then I >>>> disagree. >>>> >>>> The unnamed module should be coherent among >>>> itself. If the >>>> unnamed module >>>> has package B and relies on classes from >>>> package A, it >>>> should >>>> still be able >>>> to see its own package A. I don't think >>>> modules should >>>> be able >>>> to impact >>>> how the unnamed module sees itself. That's a >>>> surprising >>>> situation. >>>> >>>> >>>> The unnamed module is not a root module during >>>> resolution. >>>> If your >>>> main class is in the unnamed module (i.e. you did >>>> java -jar >>>> MyApp.jar rather than java -m MyApp), then the >>>> module graph is >>>> created by resolving various root modules (what >>>> are they? >>>> separate >>>> discussion) and only then is the unnamed module >>>> hooked up >>>> to read >>>> every module in the graph. >>>> >>>> Hope we're OK so far. >>>> >>>> If some named module in the graph exports package >>>> A (more >>>> than one >>>> module exporting A? separate discussion), then >>>> since the >>>> unnamed >>>> module reads that named module, the unnamed module >>>> will >>>> access A.* >>>> types from that named module. >>>> >>>> It's hard to imagine the unnamed module NOT >>>> accessing A.* >>>> types from >>>> that named module. Primarily, we need to avoid a >>>> split package >>>> situation where code in the unnamed module >>>> sometimes >>>> accesses A.* >>>> types from the named module and sometimes from the >>>> unnamed >>>> module. >>>> >>>> You might say, OK, let code in the unnamed module >>>> exclusively access >>>> A.* in the unnamed module rather than exclusively >>>> access >>>> A.* in the >>>> named module. Then you have two problems: >>>> >>>> 1. There are issues for named modules in the same >>>> class >>>> loader as >>>> the unnamed module -- such named modules MUST get >>>> A.* from >>>> the named >>>> module rather than the unnamed module, and the >>>> class loading >>>> mechanism is incapable of switching based on >>>> accessor. It'll be >>>> common for named modules to exist in the same >>>> class loader >>>> as the >>>> unnamed module, as modular JARs on the modulepath >>>> and >>>> non-modular >>>> JARs on the classpath all end up in the >>>> application class >>>> loader >>>> (modular JARs as named modules; non-modular JARs >>>> jointly as the >>>> unnamed module). >>>> >>>> 2. While the module system is sure that package A >>>> exists in the >>>> named module, how would the module system possibly >>>> know >>>> that package >>>> A exists in the unnamed module? Scanning every >>>> class file >>>> in every >>>> non-modular JAR on the classpath at startup sounds >>>> bad. >>>> >>>> Alex > From stephen.felts at oracle.com Fri Mar 11 02:33:48 2016 From: stephen.felts at oracle.com (Stephen Felts) Date: Thu, 10 Mar 2016 18:33:48 -0800 (PST) Subject: Unnamed module and duplicate package In-Reply-To: <56E22A15.2080402@oracle.com> References: <56E22A15.2080402@oracle.com> Message-ID: I'm aware of classes in our application server (not javax) that are unused when running with our own JVM and used when running with another JVM. In that case, the packages are duplicate of classes in the JDK. I would not want that usage to generate a fatal error. This is unrelated to endorsed jar files. In addition to an upgradeable module for java.transaction.jar with Jigsaw, I'm also running with an upgradeable module for javax.annotation-api-1.2.jar. -----Original Message----- From: Alex Buckley Sent: Thursday, March 10, 2016 9:15 PM To: jigsaw-dev at openjdk.java.net Subject: Re: Unnamed module and duplicate package The subtlety is that the Endorsed Standards Override Mechanism interpreted "alternative implementations of the javax.* hierarchy" as "wholesale replacements of entire javax.* packages placed in the location specified by java.endorsed.dirs". It was never permissible to simply throw a handful of javax.* types on the classpath and have them augment JDK packages. As unsupported as sun.misc.Unsafe, as the saying might go. Let's talk about the Java Transaction API, javax.transaction.xa plus some of javax.transaction. Unfortunately, JTA was never listed at http://docs.oracle.com/javase/8/docs/technotes/guides/standards/index.html as a Standalone Technology capable of being replaced wholesale by the Endorsed Standards Override Mechanism. We believe this was an oversight; to be fair, it does rather excuse throwing javax.transaction.xa types on to the classpath. Anyway, in Java SE 9, the concept of Standalone Technology has turned into the concept of upgradeable module (where you specify a wholesale replacement of a Java SE module to -upgrademodulepath), and the ill-documented Standalone Technology of JTA has turned into the upgradeable module java.transaction. tl;dr Since you were and are meant to replace javax.* packages in a wholesale fashion using a first-class mechanism, Paul's suggestion is morally backwards-compatible. Practically, it might be a different story. Alex On 3/10/2016 3:58 PM, Neil Bartlett wrote: > Paul, > > This sounds like you are suggesting a backwards-incompatible change to > the behaviour of the application classpath. > > For example, many apps include on their classpath a library containing > javax.transaction.xa, since the version of this package provided by > the JDK is broken (omits several types). > > In general it has always been permissible for applications to provide > their own alternative implementations of the javax.* hierarchy, with > only the java.* hierarchy being off-limits due to the > SecurityException that would be thrown by ClassLoader.defineClass. > > Neil > > >> On 10 Mar 2016, at 21:25, Paul Benedict > > wrote: >> >> Alex, >> >> For the sake of usability, however, it would be nice if the JDK >> verified that jars do not contain any exported JDK packages. This >> would be an RFE. I understand that in order to avoid split packages >> between modules and classpath, the module version takes precedent. >> For developer vs. developer code, I find that reasoning fine. >> However, I really would like to treat the JDK as "special" (your >> words) because in my experience, I see developers constantly >> perplexed by NoClassDefFoundError when something occurred like you >> just detailed. >> >> I'd like to refer you to the Servlet 3.1 spec [1], section 10.7.2, as >> an analogous concern to mine. This is the so-called "prohibited classes" >> violation clause: >> >> "As described in the Java EE license agreement, servlet containers >> that are not part of a Java EE product should not allow the >> application to override Java SE platform classes, such as those in >> the java.* and javax.* namespaces, that Java SE does not allow to be >> modified. The container should not allow applications to override or >> access the container?s implementation classes." >> >> I don't think it's good usability to let JDK packages in the >> classpath go silently unchallenged and unloaded. I recommend they are >> reported as an error. >> >> >> [1]https://java.net/downloads/servlet-spec/Final/servlet-3_1-final.pd >> f >> >> Cheers, >> Paul >> >> On Thu, Mar 10, 2016 at 2:30 PM, Alex Buckley >> > >> wrote: >> >>> I see xml-apis.jar (2.0.2) contains: >>> >>> - a javax.xml.parser package, which includes a FactoryFinder class >>> that's not in Java SE, and >>> >>> - a javax.xml.transform package hierarchy, whose types at first >>> glance look identical to those in Java SE except for yet another >>> FactoryFinder class in javax.xml.transform. >>> >>> If you put xml-apis.jar on the classpath, its javax.xml.** packages >>> will be ignored. The unnamed module reads the java.xml module which >>> exports >>> javax.xml.** packages (assuming java.xml in the system image, of >>> course), so the application class loader delegates for javax.xml.** >>> packages to the loader responsible for the java.xml module. User >>> code that tries to access FactoryFinder will get a >>> NoClassDefFoundError. >>> >>> There's nothing special about JDK modules here. The same >>> NoClassDefFoundError would occur if the system image contained a >>> module exporting some package, and a JAR on the classpath contained >>> the same package with extra classes, and some code on the classpath >>> tried to access those extra classes. Since the module in the system >>> image is probably the rightful owner/exporter of the package, hard >>> questions should be asked about the provenance of the JAR on the >>> classpath. >>> >>> There has been some discussion of a jdeps-like tool that detects >>> when a JAR on your classpath is trying to split a JDK package: >>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-November/0052 >>> 27.html >>> . >>> >>> Alex >>> >>> On 3/10/2016 10:27 AM, Paul Benedict wrote: >>> >>>> Alex, there are JARs that contain javax packages. Anyone in the web >>>> development community knows how many people have included xml-apis >>>> in their WEB-INF :-) only to find out it wasn't loaded or it took >>>> precedent over the JDK versions. >>>> >>>> Has Jigsaw introduced any restrictions here on this front? >>>> Honestly, I think the JDK should make it illegal for the classpath >>>> to contain ANY packages that the jdk has. Please opine when it is convenient for you. >>>> >>>> Cheers, >>>> Paul >>>> >>>> On Wed, Mar 9, 2016 at 5:13 PM, Alex Buckley >>>> >>>> > wrote: >>>> >>>> Paul, thank you for asking. The module system's treatment of the >>>> unnamed module vis-a-vis named modules is probably the biggest >>>> factor affecting usability of the module system. This is true almost >>>> by definition because at JDK 9 GA the only named modules in the >>>> world will be the JDK's while every other class will be in the >>>> unnamed module of the application class loader. >>>> >>>> So please, ask more questions about the unnamed module. I am >>>> especially interested to know if anyone has JARs that contain javax >>>> packages (or heaven forbid, sun or com.sun packages) found in the >>>> JDK -- such JARs are a mortal danger to interop between unnamed and >>>> named modules. >>>> >>>> Alex >>>> >>>> On 3/9/2016 1:47 PM, Paul Benedict wrote: >>>> >>>> Thank you Alex. Since it's roughly the same as JDK 8, then it's >>>> also not >>>> worse. I defer to your explanation on that point. >>>> >>>> Cheers, >>>> Paul >>>> >>>> On Wed, Mar 9, 2016 at 3:37 PM, Alex Buckley >>>> >>> >>>> >>> >> wrote: >>>> >>>> Presumably you would count the equivalent scenario on JDK 8 >>>> -- my >>>> package A is in Alex.jar on the classpath and your package >>>> A is in >>>> Paul.jar on the classpath -- as a security issue too, >>>> because some >>>> of my classes may substitute for yours (or some of yours >>>> for mine, >>>> depending on how the classpath is constructed). >>>> >>>> On JDK 9, we do the "substitution" cleanly. Package A is >>>> not split. >>>> That avoids one category of error (ClassCastException). >>>> What about >>>> poor package B that finds itself accessing a different >>>> package A >>>> than it was compiled with? Well, since package A is >>>> exported by a >>>> named module, it's reasonable to assume that the named >>>> module "owns" >>>> package A [*], and that the developer of package B >>>> co-bundled some >>>> version of package A without renaming it. Dangerous in >>>> JDK 8, >>>> dangerous in JDK 9. (We're trying to encapsulate the >>>> internals of a >>>> module, which is different from trying to isolate modules >>>> from each >>>> other.) >>>> >>>> [*] Advanced scenario: the named module exporting A is >>>> actually an >>>> automatic module which happened to co-bundle package A. By >>>> placing >>>> this JAR on the modulepath to form an automatic module, it >>>> dominates >>>> the JAR left on the classpath which also co-bundled >>>> package A. >>>> >>>> Alex >>>> >>>> On 3/9/2016 1:17 PM, Paul Benedict wrote: >>>> >>>> But isn't what your proposing a security issue? Let's >>>> say my >>>> package A >>>> is in the unnamed module and your package A is in a >>>> named >>>> module. You >>>> basically took over my code; your classes will be >>>> substituted >>>> for mine. >>>> >>>> Cheers, >>>> Paul >>>> >>>> On Wed, Mar 9, 2016 at 2:38 PM, Alex Buckley >>>> >>> >>>> >>> > >>>> >>> >>>> >>>> >>> >>> wrote: >>>> >>>> On 3/9/2016 10:36 AM, Paul Benedict wrote: >>>> >>>> From the doc: >>>> "If a package is defined in both a named >>>> module and the >>>> unnamed >>>> module then >>>> the package in the unnamed module is ignored. >>>> This >>>> preserves >>>> reliable >>>> configuration even in the face of the >>>> chaos of the >>>> class path, >>>> ensuring >>>> that every module still reads at most one >>>> module defining a >>>> given package. >>>> If, in our example above, a JAR file on the >>>> class path >>>> contains >>>> a class >>>> file named >>>> com/foo/bar/alpha/AlphaFactory.class then >>>> that file >>>> will never >>>> be loaded, since the com.foo.bar.alpha >>>> package is >>>> exported by the >>>> com.foo.bar module." >>>> >>>> I would like some clarification. Correct me if >>>> wrong, but I >>>> think this >>>> entire paragraph is really meant to be >>>> about the >>>> perspective from a >>>> modularized JAR? If a module has package A, >>>> and the unnamed >>>> module has >>>> package A, then of course the module's package >>>> A should >>>> win. >>>> >>>> However, if it is meant to be absolute >>>> language, then I >>>> disagree. >>>> >>>> The unnamed module should be coherent among >>>> itself. If the >>>> unnamed module >>>> has package B and relies on classes from >>>> package A, it >>>> should >>>> still be able >>>> to see its own package A. I don't think >>>> modules should >>>> be able >>>> to impact >>>> how the unnamed module sees itself. That's a >>>> surprising >>>> situation. >>>> >>>> >>>> The unnamed module is not a root module during >>>> resolution. >>>> If your >>>> main class is in the unnamed module (i.e. you did >>>> java -jar >>>> MyApp.jar rather than java -m MyApp), then the >>>> module graph is >>>> created by resolving various root modules (what >>>> are they? >>>> separate >>>> discussion) and only then is the unnamed module >>>> hooked up >>>> to read >>>> every module in the graph. >>>> >>>> Hope we're OK so far. >>>> >>>> If some named module in the graph exports package >>>> A (more >>>> than one >>>> module exporting A? separate discussion), then >>>> since the >>>> unnamed >>>> module reads that named module, the unnamed module >>>> will >>>> access A.* >>>> types from that named module. >>>> >>>> It's hard to imagine the unnamed module NOT >>>> accessing A.* >>>> types from >>>> that named module. Primarily, we need to avoid a >>>> split package >>>> situation where code in the unnamed module >>>> sometimes >>>> accesses A.* >>>> types from the named module and sometimes from the >>>> unnamed >>>> module. >>>> >>>> You might say, OK, let code in the unnamed module >>>> exclusively access >>>> A.* in the unnamed module rather than exclusively >>>> access >>>> A.* in the >>>> named module. Then you have two problems: >>>> >>>> 1. There are issues for named modules in the same >>>> class >>>> loader as >>>> the unnamed module -- such named modules MUST get >>>> A.* from >>>> the named >>>> module rather than the unnamed module, and the >>>> class loading >>>> mechanism is incapable of switching based on >>>> accessor. It'll be >>>> common for named modules to exist in the same >>>> class loader >>>> as the >>>> unnamed module, as modular JARs on the >>>> modulepath and >>>> non-modular >>>> JARs on the classpath all end up in the >>>> application class >>>> loader >>>> (modular JARs as named modules; non-modular JARs >>>> jointly as the >>>> unnamed module). >>>> >>>> 2. While the module system is sure that package A >>>> exists in the >>>> named module, how would the module system possibly >>>> know >>>> that package >>>> A exists in the unnamed module? Scanning every >>>> class file >>>> in every >>>> non-modular JAR on the classpath at startup sounds >>>> bad. >>>> >>>> Alex > From pbenedict at apache.org Fri Mar 11 03:15:51 2016 From: pbenedict at apache.org (Paul Benedict) Date: Thu, 10 Mar 2016 21:15:51 -0600 Subject: Unnamed module and duplicate package In-Reply-To: References: <56E22A15.2080402@oracle.com> Message-ID: Stephen, regarding your first paragraph, I would like some more detail. Are you running your application server with jigsaw? Cheers, Paul On Thu, Mar 10, 2016 at 8:33 PM, Stephen Felts wrote: > I'm aware of classes in our application server (not javax) that are unused > when running with our own JVM and used when running with another JVM. > In that case, the packages are duplicate of classes in the JDK. I would > not want that usage to generate a fatal error. > This is unrelated to endorsed jar files. > > In addition to an upgradeable module for java.transaction.jar with Jigsaw, > I'm also running with an upgradeable module for > javax.annotation-api-1.2.jar. > > > -----Original Message----- > From: Alex Buckley > Sent: Thursday, March 10, 2016 9:15 PM > To: jigsaw-dev at openjdk.java.net > Subject: Re: Unnamed module and duplicate package > > The subtlety is that the Endorsed Standards Override Mechanism interpreted > "alternative implementations of the javax.* hierarchy" as "wholesale > replacements of entire javax.* packages placed in the location specified by > java.endorsed.dirs". It was never permissible to simply throw a handful of > javax.* types on the classpath and have them augment JDK packages. As > unsupported as sun.misc.Unsafe, as the saying might go. > > Let's talk about the Java Transaction API, javax.transaction.xa plus some > of javax.transaction. Unfortunately, JTA was never listed at > http://docs.oracle.com/javase/8/docs/technotes/guides/standards/index.html > as a Standalone Technology capable of being replaced wholesale by the > Endorsed Standards Override Mechanism. We believe this was an oversight; to > be fair, it does rather excuse throwing javax.transaction.xa types on to > the classpath. Anyway, in Java SE 9, the concept of Standalone Technology > has turned into the concept of upgradeable module (where you specify a > wholesale replacement of a Java SE module to -upgrademodulepath), and the > ill-documented Standalone Technology of JTA has turned into the upgradeable > module java.transaction. > > tl;dr Since you were and are meant to replace javax.* packages in a > wholesale fashion using a first-class mechanism, Paul's suggestion is > morally backwards-compatible. Practically, it might be a different story. > > Alex > > On 3/10/2016 3:58 PM, Neil Bartlett wrote: > > Paul, > > > > This sounds like you are suggesting a backwards-incompatible change to > > the behaviour of the application classpath. > > > > For example, many apps include on their classpath a library containing > > javax.transaction.xa, since the version of this package provided by > > the JDK is broken (omits several types). > > > > In general it has always been permissible for applications to provide > > their own alternative implementations of the javax.* hierarchy, with > > only the java.* hierarchy being off-limits due to the > > SecurityException that would be thrown by ClassLoader.defineClass. > > > > Neil > > > > > >> On 10 Mar 2016, at 21:25, Paul Benedict >> > wrote: > >> > >> Alex, > >> > >> For the sake of usability, however, it would be nice if the JDK > >> verified that jars do not contain any exported JDK packages. This > >> would be an RFE. I understand that in order to avoid split packages > >> between modules and classpath, the module version takes precedent. > >> For developer vs. developer code, I find that reasoning fine. > >> However, I really would like to treat the JDK as "special" (your > >> words) because in my experience, I see developers constantly > >> perplexed by NoClassDefFoundError when something occurred like you > >> just detailed. > >> > >> I'd like to refer you to the Servlet 3.1 spec [1], section 10.7.2, as > >> an analogous concern to mine. This is the so-called "prohibited classes" > >> violation clause: > >> > >> "As described in the Java EE license agreement, servlet containers > >> that are not part of a Java EE product should not allow the > >> application to override Java SE platform classes, such as those in > >> the java.* and javax.* namespaces, that Java SE does not allow to be > >> modified. The container should not allow applications to override or > >> access the container?s implementation classes." > >> > >> I don't think it's good usability to let JDK packages in the > >> classpath go silently unchallenged and unloaded. I recommend they are > >> reported as an error. > >> > >> > >> [1]https://java.net/downloads/servlet-spec/Final/servlet-3_1-final.pd > >> f > >> > >> Cheers, > >> Paul > >> > >> On Thu, Mar 10, 2016 at 2:30 PM, Alex Buckley > >> > > >> wrote: > >> > >>> I see xml-apis.jar (2.0.2) contains: > >>> > >>> - a javax.xml.parser package, which includes a FactoryFinder class > >>> that's not in Java SE, and > >>> > >>> - a javax.xml.transform package hierarchy, whose types at first > >>> glance look identical to those in Java SE except for yet another > >>> FactoryFinder class in javax.xml.transform. > >>> > >>> If you put xml-apis.jar on the classpath, its javax.xml.** packages > >>> will be ignored. The unnamed module reads the java.xml module which > >>> exports > >>> javax.xml.** packages (assuming java.xml in the system image, of > >>> course), so the application class loader delegates for javax.xml.** > >>> packages to the loader responsible for the java.xml module. User > >>> code that tries to access FactoryFinder will get a > >>> NoClassDefFoundError. > >>> > >>> There's nothing special about JDK modules here. The same > >>> NoClassDefFoundError would occur if the system image contained a > >>> module exporting some package, and a JAR on the classpath contained > >>> the same package with extra classes, and some code on the classpath > >>> tried to access those extra classes. Since the module in the system > >>> image is probably the rightful owner/exporter of the package, hard > >>> questions should be asked about the provenance of the JAR on the > >>> classpath. > >>> > >>> There has been some discussion of a jdeps-like tool that detects > >>> when a JAR on your classpath is trying to split a JDK package: > >>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-November/0052 > >>> 27.html > >>> . > >>> > >>> Alex > >>> > >>> On 3/10/2016 10:27 AM, Paul Benedict wrote: > >>> > >>>> Alex, there are JARs that contain javax packages. Anyone in the web > >>>> development community knows how many people have included xml-apis > >>>> in their WEB-INF :-) only to find out it wasn't loaded or it took > >>>> precedent over the JDK versions. > >>>> > >>>> Has Jigsaw introduced any restrictions here on this front? > >>>> Honestly, I think the JDK should make it illegal for the classpath > >>>> to contain ANY packages that the jdk has. Please opine when it is > convenient for you. > >>>> > >>>> Cheers, > >>>> Paul > >>>> > >>>> On Wed, Mar 9, 2016 at 5:13 PM, Alex Buckley > >>>> > >>>> > wrote: > >>>> > >>>> Paul, thank you for asking. The module system's treatment of the > >>>> unnamed module vis-a-vis named modules is probably the biggest > >>>> factor affecting usability of the module system. This is true > almost > >>>> by definition because at JDK 9 GA the only named modules in the > >>>> world will be the JDK's while every other class will be in the > >>>> unnamed module of the application class loader. > >>>> > >>>> So please, ask more questions about the unnamed module. I am > >>>> especially interested to know if anyone has JARs that contain javax > >>>> packages (or heaven forbid, sun or com.sun packages) found in the > >>>> JDK -- such JARs are a mortal danger to interop between unnamed and > >>>> named modules. > >>>> > >>>> Alex > >>>> > >>>> On 3/9/2016 1:47 PM, Paul Benedict wrote: > >>>> > >>>> Thank you Alex. Since it's roughly the same as JDK 8, then it's > >>>> also not > >>>> worse. I defer to your explanation on that point. > >>>> > >>>> Cheers, > >>>> Paul > >>>> > >>>> On Wed, Mar 9, 2016 at 3:37 PM, Alex Buckley > >>>> >>>> > >>>> >>>> >> wrote: > >>>> > >>>> Presumably you would count the equivalent scenario on JDK > 8 > >>>> -- my > >>>> package A is in Alex.jar on the classpath and your package > >>>> A is in > >>>> Paul.jar on the classpath -- as a security issue too, > >>>> because some > >>>> of my classes may substitute for yours (or some of yours > >>>> for mine, > >>>> depending on how the classpath is constructed). > >>>> > >>>> On JDK 9, we do the "substitution" cleanly. Package A is > >>>> not split. > >>>> That avoids one category of error (ClassCastException). > >>>> What about > >>>> poor package B that finds itself accessing a different > >>>> package A > >>>> than it was compiled with? Well, since package A is > >>>> exported by a > >>>> named module, it's reasonable to assume that the named > >>>> module "owns" > >>>> package A [*], and that the developer of package B > >>>> co-bundled some > >>>> version of package A without renaming it. Dangerous in > >>>> JDK 8, > >>>> dangerous in JDK 9. (We're trying to encapsulate the > >>>> internals of a > >>>> module, which is different from trying to isolate modules > >>>> from each > >>>> other.) > >>>> > >>>> [*] Advanced scenario: the named module exporting A is > >>>> actually an > >>>> automatic module which happened to co-bundle package A. By > >>>> placing > >>>> this JAR on the modulepath to form an automatic module, it > >>>> dominates > >>>> the JAR left on the classpath which also co-bundled > >>>> package A. > >>>> > >>>> Alex > >>>> > >>>> On 3/9/2016 1:17 PM, Paul Benedict wrote: > >>>> > >>>> But isn't what your proposing a security issue? Let's > >>>> say my > >>>> package A > >>>> is in the unnamed module and your package A is in a > >>>> named > >>>> module. You > >>>> basically took over my code; your classes will be > >>>> substituted > >>>> for mine. > >>>> > >>>> Cheers, > >>>> Paul > >>>> > >>>> On Wed, Mar 9, 2016 at 2:38 PM, Alex Buckley > >>>> >>>> > >>>> alex.buckley at oracle.com > >>>> > > >>>> >>>> > >>>> > >>>> >>>> >>> wrote: > >>>> > >>>> On 3/9/2016 10:36 AM, Paul Benedict wrote: > >>>> > >>>> From the doc: > >>>> "If a package is defined in both a named > >>>> module and the > >>>> unnamed > >>>> module then > >>>> the package in the unnamed module is ignored. > >>>> This > >>>> preserves > >>>> reliable > >>>> configuration even in the face of the > >>>> chaos of the > >>>> class path, > >>>> ensuring > >>>> that every module still reads at most one > >>>> module defining a > >>>> given package. > >>>> If, in our example above, a JAR file on the > >>>> class path > >>>> contains > >>>> a class > >>>> file named > >>>> com/foo/bar/alpha/AlphaFactory.class then > >>>> that file > >>>> will never > >>>> be loaded, since the com.foo.bar.alpha > >>>> package is > >>>> exported by the > >>>> com.foo.bar module." > >>>> > >>>> I would like some clarification. Correct me > if > >>>> wrong, but I > >>>> think this > >>>> entire paragraph is really meant to be > >>>> about the > >>>> perspective from a > >>>> modularized JAR? If a module has package A, > >>>> and the unnamed > >>>> module has > >>>> package A, then of course the module's > package > >>>> A should > >>>> win. > >>>> > >>>> However, if it is meant to be absolute > >>>> language, then I > >>>> disagree. > >>>> > >>>> The unnamed module should be coherent among > >>>> itself. If the > >>>> unnamed module > >>>> has package B and relies on classes from > >>>> package A, it > >>>> should > >>>> still be able > >>>> to see its own package A. I don't think > >>>> modules should > >>>> be able > >>>> to impact > >>>> how the unnamed module sees itself. That's a > >>>> surprising > >>>> situation. > >>>> > >>>> > >>>> The unnamed module is not a root module during > >>>> resolution. > >>>> If your > >>>> main class is in the unnamed module (i.e. you did > >>>> java -jar > >>>> MyApp.jar rather than java -m MyApp), then the > >>>> module graph is > >>>> created by resolving various root modules (what > >>>> are they? > >>>> separate > >>>> discussion) and only then is the unnamed module > >>>> hooked up > >>>> to read > >>>> every module in the graph. > >>>> > >>>> Hope we're OK so far. > >>>> > >>>> If some named module in the graph exports package > >>>> A (more > >>>> than one > >>>> module exporting A? separate discussion), then > >>>> since the > >>>> unnamed > >>>> module reads that named module, the unnamed > module > >>>> will > >>>> access A.* > >>>> types from that named module. > >>>> > >>>> It's hard to imagine the unnamed module NOT > >>>> accessing A.* > >>>> types from > >>>> that named module. Primarily, we need to avoid a > >>>> split package > >>>> situation where code in the unnamed module > >>>> sometimes > >>>> accesses A.* > >>>> types from the named module and sometimes from > the > >>>> unnamed > >>>> module. > >>>> > >>>> You might say, OK, let code in the unnamed module > >>>> exclusively access > >>>> A.* in the unnamed module rather than exclusively > >>>> access > >>>> A.* in the > >>>> named module. Then you have two problems: > >>>> > >>>> 1. There are issues for named modules in the same > >>>> class > >>>> loader as > >>>> the unnamed module -- such named modules MUST get > >>>> A.* from > >>>> the named > >>>> module rather than the unnamed module, and the > >>>> class loading > >>>> mechanism is incapable of switching based on > >>>> accessor. It'll be > >>>> common for named modules to exist in the same > >>>> class loader > >>>> as the > >>>> unnamed module, as modular JARs on the > >>>> modulepath and > >>>> non-modular > >>>> JARs on the classpath all end up in the > >>>> application class > >>>> loader > >>>> (modular JARs as named modules; non-modular JARs > >>>> jointly as the > >>>> unnamed module). > >>>> > >>>> 2. While the module system is sure that package A > >>>> exists in the > >>>> named module, how would the module system > possibly > >>>> know > >>>> that package > >>>> A exists in the unnamed module? Scanning every > >>>> class file > >>>> in every > >>>> non-modular JAR on the classpath at startup > sounds > >>>> bad. > >>>> > >>>> Alex > > > From stephen.felts at oracle.com Fri Mar 11 04:02:42 2016 From: stephen.felts at oracle.com (Stephen Felts) Date: Thu, 10 Mar 2016 20:02:42 -0800 (PST) Subject: Unnamed module and duplicate package In-Reply-To: References: <56E22A15.2080402@oracle.com> Message-ID: <425799e7-d16d-4ce3-8315-05b50114cc57@default> Yes, it is compiling and running on Jigsaw.? It?s not pretty but generally getting better. I?m concerned about a number of behaviors that aren?t pinned down yet and I?m worried that a discussion like this one will introduce a non-upward-compatible behavior that will break things worse. ? We have some classes that don?t run on Hotspot because they are already available but run on non-Hotspot JVMs. ? The Java EE folks are aware of the problems with both the ?transaction and annotation jars.? One of the outstanding issues I have is to get official copies of these module jar files.? Also, the current approach requires two associated jar files on the module path, javax.enterprise.cdi.api.jar and javax.interceptor.javax.interceptor.api.jar, because of dependencies.? I think the plan is to handle the dependencies so those jar files are not needed. ? ? ? ? From: Paul Benedict [mailto:pbenedict at apache.org] Sent: Thursday, March 10, 2016 10:16 PM To: Stephen Felts Cc: Alex Buckley; ML OpenJDK Jigsaw Developers Subject: Re: Unnamed module and duplicate package ? Stephen, regarding your first paragraph, I would like some more detail. Are you running your application server with jigsaw?? ? Cheers, Paul ? On Thu, Mar 10, 2016 at 8:33 PM, Stephen Felts wrote: I'm aware of classes in our application server (not javax) that are unused when running with our own JVM and used when running with another JVM. In that case, the packages are duplicate of classes in the JDK.? I would not want that usage to generate a fatal error. This is unrelated to endorsed jar files. In addition to an upgradeable module for java.transaction.jar with Jigsaw, I'm also running with an upgradeable module for javax.annotation-api-1.2.jar. -----Original Message----- From: Alex Buckley Sent: Thursday, March 10, 2016 9:15 PM To: HYPERLINK "mailto:jigsaw-dev at openjdk.java.net"jigsaw-dev at openjdk.java.net Subject: Re: Unnamed module and duplicate package The subtlety is that the Endorsed Standards Override Mechanism interpreted "alternative implementations of the javax.* hierarchy" as "wholesale replacements of entire javax.* packages placed in the location specified by java.endorsed.dirs". It was never permissible to simply throw a handful of javax.* types on the classpath and have them augment JDK packages. As unsupported as sun.misc.Unsafe, as the saying might go. Let's talk about the Java Transaction API, javax.transaction.xa plus some of javax.transaction. Unfortunately, JTA was never listed at http://docs.oracle.com/javase/8/docs/technotes/guides/standards/index.html as a Standalone Technology capable of being replaced wholesale by the Endorsed Standards Override Mechanism. We believe this was an oversight; to be fair, it does rather excuse throwing javax.transaction.xa types on to the classpath. Anyway, in Java SE 9, the concept of Standalone Technology has turned into the concept of upgradeable module (where you specify a wholesale replacement of a Java SE module to -upgrademodulepath), and the ill-documented Standalone Technology of JTA has turned into the upgradeable module java.transaction. tl;dr Since you were and are meant to replace javax.* packages in a wholesale fashion using a first-class mechanism, Paul's suggestion is morally backwards-compatible. Practically, it might be a different story. Alex On 3/10/2016 3:58 PM, Neil Bartlett wrote: > Paul, > > This sounds like you are suggesting a backwards-incompatible change to > the behaviour of the application classpath. > > For example, many apps include on their classpath a library containing > javax.transaction.xa, since the version of this package provided by > the JDK is broken (omits several types). > > In general it has always been permissible for applications to provide > their own alternative implementations of the javax.* hierarchy, with > only the java.* hierarchy being off-limits due to the > SecurityException that would be thrown by ClassLoader.defineClass. > > Neil > > >> On 10 Mar 2016, at 21:25, Paul Benedict > > wrote: >> >> Alex, >> >> For the sake of usability, however, it would be nice if the JDK >> verified that jars do not contain any exported JDK packages. This >> would be an RFE. I understand that in order to avoid split packages >> between modules and classpath, the module version takes precedent. >> For developer vs. developer code, I find that reasoning fine. >> However, I really would like to treat the JDK as "special" (your >> words) because in my experience, I see developers constantly >> perplexed by NoClassDefFoundError when something occurred like you >> just detailed. >> >> I'd like to refer you to the Servlet 3.1 spec [1], section 10.7.2, as >> an analogous concern to mine. This is the so-called "prohibited classes" >> violation clause: >> >> "As described in the Java EE license agreement, servlet containers >> that are not part of a Java EE product should not allow the >> application to override Java SE platform classes, such as those in >> the java.* and javax.* namespaces, that Java SE does not allow to be >> modified. The container should not allow applications to override or >> access the container?s implementation classes." >> >> I don't think it's good usability to let JDK packages in the >> classpath go silently unchallenged and unloaded. I recommend they are >> reported as an error. >> >> >> [1]https://java.net/downloads/servlet-spec/Final/servlet-3_1-final.pd >> f >> >> Cheers, >> Paul >> >> On Thu, Mar 10, 2016 at 2:30 PM, Alex Buckley >> > >> wrote: >> >>> I see xml-apis.jar (2.0.2) contains: >>> >>> - a javax.xml.parser package, which includes a FactoryFinder class >>> that's not in Java SE, and >>> >>> - a javax.xml.transform package hierarchy, whose types at first >>> glance look identical to those in Java SE except for yet another >>> FactoryFinder class in javax.xml.transform. >>> >>> If you put xml-apis.jar on the classpath, its javax.xml.** packages >>> will be ignored. The unnamed module reads the java.xml module which >>> exports >>> javax.xml.** packages (assuming java.xml in the system image, of >>> course), so the application class loader delegates for javax.xml.** >>> packages to the loader responsible for the java.xml module. User >>> code that tries to access FactoryFinder will get a >>> NoClassDefFoundError. >>> >>> There's nothing special about JDK modules here. The same >>> NoClassDefFoundError would occur if the system image contained a >>> module exporting some package, and a JAR on the classpath contained >>> the same package with extra classes, and some code on the classpath >>> tried to access those extra classes. Since the module in the system >>> image is probably the rightful owner/exporter of the package, hard >>> questions should be asked about the provenance of the JAR on the >>> classpath. >>> >>> There has been some discussion of a jdeps-like tool that detects >>> when a JAR on your classpath is trying to split a JDK package: >>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-November/0052 >>> 27.html >>> . >>> >>> Alex >>> >>> On 3/10/2016 10:27 AM, Paul Benedict wrote: >>> >>>> Alex, there are JARs that contain javax packages. Anyone in the web >>>> development community knows how many people have included xml-apis >>>> in their WEB-INF :-) only to find out it wasn't loaded or it took >>>> precedent over the JDK versions. >>>> >>>> Has Jigsaw introduced any restrictions here on this front? >>>> Honestly, I think the JDK should make it illegal for the classpath >>>> to contain ANY packages that the jdk has. Please opine when it is convenient for you. >>>> >>>> Cheers, >>>> Paul >>>> >>>> On Wed, Mar 9, 2016 at 5:13 PM, Alex Buckley >>>> >>>> > wrote: >>>> >>>>? ? Paul, thank you for asking. The module system's treatment of the >>>>? ? unnamed module vis-a-vis named modules is probably the biggest >>>>? ? factor affecting usability of the module system. This is true almost >>>>? ? by definition because at JDK 9 GA the only named modules in the >>>>? ? world will be the JDK's while every other class will be in the >>>>? ? unnamed module of the application class loader. >>>> >>>>? ? So please, ask more questions about the unnamed module. I am >>>>? ? especially interested to know if anyone has JARs that contain javax >>>>? ? packages (or heaven forbid, sun or com.sun packages) found in the >>>>? ? JDK -- such JARs are a mortal danger to interop between unnamed and >>>>? ? named modules. >>>> >>>>? ? Alex >>>> >>>>? ? On 3/9/2016 1:47 PM, Paul Benedict wrote: >>>> >>>>? ? ? ? Thank you Alex. Since it's roughly the same as JDK 8, then it's >>>>? ? ? ? also not >>>>? ? ? ? worse. I defer to your explanation on that point. >>>> >>>>? ? ? ? Cheers, >>>>? ? ? ? Paul >>>> >>>>? ? ? ? On Wed, Mar 9, 2016 at 3:37 PM, Alex Buckley >>>>? ? ? ? >>> >>>>? ? ? ? >>>? ? ? ? >> wrote: >>>> >>>>? ? ? ? ? ? ?Presumably you would count the equivalent scenario on JDK 8 >>>>? ? ? ? -- my >>>>? ? ? ? ? ? ?package A is in Alex.jar on the classpath and your package >>>>? ? ? ? A is in >>>>? ? ? ? ? ? ?Paul.jar on the classpath -- as a security issue too, >>>>? ? ? ? because some >>>>? ? ? ? ? ? ?of my classes may substitute for yours (or some of yours >>>>? ? ? ? for mine, >>>>? ? ? ? ? ? ?depending on how the classpath is constructed). >>>> >>>>? ? ? ? ? ? ?On JDK 9, we do the "substitution" cleanly. Package A is >>>>? ? ? ? not split. >>>>? ? ? ? ? ? ?That avoids one category of error (ClassCastException). >>>>? ? ? ? What about >>>>? ? ? ? ? ? ?poor package B that finds itself accessing a different >>>>? ? ? ? package A >>>>? ? ? ? ? ? ?than it was compiled with? Well, since package A is >>>>? ? ? ? exported by a >>>>? ? ? ? ? ? ?named module, it's reasonable to assume that the named >>>>? ? ? ? module "owns" >>>>? ? ? ? ? ? ?package A [*], and that the developer of package B >>>>? ? ? ? co-bundled some >>>>? ? ? ? ? ? ?version of package A without renaming it. Dangerous in >>>> JDK 8, >>>>? ? ? ? ? ? ?dangerous in JDK 9. (We're trying to encapsulate the >>>>? ? ? ? internals of a >>>>? ? ? ? ? ? ?module, which is different from trying to isolate modules >>>>? ? ? ? from each >>>>? ? ? ? ? ? ?other.) >>>> >>>>? ? ? ? ? ? ?[*] Advanced scenario: the named module exporting A is >>>>? ? ? ? actually an >>>>? ? ? ? ? ? ?automatic module which happened to co-bundle package A. By >>>>? ? ? ? placing >>>>? ? ? ? ? ? ?this JAR on the modulepath to form an automatic module, it >>>>? ? ? ? dominates >>>>? ? ? ? ? ? ?the JAR left on the classpath which also co-bundled >>>> package A. >>>> >>>>? ? ? ? ? ? ?Alex >>>> >>>>? ? ? ? ? ? ?On 3/9/2016 1:17 PM, Paul Benedict wrote: >>>> >>>>? ? ? ? ? ? ? ? ?But isn't what your proposing a security issue? Let's >>>>? ? ? ? say my >>>>? ? ? ? ? ? ? ? ?package A >>>>? ? ? ? ? ? ? ? ?is in the unnamed module and your package A is in a >>>> named >>>>? ? ? ? ? ? ? ? ?module. You >>>>? ? ? ? ? ? ? ? ?basically took over my code; your classes will be >>>>? ? ? ? substituted >>>>? ? ? ? ? ? ? ? ?for mine. >>>> >>>>? ? ? ? ? ? ? ? ?Cheers, >>>>? ? ? ? ? ? ? ? ?Paul >>>> >>>>? ? ? ? ? ? ? ? ?On Wed, Mar 9, 2016 at 2:38 PM, Alex Buckley >>>>? ? ? ? ? ? ? ? ?>>> >>>>? ? ? ? >>>? ? ? ? > >>>>? ? ? ? ? ? ? ? ?>>>? ? ? ? >>>> >>>>? ? ? ? ? ? ? ? ?>>>? ? ? ? >>> wrote: >>>> >>>>? ? ? ? ? ? ? ? ? ? ? On 3/9/2016 10:36 AM, Paul Benedict wrote: >>>> >>>>? ? ? ? ? ? ? ? ? ? ? ? ? ? From the doc: >>>>? ? ? ? ? ? ? ? ? ? ? ? ? "If a package is defined in both a named >>>>? ? ? ? module and the >>>>? ? ? ? ? ? ? ? ?unnamed >>>>? ? ? ? ? ? ? ? ? ? ? ? ? module then >>>>? ? ? ? ? ? ? ? ? ? ? ? ? the package in the unnamed module is ignored. >>>> This >>>>? ? ? ? ? ? ? ? ?preserves >>>>? ? ? ? ? ? ? ? ? ? ? ? ? reliable >>>>? ? ? ? ? ? ? ? ? ? ? ? ? configuration even in the face of the >>>> chaos of the >>>>? ? ? ? ? ? ? ? ?class path, >>>>? ? ? ? ? ? ? ? ? ? ? ? ? ensuring >>>>? ? ? ? ? ? ? ? ? ? ? ? ? that every module still reads at most one >>>>? ? ? ? module defining a >>>>? ? ? ? ? ? ? ? ? ? ? ? ? given package. >>>>? ? ? ? ? ? ? ? ? ? ? ? ? If, in our example above, a JAR file on the >>>>? ? ? ? class path >>>>? ? ? ? ? ? ? ? ?contains >>>>? ? ? ? ? ? ? ? ? ? ? ? ? a class >>>>? ? ? ? ? ? ? ? ? ? ? ? ? file named >>>>? ? ? ? com/foo/bar/alpha/AlphaFactory.class then >>>>? ? ? ? ? ? ? ? ?that file >>>>? ? ? ? ? ? ? ? ? ? ? ? ? will never >>>>? ? ? ? ? ? ? ? ? ? ? ? ? be loaded, since the com.foo.bar.alpha >>>> package is >>>>? ? ? ? ? ? ? ? ?exported by the >>>>? ? ? ? ? ? ? ? ? ? ? ? ? com.foo.bar module." >>>> >>>>? ? ? ? ? ? ? ? ? ? ? ? ? I would like some clarification. Correct me if >>>>? ? ? ? wrong, but I >>>>? ? ? ? ? ? ? ? ? ? ? ? ? think this >>>>? ? ? ? ? ? ? ? ? ? ? ? ? entire paragraph is really meant to be >>>> about the >>>>? ? ? ? ? ? ? ? ?perspective from a >>>>? ? ? ? ? ? ? ? ? ? ? ? ? modularized JAR? If a module has package A, >>>>? ? ? ? and the unnamed >>>>? ? ? ? ? ? ? ? ? ? ? ? ? module has >>>>? ? ? ? ? ? ? ? ? ? ? ? ? package A, then of course the module's package >>>>? ? ? ? A should >>>>? ? ? ? ? ? ? ? ?win. >>>> >>>>? ? ? ? ? ? ? ? ? ? ? ? ? However, if it is meant to be absolute >>>>? ? ? ? language, then I >>>>? ? ? ? ? ? ? ? ?disagree. >>>> >>>>? ? ? ? ? ? ? ? ? ? ? ? ? The unnamed module should be coherent among >>>>? ? ? ? itself. If the >>>>? ? ? ? ? ? ? ? ? ? ? ? ? unnamed module >>>>? ? ? ? ? ? ? ? ? ? ? ? ? has package B and relies on classes from >>>>? ? ? ? package A, it >>>>? ? ? ? ? ? ? ? ?should >>>>? ? ? ? ? ? ? ? ? ? ? ? ? still be able >>>>? ? ? ? ? ? ? ? ? ? ? ? ? to see its own package A. I don't think >>>>? ? ? ? modules should >>>>? ? ? ? ? ? ? ? ?be able >>>>? ? ? ? ? ? ? ? ? ? ? ? ? to impact >>>>? ? ? ? ? ? ? ? ? ? ? ? ? how the unnamed module sees itself. That's a >>>>? ? ? ? surprising >>>>? ? ? ? ? ? ? ? ?situation. >>>> >>>> >>>>? ? ? ? ? ? ? ? ? ? ? The unnamed module is not a root module during >>>>? ? ? ? resolution. >>>>? ? ? ? ? ? ? ? ?If your >>>>? ? ? ? ? ? ? ? ? ? ? main class is in the unnamed module (i.e. you did >>>>? ? ? ? java -jar >>>>? ? ? ? ? ? ? ? ? ? ? MyApp.jar rather than java -m MyApp), then the >>>>? ? ? ? module graph is >>>>? ? ? ? ? ? ? ? ? ? ? created by resolving various root modules (what >>>>? ? ? ? are they? >>>>? ? ? ? ? ? ? ? ?separate >>>>? ? ? ? ? ? ? ? ? ? ? discussion) and only then is the unnamed module >>>>? ? ? ? hooked up >>>>? ? ? ? ? ? ? ? ?to read >>>>? ? ? ? ? ? ? ? ? ? ? every module in the graph. >>>> >>>>? ? ? ? ? ? ? ? ? ? ? Hope we're OK so far. >>>> >>>>? ? ? ? ? ? ? ? ? ? ? If some named module in the graph exports package >>>>? ? ? ? A (more >>>>? ? ? ? ? ? ? ? ?than one >>>>? ? ? ? ? ? ? ? ? ? ? module exporting A? separate discussion), then >>>>? ? ? ? since the >>>>? ? ? ? ? ? ? ? ?unnamed >>>>? ? ? ? ? ? ? ? ? ? ? module reads that named module, the unnamed module >>>>? ? ? ? will >>>>? ? ? ? ? ? ? ? ?access A.* >>>>? ? ? ? ? ? ? ? ? ? ? types from that named module. >>>> >>>>? ? ? ? ? ? ? ? ? ? ? It's hard to imagine the unnamed module NOT >>>>? ? ? ? accessing A.* >>>>? ? ? ? ? ? ? ? ?types from >>>>? ? ? ? ? ? ? ? ? ? ? that named module. Primarily, we need to avoid a >>>>? ? ? ? split package >>>>? ? ? ? ? ? ? ? ? ? ? situation where code in the unnamed module >>>> sometimes >>>>? ? ? ? ? ? ? ? ?accesses A.* >>>>? ? ? ? ? ? ? ? ? ? ? types from the named module and sometimes from the >>>>? ? ? ? unnamed >>>>? ? ? ? ? ? ? ? ?module. >>>> >>>>? ? ? ? ? ? ? ? ? ? ? You might say, OK, let code in the unnamed module >>>>? ? ? ? ? ? ? ? ?exclusively access >>>>? ? ? ? ? ? ? ? ? ? ? A.* in the unnamed module rather than exclusively >>>>? ? ? ? access >>>>? ? ? ? ? ? ? ? ?A.* in the >>>>? ? ? ? ? ? ? ? ? ? ? named module. Then you have two problems: >>>> >>>>? ? ? ? ? ? ? ? ? ? ? 1. There are issues for named modules in the same >>>>? ? ? ? class >>>>? ? ? ? ? ? ? ? ?loader as >>>>? ? ? ? ? ? ? ? ? ? ? the unnamed module -- such named modules MUST get >>>>? ? ? ? A.* from >>>>? ? ? ? ? ? ? ? ?the named >>>>? ? ? ? ? ? ? ? ? ? ? module rather than the unnamed module, and the >>>>? ? ? ? class loading >>>>? ? ? ? ? ? ? ? ? ? ? mechanism is incapable of switching based on >>>>? ? ? ? accessor. It'll be >>>>? ? ? ? ? ? ? ? ? ? ? common for named modules to exist in the same >>>>? ? ? ? class loader >>>>? ? ? ? ? ? ? ? ?as the >>>>? ? ? ? ? ? ? ? ? ? ? unnamed module, as modular JARs on the >>>> modulepath and >>>>? ? ? ? ? ? ? ? ?non-modular >>>>? ? ? ? ? ? ? ? ? ? ? JARs on the classpath all end up in the >>>>? ? ? ? application class >>>>? ? ? ? ? ? ? ? ?loader >>>>? ? ? ? ? ? ? ? ? ? ? (modular JARs as named modules; non-modular JARs >>>>? ? ? ? jointly as the >>>>? ? ? ? ? ? ? ? ? ? ? unnamed module). >>>> >>>>? ? ? ? ? ? ? ? ? ? ? 2. While the module system is sure that package A >>>>? ? ? ? exists in the >>>>? ? ? ? ? ? ? ? ? ? ? named module, how would the module system possibly >>>>? ? ? ? know >>>>? ? ? ? ? ? ? ? ?that package >>>>? ? ? ? ? ? ? ? ? ? ? A exists in the unnamed module? Scanning every >>>>? ? ? ? class file >>>>? ? ? ? ? ? ? ? ?in every >>>>? ? ? ? ? ? ? ? ? ? ? non-modular JAR on the classpath at startup sounds >>>>? ? ? ? bad. >>>> >>>>? ? ? ? ? ? ? ? ? ? ? Alex > ? From pbenedict at apache.org Fri Mar 11 04:42:49 2016 From: pbenedict at apache.org (Paul Benedict) Date: Thu, 10 Mar 2016 22:42:49 -0600 Subject: Unnamed module and duplicate package In-Reply-To: <425799e7-d16d-4ce3-8315-05b50114cc57@default> References: <56E22A15.2080402@oracle.com> <425799e7-d16d-4ce3-8315-05b50114cc57@default> Message-ID: On Thu, Mar 10, 2016 at 10:02 PM, Stephen Felts wrote: > Yes, it is compiling and running on Jigsaw. It?s not pretty but generally > getting better. I?m concerned about a number of behaviors that aren?t > pinned down yet and I?m worried that a discussion like this one will > introduce a non-upward-compatible behavior that will break things worse. > Well I appreciate your candid opinion because I believe that you and Niel are ultimately correct. I'll quote from section 3.1 of SOTMS: "An existing class-path application that compiles and runs on Java SE 8 will, thus, compile and run in exactly the same way on Java SE 9, so long as it only uses standard, non-deprecated Java SE APIs." To introduce extra validating behavior is backward incompatible. So yes, I believe this is not a good idea anymore. Thanks for your input. I did want to prevent classes shadowing each other, but it's clear the classpath is meant to be more lenient than the modulepath. Kudos. Regarding your previous email, please help me understand how your web application works at all with those duplicate JDK classes present. Wouldn't the modules that expose those JDK classes put you in a split package situation? Cheers, Paul > > > *From:* Paul Benedict [mailto:pbenedict at apache.org] > *Sent:* Thursday, March 10, 2016 10:16 PM > *To:* Stephen Felts > *Cc:* Alex Buckley; ML OpenJDK Jigsaw Developers > > *Subject:* Re: Unnamed module and duplicate package > > > > Stephen, regarding your first paragraph, I would like some more detail. > Are you running your application server with jigsaw? > > > > Cheers, > > Paul > > > > On Thu, Mar 10, 2016 at 8:33 PM, Stephen Felts > wrote: > > I'm aware of classes in our application server (not javax) that are unused > when running with our own JVM and used when running with another JVM. > In that case, the packages are duplicate of classes in the JDK. I would > not want that usage to generate a fatal error. > This is unrelated to endorsed jar files. > > In addition to an upgradeable module for java.transaction.jar with Jigsaw, > I'm also running with an upgradeable module for > javax.annotation-api-1.2.jar. > > From jan.lahoda at oracle.com Fri Mar 11 08:21:31 2016 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Fri, 11 Mar 2016 08:21:31 +0000 Subject: hg: jigsaw/jake/langtools: Renaming the property holding the target JDK from jdk.home to langtools.jdk.home; using javac -m. Message-ID: <201603110821.u2B8LVkM016360@aojmv0008.oracle.com> Changeset: 401b25c9ad7e Author: jlahoda Date: 2016-03-11 07:48 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/401b25c9ad7e Renaming the property holding the target JDK from jdk.home to langtools.jdk.home; using javac -m. ! make/build.xml ! make/intellij/ant.xml ! make/intellij/build.xml ! make/netbeans/langtools/build.xml From Alan.Bateman at oracle.com Fri Mar 11 08:50:51 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 11 Mar 2016 08:50:51 +0000 Subject: Unnamed module and duplicate package In-Reply-To: References: Message-ID: <56E286EB.5000904@oracle.com> On 10/03/2016 23:58, Neil Bartlett wrote: > Paul, > > This sounds like you are suggesting a backwards-incompatible change to the behaviour of the application classpath. > > For example, many apps include on their classpath a library containing javax.transaction.xa, since the version of this package provided by the JDK is broken (omits several types). > > In general it has always been permissible for applications to provide their own alternative implementations of the javax.* hierarchy, with only the java.* hierarchy being off-limits due to the SecurityException that would be thrown by ClassLoader.defineClass. > > "provided by the JDK is broken" is misleading. On the other hand, "omits several types" is accurate, assuming you mean javax.transaction rather than javax.transaction.xa. The transaction API is one of a small number of APIs shared between Java SE and EE. The complete set is non-aggregator modules that java.se.ee requires. In the case of the transaction API then Java SE defines the minimum subset of javax.transaction required to support the mapping of CORBA system exceptions to RMI exceptions. The Java Language to IDL Mapping spec has the details. Java SE defines all the types in javax.transacation.xa, important because JDBC supports XA. The EE/app servers need to override JTA with the version that EE defines (the version has all of the javax.transaction types). In JDK 8 and older then the supported way of doing this was via the endorsed standards override mechanism. It was never supported to deploy the upgraded version as a JAR file on the class path. The endorsed standards override mechanism doesn't make sense with modules and the replacement, as Alex notes, is to deploy the EE version of the java.transaction (no 'x') module on the upgrade module path. Another way that would work is to compile or run with`-limitmods java.se` so as to limit observability to just the Java SE modules that do not overlap/share with Java EE. It would be as if the JDK doesn't have the modules that are shared with EE. For those interested in the transaction API then the module summary page [1] has the details on the modules. The surprise might be that the java.sql module has taken ownership for the javax.transaction.xa package. -Alan [1] http://cr.openjdk.java.net/~mr/jigsaw/ea/module-summary.html From Alan.Bateman at oracle.com Fri Mar 11 09:03:23 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 11 Mar 2016 09:03:23 +0000 Subject: Unnamed module and duplicate package In-Reply-To: <425799e7-d16d-4ce3-8315-05b50114cc57@default> References: <56E22A15.2080402@oracle.com> <425799e7-d16d-4ce3-8315-05b50114cc57@default> Message-ID: <56E289DB.50508@oracle.com> On 11/03/2016 04:02, Stephen Felts wrote: > : > > > The Java EE folks are aware of the problems with both the transaction and annotation jars. One of the outstanding issues I have is to get official copies of these module jar files. Also, the current approach requires two associated jar files on the module path, > > javax.enterprise.cdi.api.jar and javax.interceptor.javax.interceptor.api.jar, because of dependencies. I think the plan is to handle the dependencies so those jar files are not needed. > > Just to add to Stephen's note. The EE version of the java.transaction module that Stephen with WebLogic has additional dependences. This creates a migration challenge as we are trying to deploy a library as a module when it depends on other libraries that have not yet migrated to modules. Here is where automatic modules comes in because these dependences can be put on the application module path and work as automatic modules. They in turn might have to link to types on the class path, something that automatic modules can do. It of course makes the deployment a bit more complicated but that's another discussion. -Alan. From Alan.Bateman at oracle.com Fri Mar 11 09:07:47 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 11 Mar 2016 09:07:47 +0000 Subject: Project Jigsaw, build 109 on 03-10-2016 (#4622) Message-ID: <56E28AE3.8070404@oracle.com> jigsaw/jake has been sync'ed up to jdk-9+109 and the EA build [1] has been refreshed. -Alan [1] https://jdk9.java.net/jigsaw/ From Alan.Bateman at oracle.com Fri Mar 11 09:39:51 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 11 Mar 2016 09:39:51 +0000 Subject: Initial webrev with changes for JDK 9 Message-ID: <56E29267.7070501@oracle.com> I've refreshed the webrevs here: http://cr.openjdk.java.net/~alanb/8142968/2 so that we have a snapshot of what is currently in the jigsaw/jake forest. The webrevs are against jdk-9+109. As I said in the last mail, we would like to integrate this snapshot into JDK 9 before the end of March. The proposal is to aim to integrate during the week of March 21, with the the week of March 28 as fallback in event of problems. The related JEPs (JEP 200, JEP 260, JEP 261 and JEP 282) are now in "Proposed to Target" state. Mark send mail to jdk9-dev with this list and other proposals yesterday. -Alan From njbartlett at gmail.com Fri Mar 11 10:04:04 2016 From: njbartlett at gmail.com (Neil Bartlett) Date: Fri, 11 Mar 2016 10:04:04 +0000 Subject: Unnamed module and duplicate package In-Reply-To: <56E286EB.5000904@oracle.com> References: <56E286EB.5000904@oracle.com> Message-ID: Hello Alan, > On 11 Mar 2016, at 08:50, Alan Bateman wrote: > > > > On 10/03/2016 23:58, Neil Bartlett wrote: >> Paul, >> >> This sounds like you are suggesting a backwards-incompatible change to the behaviour of the application classpath. >> >> For example, many apps include on their classpath a library containing javax.transaction.xa, since the version of this package provided by the JDK is broken (omits several types). >> >> In general it has always been permissible for applications to provide their own alternative implementations of the javax.* hierarchy, with only the java.* hierarchy being off-limits due to the SecurityException that would be thrown by ClassLoader.defineClass. >> >> > "provided by the JDK is broken" is misleading. On the other hand, "omits several types" is accurate, assuming you mean javax.transaction rather than javax.transaction.xa. Yes my mistake, I did mean javax.transaction. > > The transaction API is one of a small number of APIs shared between Java SE and EE. The complete set is non-aggregator modules that java.se.ee requires. In the case of the transaction API then Java SE defines the minimum subset of javax.transaction required to support the mapping of CORBA system exceptions to RMI exceptions. The Java Language to IDL Mapping spec has the details. Java SE defines all the types in javax.transacation.xa, important because JDBC supports XA. Whatever the motivation, I referred to this package as ?broken? because it has caused a great many problems for OSGi users. Applications that import the javax.transaction package may encounter NoClassDefFoundError due to the missing types if they wire to the platform export. The most commonly employed practical solution is to add back those types with the application ClassLoader. A properly constructed set of OSGi bundles *should* never throw NoClassDefFoundError or ClassNotFoundException, and I would hope this will also be the case in Jigsaw. > > The EE/app servers need to override JTA with the version that EE defines (the version has all of the javax.transaction types). In JDK 8 and older then the supported way of doing this was via the endorsed standards override mechanism. It was never supported to deploy the upgraded version as a JAR file on the class path. The endorsed standards override mechanism doesn't make sense with modules and the replacement, as Alex notes, is to deploy the EE version of the java.transaction (no 'x') module on the upgrade module path. > > Another way that would work is to compile or run with`-limitmods java.se` so as to limit observability to just the Java SE modules that do not overlap/share with Java EE. It would be as if the JDK doesn't have the modules that are shared with EE. Would this include the javax.sql.* packages? Since javax.sql exposes XAResource via its method signatures, it would be necessary for the classloader of javax.sql to have visibility of those types also. Regards, Neil > > For those interested in the transaction API then the module summary page [1] has the details on the modules. The surprise might be that the java.sql module has taken ownership for the javax.transaction.xa package. > > -Alan > > [1] http://cr.openjdk.java.net/~mr/jigsaw/ea/module-summary.html From Alan.Bateman at oracle.com Fri Mar 11 10:42:55 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 11 Mar 2016 10:42:55 +0000 Subject: Unnamed module and duplicate package In-Reply-To: References: <56E286EB.5000904@oracle.com> Message-ID: <56E2A12F.5020000@oracle.com> On 11/03/2016 10:04, Neil Bartlett wrote: > : > > Whatever the motivation, I referred to this package as ?broken? because it has caused a great many problems for OSGi users. Applications that import the javax.transaction package may encounter NoClassDefFoundError due to the missing types if they wire to the platform export. The most commonly employed practical solution is to add back those types with the application ClassLoader. Deploying the classes on the class path (application class loader) meant some types in javax.transaction defined to the boot loader (because of delegation) and some to the application class loader. A sad state of affairs that would not have worked if there had been any reliance on anything package private. Going forward then it requires deploying the EE version of the java.transaction module on the upgrade module path. > > A properly constructed set of OSGi bundles *should* never throw NoClassDefFoundError or ClassNotFoundException, and I would hope this will also be the case in Jigsaw. If it compiles then it should run so I would not expect NoClassDefFoundError. ClassNotFoundException hints of Class.forName and core reflection usage so the compiler cannot help. > : > Would this include the javax.sql.* packages? Since javax.sql exposes XAResource via its method signatures, it would be necessary for the classloader of javax.sql to have visibility of those types also. > Yes, except the types in the javax.sql.rowset package as that is a different module. The definition for both the java.sql and java.sql.rowset modules can be found here: http://cr.openjdk.java.net/~mr/jigsaw/ea/module-summary.html#java.sql or if you have the EA builds then `java -listmods:java.sql,java.sql.rowset` will describe these modules. In terms of visibility then both modules are currently defined to the boot loader and hence their types are visible via any of the built-in class loaders. We are on a mission to move non-core modules out of the boot loader so that they don't have all permissions by default. Easier said that done of course but we have already moved all the modules shared with EE so that they can be upgraded by app servers. I hope we can move java.sql.rowset module, I don't know about java.sql yet. There is a small spec change needed to do the latter because currently only the boot loader can defined java.* types (one of the comments in your mail suggests you are aware of this detail). -Alan From alan.bateman at oracle.com Fri Mar 11 11:26:06 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 11 Mar 2016 11:26:06 +0000 Subject: hg: jigsaw/jake/hotspot: Update JVM TI spec with a wording on instrumenting code in modules Message-ID: <201603111126.u2BBQ6tZ027879@aojmv0008.oracle.com> Changeset: 91d40a7b4190 Author: alanb Date: 2016-03-11 11:25 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/91d40a7b4190 Update JVM TI spec with a wording on instrumenting code in modules ! src/share/vm/prims/jvmti.xml From lois.foltan at oracle.com Fri Mar 11 12:16:41 2016 From: lois.foltan at oracle.com (lois.foltan at oracle.com) Date: Fri, 11 Mar 2016 12:16:41 +0000 Subject: hg: jigsaw/jake/hotspot: Remove use of "jlrM" in field and method names based on code review comments. Message-ID: <201603111216.u2BCGfYA017172@aojmv0008.oracle.com> Changeset: c9950704cbcc Author: lfoltan Date: 2016-03-11 06:49 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c9950704cbcc Remove use of "jlrM" in field and method names based on code review comments. ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/moduleEntry.cpp ! src/share/vm/classfile/moduleEntry.hpp ! src/share/vm/classfile/modules.cpp ! src/share/vm/classfile/packageEntry.hpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/prims/jvmtiEnvBase.hpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/runtime/mutexLocker.hpp ! src/share/vm/runtime/reflection.cpp From jan.lahoda at oracle.com Fri Mar 11 13:30:18 2016 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Fri, 11 Mar 2016 13:30:18 +0000 Subject: hg: jigsaw/jake/langtools: Cleanup, reflecting comments by anazarov. Message-ID: <201603111330.u2BDUIbs016808@aojmv0008.oracle.com> Changeset: 5db301565973 Author: jlahoda Date: 2016-03-11 14:29 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/5db301565973 Cleanup, reflecting comments by anazarov. ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/ModuleFinder.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/JNIWriter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/6330997/T6330997.java ! test/tools/javac/T6435291/T6435291.java ! test/tools/javac/api/6400303/T6400303.java ! test/tools/javac/api/TestResolveIdent.java ! test/tools/javac/defaultMethods/BadClassfile.java ! test/tools/javac/modules/EdgeCases.java From christian.tornqvist at oracle.com Fri Mar 11 14:07:50 2016 From: christian.tornqvist at oracle.com (christian.tornqvist at oracle.com) Date: Fri, 11 Mar 2016 14:07:50 +0000 Subject: hg: jigsaw/jake/hotspot: Updated test/runtime/SharedArchiveFile/BootAppendTests.java to work with UL, removed testng dependencies Message-ID: <201603111407.u2BE7oUk002573@aojmv0008.oracle.com> Changeset: 0a2edc67fcc2 Author: ctornqvi Date: 2016-03-11 05:41 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0a2edc67fcc2 Updated test/runtime/SharedArchiveFile/BootAppendTests.java to work with UL, removed testng dependencies ! test/runtime/SharedArchiveFile/BootAppendTests.java From stephen.felts at oracle.com Fri Mar 11 14:25:43 2016 From: stephen.felts at oracle.com (Stephen Felts) Date: Fri, 11 Mar 2016 06:25:43 -0800 (PST) Subject: Unnamed module and duplicate package In-Reply-To: References: <56E22A15.2080402@oracle.com> <425799e7-d16d-4ce3-8315-05b50114cc57@default> Message-ID: <45034f78-3bbb-49df-b25a-4b8f7691dfda@default> The bottom line is that only one module can own a package (generally), where the unnamed module is a possible owner.? If the classes are in the JDK, then it owns the package.? As long as all of the classes that I use from that package are in the JDK, it works.? If some but not all of the classes are ?in the JDK, then I have a problem. ??If none of the classes from the package are in the JDK for a non-Hotspot JDK, then it should work (we haven?t tested any other JDK9 but Hotspot). ? In one of the cases that I have, we are using ?Xpatch to get around this general rule and add some classes to the package.? We are trying to remove this case.? However, we might need to keep ?Xpatch around if we need to add back sun.misc.BASE64Encoder and sun.misc.BASE64Decoder.? We have a bunch of jar files that I don?t own that use them and some of the jars have requirements to run on pre-JDK8 and/or I know they won?t be re-released for a couple of years. ? ? ? From: Paul Benedict [mailto:pbenedict at apache.org] Sent: Thursday, March 10, 2016 11:43 PM To: Stephen Felts Cc: Alex Buckley; ML OpenJDK Jigsaw Developers Subject: Re: Unnamed module and duplicate package ? On Thu, Mar 10, 2016 at 10:02 PM, Stephen Felts wrote: Yes, it is compiling and running on Jigsaw.? It?s not pretty but generally getting better. I?m concerned about a number of behaviors that aren?t pinned down yet and I?m worried that a discussion like this one will introduce a non-upward-compatible behavior that will break things worse. ? Well I appreciate your candid opinion because I believe that you and Niel are ultimately correct. I'll quote from section 3.1 of SOTMS: "An existing class-path application that compiles and runs on Java?SE?8 will, thus, compile and run in exactly the same way on Java?SE?9, so long as it only uses standard, non-deprecated Java?SE APIs." To introduce extra validating behavior is backward incompatible. So yes, I believe this is not a good idea anymore. Thanks for your input. I did want to prevent classes shadowing each other, but it's clear the classpath is meant to be more lenient than the modulepath. Kudos. ? Regarding your previous email, please help me understand how your web application works at all with those duplicate JDK classes present. Wouldn't the modules that expose those JDK classes put you in a split package situation? Cheers, Paul ? ? From: Paul Benedict [mailto:HYPERLINK "mailto:pbenedict at apache.org" \npbenedict at apache.org] Sent: Thursday, March 10, 2016 10:16 PM To: Stephen Felts Cc: Alex Buckley; ML OpenJDK Jigsaw Developers Subject: Re: Unnamed module and duplicate package ? Stephen, regarding your first paragraph, I would like some more detail. Are you running your application server with jigsaw?? ? Cheers, Paul ? On Thu, Mar 10, 2016 at 8:33 PM, Stephen Felts wrote: I'm aware of classes in our application server (not javax) that are unused when running with our own JVM and used when running with another JVM. In that case, the packages are duplicate of classes in the JDK.? I would not want that usage to generate a fatal error. This is unrelated to endorsed jar files. In addition to an upgradeable module for java.transaction.jar with Jigsaw, I'm also running with an upgradeable module for javax.annotation-api-1.2.jar. From Roger.Riggs at Oracle.com Fri Mar 11 14:27:00 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 11 Mar 2016 09:27:00 -0500 Subject: Initial webrev with changes for JDK 9 - jimage In-Reply-To: References: <56D84C7D.9020006@oracle.com> <56DF14EE.1050102@Oracle.com> Message-ID: <56E2D5B4.7010408@Oracle.com> Thanks Jim. Beware of use of Lambdas, jimage may be used early enough in the boot cycle that lambdas are not yet fully operative. The failure is pretty obvious but can be trial and error to narrow it down. It would be useful to create an jira entry for the changes that are being delayed. Roger On 3/10/2016 6:22 PM, Jim Laskey (Oracle) wrote: > Thank you Roger. Comments inline. In general, I will hold off changes until after merge so as not to destabilize. Note that ImageBufferCache and Decompression are not currently used. > >> On Mar 8, 2016, at 2:07 PM, Roger Riggs wrote: >> >> Hi, >> >> Review comments for the jimage code in java.base, mostly cleanup but perhaps a bug or two. >> General: inconsistent style and not following guidelines, copyright dates may need an update. >> Use of assert for error checking is not going to catch or help isolate errors in production builds. > Noted. > >> dir: jdk/src/java.base/share/classes/jdk/internal/jimage/ >> >> >> BasicImageReader: >> - readHeader() exception message should say not a jimage or wrong version >> Other IOExceptions can occur if the file is corrupted or is too small, array index out of bounds, etc. > Replaced with specific exceptions. > >> - findLocation() should use a more explicit computation for the redirection >> than rehashing; this would allow the hash seed to be encapsulated. > As part of the review change set, I've documented the Minimal Perfect Hash Method (see PerfectHashBuilder.) The algorithm requires a one time one rehash when there is a collision. A new seed forces a different distribution of the colliding strings. If you started with the existing hashCode, you would not get a new distribution, merely a shift of all the colliding elements. Random distribution is the essence of algorithm. > >> - slice() synchronizes on the ByteBuffer; does every other access? > Byte buffer use here is immutable, however slicing of the ByteBuffer does require modifying position and limit. Wrapping or cloning the buffers would be of little benefit and would take a performance hit. The ByteBuffer API might have been well served with an atomic non-modifying slice operation. > >> - getAllLocations() is unused and does not respect its sorted argument; >> Best to remove the method for now. > Removed. > >> - getResourceBuffer(): unused - remove > Removed. > >> - getResourceStream(): unused - remove > Removed. > >> ImageStringsReader: >> >> - Is Modified UTF-8 really needed here; using normal UTF-8 would allow >> re-use and better performance. Alternatively, Modified UTF-8 should be >> added as a supported encoding. > Modified UTF-8 is used to be more compact and to simplify use in native code. The jimage string table has overlapping use with constant pool compaction so is really an older revision of the Modified UTF-8 standard. Not sure why Modifed UTF-8 is not offered as an encoding. It would have made constant pool management easier. And note that relying on a particular encoding is problematic. Encoding standards do change, affecting the stability of the hash algorithm and may prevent the reading of older jimage files. > >> - The ImageStringsReader.hashCode() should be defined so it can take advantage of 32 or 64 bit accesses; since it is used frequently. And it needs to be stable across revisions that may be accessing jimages from different JDK versions. >> > Reasonable and will consider. Not sure what you mean by stable across revisions. This is not string hashCode. This is a hashCode that is specific to MPHM and is deterministic. > >> - stringFromMUTF8(byte[]) - there may be some optimization to avoid expanding ascii to chars and then re-encoding in String. > Will touch base with the Aleksey. > >> - charsFromByteBufferLength/charsFromByteBuffer should throw an exception if no terminating null, not just when assertions are enabled > Will throw InternalError instead. > >> - inconsistent assert errors vs exceptions for malformed mutf8. >> Use of assert will not detect errors in production builds > Will throw InternalError instead. > >> - mutf8FromChars allocates a new working buffer (byte[8]) potentially for every UNICODE char. > Will hoist the buffer allocation and reuse. > >> - mutf8FromString: should take advantage of new String(bytes, offset, length, charsetName) to avoid extra allocations. >> (would need a Modified utf-8 charset). > Modified UTF-8 not available. > >> - hashCode(byte[0, seed) should be private; the hashcode algorithm should not be variable. >> > This is not String hashCode. see above. > >> ImageLocation: >> - Merge ImageLocation functions into ImageLocationBase and rename. >> ImageLocation does not have enough unique functionality to be a separate class. > Merged. > >> - It is a poor design to create an instance that may not be valid. >> It would be better to have an ImageLocation factory method that encapsulated the creation and checking >> > Noted. > >> >> ImageLocationBase: >> - Failing asserts will not cause a runtime error in production. >> But will degenerate into unpredictable other exceptions > Will throw InternalError instead. > >> ImageStream: >> - compress(): Too heavyweight an object to be used and discarded just for compress / decompress of small values. > compress()? I don?t see ImageStream used anywhere except for large buffers. As a note, dynamic ByteBuffers really should be part of the JDK. > >> >> ImageBufferCache: >> - Comments on each method would make the intent clear > Will add comments. > >> - getBuffer: mixing for loop and explicit indexes is fragile >> - releaseBuffer: check buffer.capacity before threadLocal.get() for early return >> - Logic of i,j is flawed, i is never changed; j is/becomes 0 >> The first buffer is removed if there are more than max >> Its not clear what algorithm was intended. >> A buffer that is in use can be removed. > Rewrote using lambdas to clarify the algorithm. > >> - ImageBufferCache constructor: the isUsed flag should be set in getBuffer() >> when it is added to the list (not in the constructor) >> It keeps it consistent with when it is set for a re-used buffer. >> > Modified. > >> ImageHeader: >> - BADMAGIC is not used > Removed. > >> - readFrom could throw BufferUnderflowException - undocumented > get(i) can IndexOutOfBoundsException [and get() BufferUnderflowException] Will add explicit check. > > >> ImageModuleData: >> - ImageModuleData seems to be unused; allModuleNames() is unreferenced >> > Removed. > >> ImageReader: >> - ImageReader(path): unused - remove > Removed. > >> - Use of assert is non-reassuring, ineffective in production builds > Added explicit check. > >> - In a long running application the per thread buffers will get to the point wehere they are unused and should be released. >> There is no support for soft or weak references to handle that case. >> Alternatively, if the buffers were not per thread then they would have a lesser impact. > The core libs team was concerned about the performance of class loading. The pattern used here is the one followed by NIO. We will probably come up with a shared NIO cache at some point. > >> Also, why should there be more than one buffer per thread? > The image cache is only used by 32 bit systems and decompression. It is possible for a channel read buffer and a decompression buffer to be allocated at the same time. > >> ImageReader.Resource: >> - unused create method > Removed. > >> - unused parent argument (0) in Resource constructor (dir, loc, attr) > Removed. > >> ImageReader.LinkNode: >> - constructor has unused parent arg >> >> > Removed > >> decompress/CompressIndexes: >> - readInt: wasteful allocation of a single byte array and then another small byte array; >> and then another heap buffer allocation in the ByteBuffer. > Removed all allocation. > >> - decompress is hugely wasteful of allocations of ByteBuffers of small sizes. >> > Removed all allocation. > > >> decompress/CompressedResourceHeader: >> - MAGIC does not need to be public >> >> >> decompress/Decompressor: >> - IOException "Plugin name not found" should include the missing name >> >> - StringsProvider is an unnecessary interface; could use Supplier >> >> - Redundant public modifiers in interface declarations >> >> decompress/SignatureParser: >> - Comments describing the input and output formats needed >> >> - style around operators does not consistently include spaces; and "if("... >> >> decompress/StringSharingDecompressor: >> - Wasteful use of ByteBuffers and small arrays without re-use (safeAdd...) >> >> - StringSharingDecompressor constructor with unused argument - remove >> >> >> decompress/ZipDecompressor: >> - Should be more specific about the zip algorithms supported >> since it needs to be stable across releases >> >> - decompress(): use try-with-resources for safer inflation >> > I think decompression needs significant reworking.. > >> src/java.base/share/native/libjimage/imageDecompressor.cpp >> - "// If ptr is not aligned, sparc will fail." implies input argument must be aligned >> >> - General doubt about using assert; for example to check on malloc allocation failure >> >> - In production environment will exhibit as segv >> > Noted. > From david.lloyd at redhat.com Fri Mar 11 14:52:05 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 11 Mar 2016 08:52:05 -0600 Subject: Unnamed module and duplicate package In-Reply-To: <56E2A12F.5020000@oracle.com> References: <56E286EB.5000904@oracle.com> <56E2A12F.5020000@oracle.com> Message-ID: <56E2DB95.4010600@redhat.com> On 03/11/2016 04:42 AM, Alan Bateman wrote: > > On 11/03/2016 10:04, Neil Bartlett wrote: >> : >> >> Whatever the motivation, I referred to this package as ?broken? >> because it has caused a great many problems for OSGi users. >> Applications that import the javax.transaction package may encounter >> NoClassDefFoundError due to the missing types if they wire to the >> platform export. The most commonly employed practical solution is to >> add back those types with the application ClassLoader. > Deploying the classes on the class path (application class loader) meant > some types in javax.transaction defined to the boot loader (because of > delegation) and some to the application class loader. A sad state of > affairs that would not have worked if there had been any reliance on > anything package private. > > Going forward then it requires deploying the EE version of the > java.transaction module on the upgrade module path. What about javax.transaction.xa? Ideally we won't just throw that into some unnamed module right? With it being a part of java.sql though, it's going to be pretty tough to separate out. Can it not at least be its own module which can be upgraded in a consistent way with java.transaction? I guess it's just not clear to me how this is going to work. From my perspective, it would be at the least more organizationally convenient to treat all the SE+EE modules in the same way. > Yes, except the types in the javax.sql.rowset package as that is a > different module. > > The definition for both the java.sql and java.sql.rowset modules can be > found here: > http://cr.openjdk.java.net/~mr/jigsaw/ea/module-summary.html#java.sql > > or if you have the EA builds then `java > -listmods:java.sql,java.sql.rowset` will describe these modules. > > In terms of visibility then both modules are currently defined to the > boot loader and hence their types are visible via any of the built-in > class loaders. We are on a mission to move non-core modules out of the > boot loader so that they don't have all permissions by default. Easier > said that done of course but we have already moved all the modules > shared with EE so that they can be upgraded by app servers. That would definitely be ideal from a security standpoint, especially if in this context "non-core" means "all except for 'java.base'"... or as close as possible to it. > I hope we can move java.sql.rowset module, I don't know about java.sql > yet. There is a small spec change needed to do the latter because > currently only the boot loader can defined java.* types (one of the > comments in your mail suggests you are aware of this detail). -- - DML From Alan.Bateman at oracle.com Fri Mar 11 15:23:21 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 11 Mar 2016 15:23:21 +0000 Subject: Unnamed module and duplicate package In-Reply-To: <56E2DB95.4010600@redhat.com> References: <56E286EB.5000904@oracle.com> <56E2A12F.5020000@oracle.com> <56E2DB95.4010600@redhat.com> Message-ID: <56E2E2E9.2050307@oracle.com> On 11/03/2016 14:52, David M. Lloyd wrote: > > What about javax.transaction.xa? Ideally we won't just throw that > into some unnamed module right? > > With it being a part of java.sql though, it's going to be pretty tough > to separate out. Can it not at least be its own module which can be > upgraded in a consistent way with java.transaction? I guess it's just > not clear to me how this is going to work. From my perspective, it > would be at the least more organizationally convenient to treat all > the SE+EE modules in the same way. The proposal is for the java.sql module to own and export javax.transaction.xa. You'll see it in the summary table that I linked to in the mail. On the surface then it might look odd but we've explored many options. The good news is that javax.transaction.xa is slow moving, I'm not aware of any changes in 10+ years. We have of course discussed this with the relevant spec leads in the JCP and we of course understand that it requires a bit of coordination in the event that JSR 907 decides some day to update something in the xa package. > > That would definitely be ideal from a security standpoint, especially > if in this context "non-core" means "all except for 'java.base'"... or > as close as possible to it. We are currently down to ~25 modules defined to the boot loader. With more effort then we could reduce this a bit (maybe by 4 or 5 modules). -Alan. From david.lloyd at redhat.com Fri Mar 11 15:30:13 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 11 Mar 2016 09:30:13 -0600 Subject: Unnamed module and duplicate package In-Reply-To: <56E2E2E9.2050307@oracle.com> References: <56E286EB.5000904@oracle.com> <56E2A12F.5020000@oracle.com> <56E2DB95.4010600@redhat.com> <56E2E2E9.2050307@oracle.com> Message-ID: <56E2E485.40403@redhat.com> On 03/11/2016 09:23 AM, Alan Bateman wrote: > > On 11/03/2016 14:52, David M. Lloyd wrote: >> >> What about javax.transaction.xa? Ideally we won't just throw that >> into some unnamed module right? >> >> With it being a part of java.sql though, it's going to be pretty tough >> to separate out. Can it not at least be its own module which can be >> upgraded in a consistent way with java.transaction? I guess it's just >> not clear to me how this is going to work. From my perspective, it >> would be at the least more organizationally convenient to treat all >> the SE+EE modules in the same way. > The proposal is for the java.sql module to own and export > javax.transaction.xa. You'll see it in the summary table that I linked > to in the mail. > > On the surface then it might look odd but we've explored many options. > The good news is that javax.transaction.xa is slow moving, I'm not aware > of any changes in 10+ years. We have of course discussed this with the > relevant spec leads in the JCP and we of course understand that it > requires a bit of coordination in the event that JSR 907 decides some > day to update something in the xa package. > > >> >> That would definitely be ideal from a security standpoint, especially >> if in this context "non-core" means "all except for 'java.base'"... or >> as close as possible to it. > We are currently down to ~25 modules defined to the boot loader. With > more effort then we could reduce this a bit (maybe by 4 or 5 modules). What are the limiting factors? In my analysis the only problem that seemed close to insurmountable was the special natives that are used in the JDK but these only seem to be used from java.base. Does it all boil down to getClassLoader()==null security checks on the Java side, or is there a JVM component that I haven't discovered? -- - DML From david.lloyd at redhat.com Fri Mar 11 15:31:59 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 11 Mar 2016 09:31:59 -0600 Subject: Unnamed module and duplicate package In-Reply-To: <56E2E2E9.2050307@oracle.com> References: <56E286EB.5000904@oracle.com> <56E2A12F.5020000@oracle.com> <56E2DB95.4010600@redhat.com> <56E2E2E9.2050307@oracle.com> Message-ID: <56E2E4EF.7020402@redhat.com> On 03/11/2016 09:23 AM, Alan Bateman wrote: > > On 11/03/2016 14:52, David M. Lloyd wrote: >> >> What about javax.transaction.xa? Ideally we won't just throw that >> into some unnamed module right? >> >> With it being a part of java.sql though, it's going to be pretty tough >> to separate out. Can it not at least be its own module which can be >> upgraded in a consistent way with java.transaction? I guess it's just >> not clear to me how this is going to work. From my perspective, it >> would be at the least more organizationally convenient to treat all >> the SE+EE modules in the same way. > The proposal is for the java.sql module to own and export > javax.transaction.xa. You'll see it in the summary table that I linked > to in the mail. > > On the surface then it might look odd but we've explored many options. > The good news is that javax.transaction.xa is slow moving, I'm not aware > of any changes in 10+ years. We have of course discussed this with the > relevant spec leads in the JCP and we of course understand that it > requires a bit of coordination in the event that JSR 907 decides some > day to update something in the xa package. OK, it just seems odd since javax.transaction.xa has no dependencies on anything and thus would seem to be a good candidate to be its own module. This would solve the problem for all time, so it's not really clear why that couldn't or shouldn't be done. -- - DML From mandy.chung at oracle.com Fri Mar 11 15:36:37 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 11 Mar 2016 07:36:37 -0800 Subject: Initial webrev with changes for JDK 9 - jimage In-Reply-To: <56E2D5B4.7010408@Oracle.com> References: <56D84C7D.9020006@oracle.com> <56DF14EE.1050102@Oracle.com> <56E2D5B4.7010408@Oracle.com> Message-ID: We rework the VM initialization such that lambdas can be used very early after phase 1 initialization is done and before module system initialization. I?m not sure where jimage uses of lambdas for this case. In general, we wanted to enable use of new language features early during startup and we have this solve in jake (startup performance is a different topic). Mandy > On Mar 11, 2016, at 6:27 AM, Roger Riggs wrote: > > Thanks Jim. > > Beware of use of Lambdas, jimage may be used early enough in the boot cycle that lambdas > are not yet fully operative. The failure is pretty obvious but can be trial and error to narrow it down. > > It would be useful to create an jira entry for the changes that are being delayed. > > Roger > > > On 3/10/2016 6:22 PM, Jim Laskey (Oracle) wrote: >> Thank you Roger. Comments inline. In general, I will hold off changes until after merge so as not to destabilize. Note that ImageBufferCache and Decompression are not currently used. >> >>> On Mar 8, 2016, at 2:07 PM, Roger Riggs wrote: >>> >>> Hi, >>> >>> Review comments for the jimage code in java.base, mostly cleanup but perhaps a bug or two. >>> General: inconsistent style and not following guidelines, copyright dates may need an update. >>> Use of assert for error checking is not going to catch or help isolate errors in production builds. >> Noted. >> >>> dir: jdk/src/java.base/share/classes/jdk/internal/jimage/ >>> >>> >>> BasicImageReader: >>> - readHeader() exception message should say not a jimage or wrong version >>> Other IOExceptions can occur if the file is corrupted or is too small, array index out of bounds, etc. >> Replaced with specific exceptions. >> >>> - findLocation() should use a more explicit computation for the redirection >>> than rehashing; this would allow the hash seed to be encapsulated. >> As part of the review change set, I've documented the Minimal Perfect Hash Method (see PerfectHashBuilder.) The algorithm requires a one time one rehash when there is a collision. A new seed forces a different distribution of the colliding strings. If you started with the existing hashCode, you would not get a new distribution, merely a shift of all the colliding elements. Random distribution is the essence of algorithm. >> >>> - slice() synchronizes on the ByteBuffer; does every other access? >> Byte buffer use here is immutable, however slicing of the ByteBuffer does require modifying position and limit. Wrapping or cloning the buffers would be of little benefit and would take a performance hit. The ByteBuffer API might have been well served with an atomic non-modifying slice operation. >> >>> - getAllLocations() is unused and does not respect its sorted argument; >>> Best to remove the method for now. >> Removed. >> >>> - getResourceBuffer(): unused - remove >> Removed. >> >>> - getResourceStream(): unused - remove >> Removed. >> >>> ImageStringsReader: >>> >>> - Is Modified UTF-8 really needed here; using normal UTF-8 would allow >>> re-use and better performance. Alternatively, Modified UTF-8 should be >>> added as a supported encoding. >> Modified UTF-8 is used to be more compact and to simplify use in native code. The jimage string table has overlapping use with constant pool compaction so is really an older revision of the Modified UTF-8 standard. Not sure why Modifed UTF-8 is not offered as an encoding. It would have made constant pool management easier. And note that relying on a particular encoding is problematic. Encoding standards do change, affecting the stability of the hash algorithm and may prevent the reading of older jimage files. >> >>> - The ImageStringsReader.hashCode() should be defined so it can take advantage of 32 or 64 bit accesses; since it is used frequently. And it needs to be stable across revisions that may be accessing jimages from different JDK versions. >>> >> Reasonable and will consider. Not sure what you mean by stable across revisions. This is not string hashCode. This is a hashCode that is specific to MPHM and is deterministic. >> >>> - stringFromMUTF8(byte[]) - there may be some optimization to avoid expanding ascii to chars and then re-encoding in String. >> Will touch base with the Aleksey. >> >>> - charsFromByteBufferLength/charsFromByteBuffer should throw an exception if no terminating null, not just when assertions are enabled >> Will throw InternalError instead. >> >>> - inconsistent assert errors vs exceptions for malformed mutf8. >>> Use of assert will not detect errors in production builds >> Will throw InternalError instead. >> >>> - mutf8FromChars allocates a new working buffer (byte[8]) potentially for every UNICODE char. >> Will hoist the buffer allocation and reuse. >> >>> - mutf8FromString: should take advantage of new String(bytes, offset, length, charsetName) to avoid extra allocations. >>> (would need a Modified utf-8 charset). >> Modified UTF-8 not available. >> >>> - hashCode(byte[0, seed) should be private; the hashcode algorithm should not be variable. >>> >> This is not String hashCode. see above. >> >>> ImageLocation: >>> - Merge ImageLocation functions into ImageLocationBase and rename. >>> ImageLocation does not have enough unique functionality to be a separate class. >> Merged. >> >>> - It is a poor design to create an instance that may not be valid. >>> It would be better to have an ImageLocation factory method that encapsulated the creation and checking >>> >> Noted. >> >>> ImageLocationBase: >>> - Failing asserts will not cause a runtime error in production. >>> But will degenerate into unpredictable other exceptions >> Will throw InternalError instead. >> >>> ImageStream: >>> - compress(): Too heavyweight an object to be used and discarded just for compress / decompress of small values. >> compress()? I don?t see ImageStream used anywhere except for large buffers. As a note, dynamic ByteBuffers really should be part of the JDK. >> >>> >>> ImageBufferCache: >>> - Comments on each method would make the intent clear >> Will add comments. >> >>> - getBuffer: mixing for loop and explicit indexes is fragile >>> - releaseBuffer: check buffer.capacity before threadLocal.get() for early return >>> - Logic of i,j is flawed, i is never changed; j is/becomes 0 >>> The first buffer is removed if there are more than max >>> Its not clear what algorithm was intended. >>> A buffer that is in use can be removed. >> Rewrote using lambdas to clarify the algorithm. >> >>> - ImageBufferCache constructor: the isUsed flag should be set in getBuffer() >>> when it is added to the list (not in the constructor) >>> It keeps it consistent with when it is set for a re-used buffer. >>> >> Modified. >> >>> ImageHeader: >>> - BADMAGIC is not used >> Removed. >> >>> - readFrom could throw BufferUnderflowException - undocumented >> get(i) can IndexOutOfBoundsException [and get() BufferUnderflowException] Will add explicit check. >> >> >>> ImageModuleData: >>> - ImageModuleData seems to be unused; allModuleNames() is unreferenced >>> >> Removed. >> >>> ImageReader: >>> - ImageReader(path): unused - remove >> Removed. >> >>> - Use of assert is non-reassuring, ineffective in production builds >> Added explicit check. >> >>> - In a long running application the per thread buffers will get to the point wehere they are unused and should be released. >>> There is no support for soft or weak references to handle that case. >>> Alternatively, if the buffers were not per thread then they would have a lesser impact. >> The core libs team was concerned about the performance of class loading. The pattern used here is the one followed by NIO. We will probably come up with a shared NIO cache at some point. >> >>> Also, why should there be more than one buffer per thread? >> The image cache is only used by 32 bit systems and decompression. It is possible for a channel read buffer and a decompression buffer to be allocated at the same time. >> >>> ImageReader.Resource: >>> - unused create method >> Removed. >> >>> - unused parent argument (0) in Resource constructor (dir, loc, attr) >> Removed. >> >>> ImageReader.LinkNode: >>> - constructor has unused parent arg >>> >>> >> Removed >> >>> decompress/CompressIndexes: >>> - readInt: wasteful allocation of a single byte array and then another small byte array; >>> and then another heap buffer allocation in the ByteBuffer. >> Removed all allocation. >> >>> - decompress is hugely wasteful of allocations of ByteBuffers of small sizes. >>> >> Removed all allocation. >> >> >>> decompress/CompressedResourceHeader: >>> - MAGIC does not need to be public >>> >>> >>> decompress/Decompressor: >>> - IOException "Plugin name not found" should include the missing name >>> >>> - StringsProvider is an unnecessary interface; could use Supplier >>> >>> - Redundant public modifiers in interface declarations >>> >>> decompress/SignatureParser: >>> - Comments describing the input and output formats needed >>> >>> - style around operators does not consistently include spaces; and "if("... >>> >>> decompress/StringSharingDecompressor: >>> - Wasteful use of ByteBuffers and small arrays without re-use (safeAdd...) >>> >>> - StringSharingDecompressor constructor with unused argument - remove >>> >>> >>> decompress/ZipDecompressor: >>> - Should be more specific about the zip algorithms supported >>> since it needs to be stable across releases >>> >>> - decompress(): use try-with-resources for safer inflation >>> >> I think decompression needs significant reworking.. >> >>> src/java.base/share/native/libjimage/imageDecompressor.cpp >>> - "// If ptr is not aligned, sparc will fail." implies input argument must be aligned >>> >>> - General doubt about using assert; for example to check on malloc allocation failure >>> >>> - In production environment will exhibit as segv >>> >> Noted. >> > From james.laskey at oracle.com Fri Mar 11 15:47:38 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Fri, 11 Mar 2016 11:47:38 -0400 Subject: Initial webrev with changes for JDK 9 - jimage In-Reply-To: References: <56D84C7D.9020006@oracle.com> <56DF14EE.1050102@Oracle.com> <56E2D5B4.7010408@Oracle.com> Message-ID: A non issue. I discussed using NIO buffers with Alan. That is the direction we will go. > On Mar 11, 2016, at 11:36 AM, Mandy Chung wrote: > > We rework the VM initialization such that lambdas can be used very early after phase 1 initialization is done and before module system initialization. > > I?m not sure where jimage uses of lambdas for this case. In general, we wanted to enable use of new language features early during startup and we have this solve in jake (startup performance is a different topic). > > Mandy > >> On Mar 11, 2016, at 6:27 AM, Roger Riggs wrote: >> >> Thanks Jim. >> >> Beware of use of Lambdas, jimage may be used early enough in the boot cycle that lambdas >> are not yet fully operative. The failure is pretty obvious but can be trial and error to narrow it down. >> >> It would be useful to create an jira entry for the changes that are being delayed. >> >> Roger >> >> >> On 3/10/2016 6:22 PM, Jim Laskey (Oracle) wrote: >>> Thank you Roger. Comments inline. In general, I will hold off changes until after merge so as not to destabilize. Note that ImageBufferCache and Decompression are not currently used. >>> >>>> On Mar 8, 2016, at 2:07 PM, Roger Riggs wrote: >>>> >>>> Hi, >>>> >>>> Review comments for the jimage code in java.base, mostly cleanup but perhaps a bug or two. >>>> General: inconsistent style and not following guidelines, copyright dates may need an update. >>>> Use of assert for error checking is not going to catch or help isolate errors in production builds. >>> Noted. >>> >>>> dir: jdk/src/java.base/share/classes/jdk/internal/jimage/ >>>> >>>> >>>> BasicImageReader: >>>> - readHeader() exception message should say not a jimage or wrong version >>>> Other IOExceptions can occur if the file is corrupted or is too small, array index out of bounds, etc. >>> Replaced with specific exceptions. >>> >>>> - findLocation() should use a more explicit computation for the redirection >>>> than rehashing; this would allow the hash seed to be encapsulated. >>> As part of the review change set, I've documented the Minimal Perfect Hash Method (see PerfectHashBuilder.) The algorithm requires a one time one rehash when there is a collision. A new seed forces a different distribution of the colliding strings. If you started with the existing hashCode, you would not get a new distribution, merely a shift of all the colliding elements. Random distribution is the essence of algorithm. >>> >>>> - slice() synchronizes on the ByteBuffer; does every other access? >>> Byte buffer use here is immutable, however slicing of the ByteBuffer does require modifying position and limit. Wrapping or cloning the buffers would be of little benefit and would take a performance hit. The ByteBuffer API might have been well served with an atomic non-modifying slice operation. >>> >>>> - getAllLocations() is unused and does not respect its sorted argument; >>>> Best to remove the method for now. >>> Removed. >>> >>>> - getResourceBuffer(): unused - remove >>> Removed. >>> >>>> - getResourceStream(): unused - remove >>> Removed. >>> >>>> ImageStringsReader: >>>> >>>> - Is Modified UTF-8 really needed here; using normal UTF-8 would allow >>>> re-use and better performance. Alternatively, Modified UTF-8 should be >>>> added as a supported encoding. >>> Modified UTF-8 is used to be more compact and to simplify use in native code. The jimage string table has overlapping use with constant pool compaction so is really an older revision of the Modified UTF-8 standard. Not sure why Modifed UTF-8 is not offered as an encoding. It would have made constant pool management easier. And note that relying on a particular encoding is problematic. Encoding standards do change, affecting the stability of the hash algorithm and may prevent the reading of older jimage files. >>> >>>> - The ImageStringsReader.hashCode() should be defined so it can take advantage of 32 or 64 bit accesses; since it is used frequently. And it needs to be stable across revisions that may be accessing jimages from different JDK versions. >>>> >>> Reasonable and will consider. Not sure what you mean by stable across revisions. This is not string hashCode. This is a hashCode that is specific to MPHM and is deterministic. >>> >>>> - stringFromMUTF8(byte[]) - there may be some optimization to avoid expanding ascii to chars and then re-encoding in String. >>> Will touch base with the Aleksey. >>> >>>> - charsFromByteBufferLength/charsFromByteBuffer should throw an exception if no terminating null, not just when assertions are enabled >>> Will throw InternalError instead. >>> >>>> - inconsistent assert errors vs exceptions for malformed mutf8. >>>> Use of assert will not detect errors in production builds >>> Will throw InternalError instead. >>> >>>> - mutf8FromChars allocates a new working buffer (byte[8]) potentially for every UNICODE char. >>> Will hoist the buffer allocation and reuse. >>> >>>> - mutf8FromString: should take advantage of new String(bytes, offset, length, charsetName) to avoid extra allocations. >>>> (would need a Modified utf-8 charset). >>> Modified UTF-8 not available. >>> >>>> - hashCode(byte[0, seed) should be private; the hashcode algorithm should not be variable. >>>> >>> This is not String hashCode. see above. >>> >>>> ImageLocation: >>>> - Merge ImageLocation functions into ImageLocationBase and rename. >>>> ImageLocation does not have enough unique functionality to be a separate class. >>> Merged. >>> >>>> - It is a poor design to create an instance that may not be valid. >>>> It would be better to have an ImageLocation factory method that encapsulated the creation and checking >>>> >>> Noted. >>> >>>> ImageLocationBase: >>>> - Failing asserts will not cause a runtime error in production. >>>> But will degenerate into unpredictable other exceptions >>> Will throw InternalError instead. >>> >>>> ImageStream: >>>> - compress(): Too heavyweight an object to be used and discarded just for compress / decompress of small values. >>> compress()? I don?t see ImageStream used anywhere except for large buffers. As a note, dynamic ByteBuffers really should be part of the JDK. >>> >>>> >>>> ImageBufferCache: >>>> - Comments on each method would make the intent clear >>> Will add comments. >>> >>>> - getBuffer: mixing for loop and explicit indexes is fragile >>>> - releaseBuffer: check buffer.capacity before threadLocal.get() for early return >>>> - Logic of i,j is flawed, i is never changed; j is/becomes 0 >>>> The first buffer is removed if there are more than max >>>> Its not clear what algorithm was intended. >>>> A buffer that is in use can be removed. >>> Rewrote using lambdas to clarify the algorithm. >>> >>>> - ImageBufferCache constructor: the isUsed flag should be set in getBuffer() >>>> when it is added to the list (not in the constructor) >>>> It keeps it consistent with when it is set for a re-used buffer. >>>> >>> Modified. >>> >>>> ImageHeader: >>>> - BADMAGIC is not used >>> Removed. >>> >>>> - readFrom could throw BufferUnderflowException - undocumented >>> get(i) can IndexOutOfBoundsException [and get() BufferUnderflowException] Will add explicit check. >>> >>> >>>> ImageModuleData: >>>> - ImageModuleData seems to be unused; allModuleNames() is unreferenced >>>> >>> Removed. >>> >>>> ImageReader: >>>> - ImageReader(path): unused - remove >>> Removed. >>> >>>> - Use of assert is non-reassuring, ineffective in production builds >>> Added explicit check. >>> >>>> - In a long running application the per thread buffers will get to the point wehere they are unused and should be released. >>>> There is no support for soft or weak references to handle that case. >>>> Alternatively, if the buffers were not per thread then they would have a lesser impact. >>> The core libs team was concerned about the performance of class loading. The pattern used here is the one followed by NIO. We will probably come up with a shared NIO cache at some point. >>> >>>> Also, why should there be more than one buffer per thread? >>> The image cache is only used by 32 bit systems and decompression. It is possible for a channel read buffer and a decompression buffer to be allocated at the same time. >>> >>>> ImageReader.Resource: >>>> - unused create method >>> Removed. >>> >>>> - unused parent argument (0) in Resource constructor (dir, loc, attr) >>> Removed. >>> >>>> ImageReader.LinkNode: >>>> - constructor has unused parent arg >>>> >>>> >>> Removed >>> >>>> decompress/CompressIndexes: >>>> - readInt: wasteful allocation of a single byte array and then another small byte array; >>>> and then another heap buffer allocation in the ByteBuffer. >>> Removed all allocation. >>> >>>> - decompress is hugely wasteful of allocations of ByteBuffers of small sizes. >>>> >>> Removed all allocation. >>> >>> >>>> decompress/CompressedResourceHeader: >>>> - MAGIC does not need to be public >>>> >>>> >>>> decompress/Decompressor: >>>> - IOException "Plugin name not found" should include the missing name >>>> >>>> - StringsProvider is an unnecessary interface; could use Supplier >>>> >>>> - Redundant public modifiers in interface declarations >>>> >>>> decompress/SignatureParser: >>>> - Comments describing the input and output formats needed >>>> >>>> - style around operators does not consistently include spaces; and "if("... >>>> >>>> decompress/StringSharingDecompressor: >>>> - Wasteful use of ByteBuffers and small arrays without re-use (safeAdd...) >>>> >>>> - StringSharingDecompressor constructor with unused argument - remove >>>> >>>> >>>> decompress/ZipDecompressor: >>>> - Should be more specific about the zip algorithms supported >>>> since it needs to be stable across releases >>>> >>>> - decompress(): use try-with-resources for safer inflation >>>> >>> I think decompression needs significant reworking.. >>> >>>> src/java.base/share/native/libjimage/imageDecompressor.cpp >>>> - "// If ptr is not aligned, sparc will fail." implies input argument must be aligned >>>> >>>> - General doubt about using assert; for example to check on malloc allocation failure >>>> >>>> - In production environment will exhibit as segv >>>> >>> Noted. >>> >> > From mandy.chung at oracle.com Fri Mar 11 16:13:18 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 11 Mar 2016 16:13:18 +0000 Subject: hg: jigsaw/jake/nashorn: 4 new changesets Message-ID: <201603111613.u2BGDItO027381@aojmv0008.oracle.com> Changeset: 70f0c3970211 Author: hannesw Date: 2016-03-07 13:28 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/70f0c3970211 8148148: Remove pluggable CodeStore API Reviewed-by: attila, mhaupt ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/CodeStore.java Changeset: 0714a30d7833 Author: lana Date: 2016-03-10 09:28 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/0714a30d7833 Added tag jdk-9+109 for changeset 70f0c3970211 ! .hgtags Changeset: 5acf59e3cbcc Author: mchung Date: 2016-03-11 08:12 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/5acf59e3cbcc allow dups bugids ! .jcheck/conf Changeset: 87da6692cd26 Author: mchung Date: 2016-03-11 08:13 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/87da6692cd26 Merge ! .hgtags From jan.lahoda at oracle.com Fri Mar 11 16:28:20 2016 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Fri, 11 Mar 2016 16:28:20 +0000 Subject: hg: jigsaw/jake/langtools: Must fail the build then javac fails Message-ID: <201603111628.u2BGSKcH004196@aojmv0008.oracle.com> Changeset: 556fedf967ed Author: jlahoda Date: 2016-03-11 17:28 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/556fedf967ed Must fail the build then javac fails ! make/build.xml From paul.sandoz at oracle.com Fri Mar 11 16:50:34 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 11 Mar 2016 17:50:34 +0100 Subject: Initial webrev with changes for JDK 9 In-Reply-To: <56E29267.7070501@oracle.com> References: <56E29267.7070501@oracle.com> Message-ID: <57D437E7-2EC8-45DB-85C0-3ECA3047AA8C@oracle.com> > On 11 Mar 2016, at 10:39, Alan Bateman wrote: > > > I've refreshed the webrevs here: > http://cr.openjdk.java.net/~alanb/8142968/2 > I browsed the code. Generally the feeling i get is it?s of good quality. Previously some of this area was quite legacy and it is refreshing to view more modern code. Comments below, only the first is something i think we should really change, the others are up to you. Once Jigsaw goes in i wonder if we should opportunistically revisit the use of URL and Enumeration with class loaders? Paul. sun/util/locale/provider/ResourceBundleProviderSupport.java ? 72 // java.base may not be able to read the bundleClass's module. 73 PrivilegedAction pa1 = () -> { ctor.setAccessible(true); return null; }; 74 AccessController.doPrivileged(pa1); 75 try { 76 return ctor.newInstance((Object[]) null); 77 } catch (InvocationTargetException e) { 78 Unsafe.getUnsafe().throwException(e.getTargetException()); 79 } catch (InstantiationException | IllegalAccessException e) { 80 throw new InternalError(e); 81 } 82 } catch (NoSuchMethodException e) { 83 } 84 } 85 return null; 86 } Please avoid the use of Unsafe here, use a sneaky throw instead if necessary, or wrap. That Unsafe method needs to die! j.l.Class ? 2476 @CallerSensitive 2477 public URL getResource(String name) { 2478 name = resolveName(name); 2479 2480 // if this Class and the caller are in the same named module 2481 // then attempt to get URL to the resource in the module 2482 Module module = getModule(); 2483 if (module.isNamed()) { 2484 Class caller = Reflection.getCallerClass(); 2485 if (caller != null && caller.getModule() == module) { 2486 String mn = getModule().getName(); 2487 ClassLoader cl = getClassLoader0(); 2488 try { 2489 if (cl == null) { 2490 return BootLoader.findResource(mn, name); 2491 } else { 2492 return cl.findResource(mn, name); 2493 } 2494 } catch (IOException ioe) { 2495 return null; 2496 } 2497 } 2498 } The method getResourceAsStream has an optimisation for a BuiltinClassLoader: 2412 // special-case built-in class loaders to avoid the 2413 // need for a URL connection 2414 if (cl == null) { 2415 return BootLoader.findResourceAsStream(mn, name); 2416 } else if (cl instanceof BuiltinClassLoader) { 2417 return ((BuiltinClassLoader) cl).findResourceAsStream(mn, name); 2418 } else { 2419 URL url = cl.findResource(mn, name); 2420 return (url != null) ? url.openStream() : null; 2421 } Is that something you plan to include for getResource too at some point? j.l.ClassLoader ? 1777 // define Package object if the named package is not yet defined 1778 NamedPackage p = packages.computeIfAbsent(name, 1779 k -> NamedPackage.toPackage(name, m)); 1780 if (p instanceof Package) 1781 return (Package)p; 1782 1783 // otherwise, replace the NamedPackage object with Package object 1784 return (Package)packages.compute(name, this::toPackage); You could merge the computeIfAbsent and compute into a single compute call if you so wish. return (Package)packages.compute((n, p) -> { // define Package object if the named package is not yet defined if (p == null) return NamedPackage.toPackage(name, m); // otherwise, replace the NamedPackage object with Package object return (p instanceof Package) ? p : toPackage(n, p); }); 2553 /** 2554 * Returns the ServiceCatalog for modules defined to this class loader, 2555 * creating it if it doesn't already exist. 2556 */ 2557 ServicesCatalog createOrGetServicesCatalog() { 2558 ServicesCatalog catalog = servicesCatalog; 2559 if (catalog == null) { 2560 catalog = new ServicesCatalog(); 2561 boolean set = trySetObjectField("servicesCatalog", catalog); 2562 if (!set) { 2563 // beaten by someone else 2564 catalog = servicesCatalog; 2565 } 2566 } 2567 return catalog; 2568 } 2569 2570 // the ServiceCatalog for modules associated with this class loader. 2571 private volatile ServicesCatalog servicesCatalog; 2572 2573 2574 /** 2575 * Attempts to atomically set a volatile field in this object. Returns 2576 * {@code true} if not beaten by another thread. Avoids the use of 2577 * AtomicReferenceFieldUpdater in this class. 2578 */ 2579 private boolean trySetObjectField(String name, Object obj) { 2580 Unsafe unsafe = Unsafe.getUnsafe(); 2581 Class k = ClassLoader.class; 2582 long offset; 2583 try { 2584 Field f = k.getDeclaredField(name); 2585 offset = unsafe.objectFieldOffset(f); 2586 } catch (NoSuchFieldException e) { 2587 throw new InternalError(e); 2588 } 2589 return unsafe.compareAndSwapObject(this, offset, null, obj); 2590 } If you can syncrhonize on this, just use double checked locking? j.l.i.BoundMethodHandle ? 791 // ## FIXME 792 // assert F_SPECIES_DATA.getDeclaredAnnotation(Stable.class) != null; That?s odd. Why did that need commenting out? MethodHandles ? That?s quite some trick to create PUBLIC_LOOKUP :-) spinning up a new class (?Unamed?) in a new class loader. If that mechanism is gonna stay and If there are costs associated with that, we could easily skip the ASM part and use hard coded bytes. j.l.r.Proxy ? 636 private static final WeakCache>, Class> proxyCache = 637 new WeakCache<>(new KeyFactory(), 638 new BiFunction>, Class>() { 639 @Override 640 public Class apply(Module m, List> interfaces) { 641 Objects.requireNonNull(m); 642 return defineProxyClass(m, interfaces); 643 } 644 }); Wild idea: this feels like an equivalent of j.l.i.ClassValue for Module. 781 static Set> referencedTypes(ClassLoader loader, List> interfaces) { 782 Set> types = new HashSet<>(); 783 for (Class intf : interfaces) { 784 for (Method m : intf.getMethods()) { 785 // return type, parameter types, and exception types 786 Stream.concat(Stream.concat(Stream.of(m.getReturnType()), 787 Arrays.stream(m.getParameterTypes())), 788 Arrays.stream(m.getExceptionTypes())) 789 .map(ProxyBuilder::getElementType) 790 .filter(t -> !t.isPrimitive()) 791 .forEach(types::add); 792 } 793 } 794 return types; 795 } Use Stream.flatMap e.g. interfaces.stream().flatMap(i -> Stream.of(i.getMethods()). flatMap(m -> f(m) /*extract all types on method*/). map(?).filter(?).collect(toSet()) Stream> f(Method m) { return Stream.of(new Class[] {m.getReturnType()}, m.getParameterTypes(), m.getExceptionTypes()). flatMap(a -> Stream.of(a)); } 939 private static final WeakHashMap dynProxyModules = new WeakHashMap<>(); 940 private static final AtomicInteger counter = new AtomicInteger(); 941 942 /* 943 * Define a dynamic module for the generated proxy classes in a non-exported package 944 * named com.sun.proxy.$MODULE. 945 * 946 * Each class loader will have one dynamic module. 947 */ 948 static synchronized Module getDynamicModule(ClassLoader loader) { 949 Module m = dynProxyModules.get(loader); 950 if (m == null) { 951 String mn = "jdk.proxy" + counter.incrementAndGet(); 952 String pn = PROXY_PACKAGE_PREFIX + "." + mn; 953 m = Modules.defineModule(loader, mn, Collections.singleton(pn)); 954 Modules.addReads(m, Proxy.class.getModule()); 955 // java.base to create proxy instance 956 Modules.addExports(m, pn, Object.class.getModule()); 957 dynProxyModules.put(loader, m); 958 } 959 return m; 960 } Consider using computeIfAbsent. At the moment no need for AtomicInteger. 1055 @CallerSensitive 1056 public static Object newProxyInstance(ClassLoader loader, 1057 Class[] interfaces, 1058 InvocationHandler h) { 1059 Objects.requireNonNull(h); 1060 1061 final List> intfs = Arrays.asList(interfaces.clone()); Use List.of, which will also clone? This presumes that there are no null values in the array. sun.invoke.util.VerifyAccess ? 198 while (c.isArray()) { 199 c = c.getComponentType(); 200 } This pattern is occurring a number of times. Memo: add a method on Arrays, or somewhere?, sun.net.www.protocol.jrt.JavaRuntimeURLConnection ? 56 private static final ImageReader reader = ImageReaderFactory.getImageReader(); reader -> READER sun.util.resources.LocaleData ? 77 private static final Map> candidatesMap = new ConcurrentHashMap<>(); candidatesMap -> CANDIDATES_MAP native/libjimage/imageDecompressor.cpp ? 114 // Sparc to read unaligned content 115 // u8 l = (*(u8*) ptr); 116 // If ptr is not aligned, sparc will fail. 117 u8 ImageDecompressor::getU8(u1* ptr, Endian *endian) { 118 u8 ret; 119 if (endian->is_big_endian()) { 120 ret = (u8)ptr[0] << 56 | (u8)ptr[1] << 48 | (u8)ptr[2]<<40 | (u8)ptr[3]<<32 | 121 ptr[4]<<24 | ptr[5]<<16 | ptr[6]<<8 | ptr[7]; 122 } else { 123 ret = ptr[0] | ptr[1]<<8 | ptr[2]<<16 | ptr[3]<<24 | (u8)ptr[4]<<32 | 124 (u8)ptr[5]<<40 | (u8)ptr[6]<<48 | (u8)ptr[7]<<56; 125 } 126 return ret; 127 } 128 129 u4 ImageDecompressor::getU4(u1* ptr, Endian *endian) { 130 u4 ret; 131 if (endian->is_big_endian()) { 132 ret = ptr[0] << 24 | ptr[1]<<16 | (ptr[2]<<8) | ptr[3]; 133 } else { 134 ret = ptr[0] | ptr[1]<<8 | (ptr[2]<<16) | ptr[3]<<24; 135 } 136 return ret; 137 } I dunno if hotspot/src/share/vm/utilities/bytes.hpp can be leveraged here. java.lang.module.ModuleInfo ? 460 private static boolean isAttributeDisallowed(String name) { 461 Set notAllowed = predefinedNotAllowed; 462 if (notAllowed == null) { 463 notAllowed = Stream.of( 464 "ConstantValue", 465 "Code", 466 "StackMapTable", 467 "Exceptions", 468 "EnclosingMethod", 469 "Signature", 470 "LineNumberTable", 471 "LocalVariableTable", 472 "LocalVariableTypeTable", 473 "RuntimeVisibleAnnotations", 474 "RuntimeInvisibleAnnotations", 475 "RuntimeVisibleParameterAnnotations", 476 "RuntimeInvisibleParameterAnnotations", 477 "RuntimeVisibleTypeAnnotations", 478 "RuntimeInvisibleTypeAnnotations", 479 "AnnotationDefault", 480 "BootstrapMethods", 481 "MethodParameters") 482 .collect(Collectors.toSet()); 483 predefinedNotAllowed = notAllowed; Consider using Set.of 484 } 485 486 if (notAllowed.contains(name)) { 487 return true; 488 } else { 489 return false; 490 } 491 } j.l.ModuleReader ? 145 default Optional read(String name) throws IOException { 146 final int BUFFER_SIZE = 8192; 147 final int MAX_BUFFER_SIZE = Integer.MAX_VALUE - 8; 148 149 InputStream in = open(name).orElse(null); 150 if (in == null) { 151 // not found 152 return Optional.empty(); 153 } 154 155 try (in) { 156 int capacity = in.available(); 157 if (capacity == 0) 158 capacity = BUFFER_SIZE; 159 160 byte[] buf = new byte[capacity]; 161 int nread = 0; 162 int n; 163 for (;;) { Use InputStream.readAllBytes? jdk.internal.module.Builder ? 56 private static final Set MANDATED = 57 Collections.singleton(Requires.Modifier.MANDATED); 58 private static final Set PUBLIC = 59 Collections.singleton(Requires.Modifier.PUBLIC); Set.of ? From harold.seigel at oracle.com Fri Mar 11 17:03:12 2016 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Fri, 11 Mar 2016 17:03:12 +0000 Subject: hg: jigsaw/jake/hotspot: Remove JNIEnv arg from JVM internal methods Message-ID: <201603111703.u2BH3C8I020556@aojmv0008.oracle.com> Changeset: 16505d7780b0 Author: hseigel Date: 2016-03-11 11:33 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/16505d7780b0 Remove JNIEnv arg from JVM internal methods ! src/share/vm/classfile/modules.cpp ! src/share/vm/classfile/modules.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/whitebox.cpp From Alan.Bateman at oracle.com Fri Mar 11 17:53:45 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 11 Mar 2016 17:53:45 +0000 Subject: Initial webrev with changes for JDK 9 In-Reply-To: <57D437E7-2EC8-45DB-85C0-3ECA3047AA8C@oracle.com> References: <56E29267.7070501@oracle.com> <57D437E7-2EC8-45DB-85C0-3ECA3047AA8C@oracle.com> Message-ID: <56E30629.3030005@oracle.com> On 11/03/2016 16:50, Paul Sandoz wrote: > : > I browsed the code. Generally the feeling i get is it?s of good quality. Previously some of this area was quite legacy and it is refreshing to view more modern code. Thanks for going through it. There is quite a mix here, lots of new code but lots of ancient code has to be changed along the way. > > Comments below, only the first is something i think we should really change, the others are up to you. > > Once Jigsaw goes in i wonder if we should opportunistically revisit the use of URL and Enumeration with class loaders? Potentially, it's just hasn't been interesting so far because the legacy ClassLoader methods aren't specified to locate resources in modules. > : > > > The method getResourceAsStream has an optimisation for a BuiltinClassLoader: > > : > > Is that something you plan to include for getResource too at some point? getResource returns a URL so the optimization to avoid the going through the URL protocol handler isn't applicable. > > If you can syncrhonize on this, just use double checked locking? I'll look at it, part of the reason for the currently implementation is that we were setting several fields. > > > > j.l.i.BoundMethodHandle > ? > > 791 // ## FIXME > 792 // assert F_SPECIES_DATA.getDeclaredAnnotation(Stable.class) != null; > > That?s odd. Why did that need commenting out? getDeclarationAnnotation => annotation parsing and creating proxies and too early in the VM startup for that. It was commented out in one of the numerous sync ups I think. I'll ask a comment to it. > > > MethodHandles > ? > > That?s quite some trick to create PUBLIC_LOOKUP :-) spinning up a new class (?Unamed?) in a new class loader. If that mechanism is gonna stay and If there are costs associated with that, we could easily skip the ASM part and use hard coded bytes. I think TBD, I think John would like PL to revert to using Object as the lookup class but requires extending the lookup modes. I have an issue in JIRA to track another phase of work here. > : > > > > > 198 while (c.isArray()) { > 199 c = c.getComponentType(); > 200 } > > This pattern is occurring a number of times. > > Memo: add a method on Arrays, or somewhere?, I agree, we have several places that need the package name but they can be called with array objects. > > > sun.net.www.protocol.jrt.JavaRuntimeURLConnection > ? > > 56 private static final ImageReader reader = ImageReaderFactory.getImageReader(); > > reader -> READER okay. > > > java.lang.module.ModuleInfo > ? > > : > > Consider using Set.of I agree, it pre-dates Set.of of course. > > j.l.ModuleReader > ? > > : > > Use InputStream.readAllBytes? I meant to do that this, this code pre-dates readAllBytes. > > > jdk.internal.module.Builder > ? > > 56 private static final Set MANDATED = > 57 Collections.singleton(Requires.Modifier.MANDATED); > 58 private static final Set PUBLIC = > 59 Collections.singleton(Requires.Modifier.PUBLIC); > > Set.of ? Okay. From jan.lahoda at oracle.com Fri Mar 11 17:58:23 2016 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Fri, 11 Mar 2016 17:58:23 +0000 Subject: hg: jigsaw/jake/langtools: Fixing IntelliJ project after the recent langtools ant build change - change by mcimadamore Message-ID: <201603111758.u2BHwN2p019240@aojmv0008.oracle.com> Changeset: 41fc9021548e Author: jlahoda Date: 2016-03-11 18:57 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/41fc9021548e Fixing IntelliJ project after the recent langtools ant build change - change by mcimadamore ! make/intellij/build.xml ! make/intellij/src/idea/LangtoolsIdeaAntLogger.java From sean.mullan at oracle.com Fri Mar 11 19:38:25 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 11 Mar 2016 14:38:25 -0500 Subject: Initial webrev with changes for JDK 9 In-Reply-To: <56E29267.7070501@oracle.com> References: <56E29267.7070501@oracle.com> Message-ID: <56E31EB1.3010700@oracle.com> Myself (mullan), Tony (ascarpino), and Vinnie (vinnie) reviewed the security-libs and java.naming changes and did not find any issues. So it's good to go from our perspective. --Sean On 03/11/2016 04:39 AM, Alan Bateman wrote: > > I've refreshed the webrevs here: > http://cr.openjdk.java.net/~alanb/8142968/2 > > so that we have a snapshot of what is currently in the jigsaw/jake > forest. The webrevs are against jdk-9+109. > > As I said in the last mail, we would like to integrate this snapshot > into JDK 9 before the end of March. The proposal is to aim to integrate > during the week of March 21, with the the week of March 28 as fallback > in event of problems. > > The related JEPs (JEP 200, JEP 260, JEP 261 and JEP 282) are now in > "Proposed to Target" state. Mark send mail to jdk9-dev with this list > and other proposals yesterday. > > -Alan From mandy.chung at oracle.com Fri Mar 11 20:53:40 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 11 Mar 2016 12:53:40 -0800 Subject: Initial webrev with changes for JDK 9 In-Reply-To: <57D437E7-2EC8-45DB-85C0-3ECA3047AA8C@oracle.com> References: <56E29267.7070501@oracle.com> <57D437E7-2EC8-45DB-85C0-3ECA3047AA8C@oracle.com> Message-ID: <9AA94BB7-AE00-4DC9-8999-3F5DDBCA3C1B@oracle.com> Thanks for the feedback. > On Mar 11, 2016, at 8:50 AM, Paul Sandoz wrote: > : > > sun/util/locale/provider/ResourceBundleProviderSupport.java > ? > > > 72 // java.base may not be able to read the bundleClass's module. > 73 PrivilegedAction pa1 = () -> { ctor.setAccessible(true); return null; }; > 74 AccessController.doPrivileged(pa1); > 75 try { > 76 return ctor.newInstance((Object[]) null); > 77 } catch (InvocationTargetException e) { > 78 Unsafe.getUnsafe().throwException(e.getTargetException()); > 79 } catch (InstantiationException | IllegalAccessException e) { > 80 throw new InternalError(e); > 81 } > 82 } catch (NoSuchMethodException e) { > 83 } > 84 } > 85 return null; > 86 } > > > Please avoid the use of Unsafe here, use a sneaky throw instead if necessary, or wrap. I agree. It's also used from ResourceBundle.Control::newBundle. Since core reflection now gets readability for free, setAccessible is no longer needed [1]. So it can call Class::newInstance instead. I fixed both places not to use Unsafe. > > j.l.ClassLoader > ? > > 1777 // define Package object if the named package is not yet defined > 1778 NamedPackage p = packages.computeIfAbsent(name, > 1779 k -> NamedPackage.toPackage(name, m)); > 1780 if (p instanceof Package) > 1781 return (Package)p; > 1782 > 1783 // otherwise, replace the NamedPackage object with Package object > 1784 return (Package)packages.compute(name, this::toPackage); > > You could merge the computeIfAbsent and compute into a single compute call if you so wish. > > return (Package)packages.compute((n, p) -> { > // define Package object if the named package is not yet defined > if (p == null) return NamedPackage.toPackage(name, m); > // otherwise, replace the NamedPackage object with Package object > return (p instanceof Package) ? p : toPackage(n, p); > }); > Thanks for the example. I will keep it as is. > > j.l.r.Proxy > ? > > 636 private static final WeakCache>, Class> proxyCache = > 637 new WeakCache<>(new KeyFactory(), > 638 new BiFunction>, Class>() { > 639 @Override > 640 public Class apply(Module m, List> interfaces) { > 641 Objects.requireNonNull(m); > 642 return defineProxyClass(m, interfaces); > 643 } > 644 }); > > Wild idea: this feels like an equivalent of j.l.i.ClassValue for Module. > Feels like that. This is the case when the proxy class is generated in a dynamic module case [1]. It?s a computed value with the given list of proxy interfaces and the given defining class loader. Each dynamic proxy is defined by a given class loader. The target Module where the proxy class may be a newly defined dynamic module per the given class loader. So a given list of proxy interfaces + the defining class loader will map to one Module. > > : > Use Stream.flatMap e.g. > > interfaces.stream().flatMap(i -> Stream.of(i.getMethods()). > flatMap(m -> f(m) /*extract all types on method*/). > map(?).filter(?).collect(toSet()) > > Stream> f(Method m) { > return Stream.of(new Class[] {m.getReturnType()}, m.getParameterTypes(), m.getExceptionTypes()). > flatMap(a -> Stream.of(a)); > } Updated. > > Consider using computeIfAbsent. At the moment no need for AtomicInteger. > > Updated. I probably intended to convert that when converting to AtomicInteger. > 1055 @CallerSensitive > 1056 public static Object newProxyInstance(ClassLoader loader, > 1057 Class[] interfaces, > 1058 InvocationHandler h) { > 1059 Objects.requireNonNull(h); > 1060 > 1061 final List> intfs = Arrays.asList(interfaces.clone()); > > Use List.of, which will also clone? This presumes that there are no null values in the array. Updated. Happy to use the new JDK 9 List.of method (the code predates List.of). Yes it will clone and do null check. > > sun.invoke.util.VerifyAccess > ? > > 198 while (c.isArray()) { > 199 c = c.getComponentType(); > 200 } > > This pattern is occurring a number of times. > > Memo: add a method on Arrays, or somewhere?, > +1. Perhaps Class::getBaseElementType. > > sun.util.resources.LocaleData > ? > > 77 private static final Map> candidatesMap = new ConcurrentHashMap<>(); > > candidatesMap -> CANDIDATES_MAP > Changed. Alan has covered the rest. Mandy [1] http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-March/000248.html [2] http://download.java.net/java/jigsaw/docs/api/java/lang/reflect/Proxy.html#membership From paul.sandoz at oracle.com Fri Mar 11 21:09:31 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 11 Mar 2016 22:09:31 +0100 Subject: Initial webrev with changes for JDK 9 In-Reply-To: <56E30629.3030005@oracle.com> References: <56E29267.7070501@oracle.com> <57D437E7-2EC8-45DB-85C0-3ECA3047AA8C@oracle.com> <56E30629.3030005@oracle.com> Message-ID: <6C67A050-8A8B-4C31-A04D-27945454CFB0@oracle.com> > On 11 Mar 2016, at 18:53, Alan Bateman wrote: > > On 11/03/2016 16:50, Paul Sandoz wrote: >> : >> I browsed the code. Generally the feeling i get is it?s of good quality. Previously some of this area was quite legacy and it is refreshing to view more modern code. > Thanks for going through it. There is quite a mix here, lots of new code but lots of ancient code has to be changed along the way. > >> >> Comments below, only the first is something i think we should really change, the others are up to you. >> >> Once Jigsaw goes in i wonder if we should opportunistically revisit the use of URL and Enumeration with class loaders? > Potentially, it's just hasn't been interesting so far because the legacy ClassLoader methods aren't specified to locate resources in modules. > Understand. Just looking for opportunities to "rm Enumeration" and potentially improve how URIs are processed by encouraging the use of ?java.net.URI? instead of ?java.net.URL? (even if one has to transform the former to the latter to open a connection). > >> : >> >> >> The method getResourceAsStream has an optimisation for a BuiltinClassLoader: >> >> : >> >> Is that something you plan to include for getResource too at some point? > getResource returns a URL so the optimization to avoid the going through the URL protocol handler isn't applicable. > Ok. > >> >> If you can syncrhonize on this, just use double checked locking? > I'll look at it, part of the reason for the currently implementation is that we were setting several fields. > AFAICT it only CAS?es one field. > >> >> >> >> j.l.i.BoundMethodHandle >> ? >> >> 791 // ## FIXME >> 792 // assert F_SPECIES_DATA.getDeclaredAnnotation(Stable.class) != null; >> >> That?s odd. Why did that need commenting out? > getDeclarationAnnotation => annotation parsing and creating proxies and too early in the VM startup for that. It was commented out in one of the numerous sync ups I think. > Ah! > I'll ask a comment to it. > > >> >> >> MethodHandles >> ? >> >> That?s quite some trick to create PUBLIC_LOOKUP :-) spinning up a new class (?Unamed?) in a new class loader. If that mechanism is gonna stay and If there are costs associated with that, we could easily skip the ASM part and use hard coded bytes. > I think TBD, I think John would like PL to revert to using Object as the lookup class but requires extending the lookup modes. I have an issue in JIRA to track another phase of work here. > Ok. This is a gnarly area. Paul. From paul.sandoz at oracle.com Fri Mar 11 21:19:00 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 11 Mar 2016 22:19:00 +0100 Subject: Initial webrev with changes for JDK 9 In-Reply-To: <9AA94BB7-AE00-4DC9-8999-3F5DDBCA3C1B@oracle.com> References: <56E29267.7070501@oracle.com> <57D437E7-2EC8-45DB-85C0-3ECA3047AA8C@oracle.com> <9AA94BB7-AE00-4DC9-8999-3F5DDBCA3C1B@oracle.com> Message-ID: <219DA2AB-4DE1-4F32-B7AF-F5E42314E86C@oracle.com> > On 11 Mar 2016, at 21:53, Mandy Chung wrote: > > Thanks for the feedback. > >> On Mar 11, 2016, at 8:50 AM, Paul Sandoz wrote: >> : >> >> sun/util/locale/provider/ResourceBundleProviderSupport.java >> ? >> >> >> 72 // java.base may not be able to read the bundleClass's module. >> 73 PrivilegedAction pa1 = () -> { ctor.setAccessible(true); return null; }; >> 74 AccessController.doPrivileged(pa1); >> 75 try { >> 76 return ctor.newInstance((Object[]) null); >> 77 } catch (InvocationTargetException e) { >> 78 Unsafe.getUnsafe().throwException(e.getTargetException()); >> 79 } catch (InstantiationException | IllegalAccessException e) { >> 80 throw new InternalError(e); >> 81 } >> 82 } catch (NoSuchMethodException e) { >> 83 } >> 84 } >> 85 return null; >> 86 } >> >> >> Please avoid the use of Unsafe here, use a sneaky throw instead if necessary, or wrap. > > I agree. It's also used from ResourceBundle.Control::newBundle. Since core reflection now gets readability for free, setAccessible is no longer needed [1]. So it can call Class::newInstance instead. I fixed both places not to use Unsafe. > Thanks! >> >> j.l.ClassLoader >> ? >> >> 1777 // define Package object if the named package is not yet defined >> 1778 NamedPackage p = packages.computeIfAbsent(name, >> 1779 k -> NamedPackage.toPackage(name, m)); >> 1780 if (p instanceof Package) >> 1781 return (Package)p; >> 1782 >> 1783 // otherwise, replace the NamedPackage object with Package object >> 1784 return (Package)packages.compute(name, this::toPackage); >> >> You could merge the computeIfAbsent and compute into a single compute call if you so wish. >> >> return (Package)packages.compute((n, p) -> { >> // define Package object if the named package is not yet defined >> if (p == null) return NamedPackage.toPackage(name, m); >> // otherwise, replace the NamedPackage object with Package object >> return (p instanceof Package) ? p : toPackage(n, p); >> }); >> > > Thanks for the example. I will keep it as is. Ok. One advantage of the merged-approach is it?s atomic. The former may update an entry twice if there is a race, but that may not matter. > >> >> j.l.r.Proxy >> ? >> >> 636 private static final WeakCache>, Class> proxyCache = >> 637 new WeakCache<>(new KeyFactory(), >> 638 new BiFunction>, Class>() { >> 639 @Override >> 640 public Class apply(Module m, List> interfaces) { >> 641 Objects.requireNonNull(m); >> 642 return defineProxyClass(m, interfaces); >> 643 } >> 644 }); >> >> Wild idea: this feels like an equivalent of j.l.i.ClassValue for Module. >> > > Feels like that. > > This is the case when the proxy class is generated in a dynamic module case [1]. It?s a computed value with the given list of proxy interfaces and the given defining class loader. > > Each dynamic proxy is defined by a given class loader. The target Module where the proxy class may be a newly defined dynamic module per the given class loader. So a given list of proxy interfaces + the defining class loader will map to one Module. > Ok, so it takes some additional arguments to compute the value, so does not map quite so cleanly. >> >> sun.invoke.util.VerifyAccess >> ? >> >> 198 while (c.isArray()) { >> 199 c = c.getComponentType(); >> 200 } >> >> This pattern is occurring a number of times. >> >> Memo: add a method on Arrays, or somewhere?, >> > > +1. Perhaps Class::getBaseElementType. > Yes, something like that. Thanks, Paul. From alex.buckley at oracle.com Fri Mar 11 21:31:52 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 11 Mar 2016 13:31:52 -0800 Subject: Unnamed module and duplicate package In-Reply-To: <56E2E4EF.7020402@redhat.com> References: <56E286EB.5000904@oracle.com> <56E2A12F.5020000@oracle.com> <56E2DB95.4010600@redhat.com> <56E2E2E9.2050307@oracle.com> <56E2E4EF.7020402@redhat.com> Message-ID: <56E33948.5050304@oracle.com> On 3/11/2016 7:31 AM, David M. Lloyd wrote: > On 03/11/2016 09:23 AM, Alan Bateman wrote: >> >> On 11/03/2016 14:52, David M. Lloyd wrote: >>> >>> What about javax.transaction.xa? Ideally we won't just throw that >>> into some unnamed module right? >>> >>> With it being a part of java.sql though, it's going to be pretty tough >>> to separate out. Can it not at least be its own module which can be >>> upgraded in a consistent way with java.transaction? I guess it's just >>> not clear to me how this is going to work. From my perspective, it >>> would be at the least more organizationally convenient to treat all >>> the SE+EE modules in the same way. >> The proposal is for the java.sql module to own and export >> javax.transaction.xa. You'll see it in the summary table that I linked >> to in the mail. >> >> On the surface then it might look odd but we've explored many options. >> The good news is that javax.transaction.xa is slow moving, I'm not aware >> of any changes in 10+ years. We have of course discussed this with the >> relevant spec leads in the JCP and we of course understand that it >> requires a bit of coordination in the event that JSR 907 decides some >> day to update something in the xa package. > > OK, it just seems odd since javax.transaction.xa has no dependencies on > anything and thus would seem to be a good candidate to be its own > module. This would solve the problem for all time, so it's not really > clear why that couldn't or shouldn't be done. A type in the java.sql module (javax.sql.XAConnection) returns a javax.transaction.xa.* type. Therefore, the java.sql module would have to depend on the tiny new module containing the javax.transaction.xa package. The java.sql module is mapped to the bootstrap loader, so the the tiny new module would have to be mapped to the bootstrap loader too. That means it's not upgradeable, so there's little benefit in carving it out at this time. The mapping of java.sql to the bootstrap loader also explains why the javax.transaction.xa package hasn't been placed in the tiny existing module java.transaction. Said module has been moved out of the bootstrap loader, as part of the work to move java.corba out of the bootstrap loader. tl;dr JDBC is a substantial shareholder in the javax.transaction.xa package. Alex From mandy.chung at oracle.com Fri Mar 11 21:56:14 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 11 Mar 2016 13:56:14 -0800 Subject: Review for the new static ClassLoader.getPlatformClassLoader method Message-ID: <16FA6B3B-BE75-438A-8429-EB8B2A0AC28C@oracle.com> http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/8146373/webrev.00/ This adds a new static ClassLoader.getPlatformClassLoader method to return a class loader via which all of the built-in Java SE and JDK types are visible. This would be useful as several JDK modules are deprivileged. To prepare for the future deprivileging work, this patch also relaxes the check such that java.* classes are defined by the platform class loader or its ancestor. Mandy [1] http://openjdk.java.net/projects/jigsaw/spec/issues/#PlatformClassLoader From alex.buckley at oracle.com Fri Mar 11 21:56:28 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 11 Mar 2016 13:56:28 -0800 Subject: Unnamed module and duplicate package In-Reply-To: References: <56E286EB.5000904@oracle.com> Message-ID: <56E33F0C.4090805@oracle.com> On 3/11/2016 2:04 AM, Neil Bartlett wrote: >> On 11 Mar 2016, at 08:50, Alan Bateman >> wrote: >> The transaction API is one of a small number of APIs shared between >> Java SE and EE. The complete set is non-aggregator modules that >> java.se.ee requires. In the case of the transaction API then Java >> SE defines the minimum subset of javax.transaction required to >> support the mapping of CORBA system exceptions to RMI exceptions. >> The Java Language to IDL Mapping spec has the details. Java SE >> defines all the types in javax.transacation.xa, important because >> JDBC supports XA. > > Whatever the motivation, I referred to this package as ?broken? > because it has caused a great many problems for OSGi users. > Applications that import the javax.transaction package may encounter > NoClassDefFoundError due to the missing types if they wire to the > platform export. The most commonly employed practical solution is to > add back those types with the application ClassLoader. > > A properly constructed set of OSGi bundles *should* never throw > NoClassDefFoundError or ClassNotFoundException, and I would hope this > will also be the case in Jigsaw. For a set of consistently compiled modules with no unchecked warnings, the JPMS guarantees the JVM will never throw NoClassDefFoundError, nor ClassCastException due to heap pollution ("no unchecked warnings") or split packages (as 'requires' != Require-Bundle). Per Alan's comment, guaranteeing no ClassNotFoundException is impossible because consistently compiled code can use Class::forName with random strings. Alex From alex.buckley at oracle.com Fri Mar 11 22:01:20 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 11 Mar 2016 14:01:20 -0800 Subject: Unnamed module and duplicate package In-Reply-To: References: <56E22A15.2080402@oracle.com> Message-ID: <56E34030.4020704@oracle.com> On 3/10/2016 6:33 PM, Stephen Felts wrote: > I'm aware of classes in our application server (not javax) that are > unused when running with our own JVM and used when running with > another JVM. In that case, the packages are duplicate of classes in > the JDK. I would not want that usage to generate a fatal error. This > is unrelated to endorsed jar files. I agree that such usage should not generate a fatal error when we're talking about duplicates of non-java.* and non-javax.* classes. Let's say your classpath JAR has foo.bar.* classes that happen to overlap with a named module's internal classes (i.e. doesn't export foo.bar). This isn't a bug in your JAR -- in general you don't and shouldn't know the internals of any named module, whether JDK or user, whether in the image or on the modulepath. What happens at run time? :- - If the named module is mapped to the bootstrap or extension loader because it's a well known JDK module, then no problem -- the application loader has no reason to delegate for foo.bar.* classes (the JDK module didn't export it) nor will the application loader search any of its own named modules for the package (since none of them export it either). The application loader will look in its unnamed module by searching the classpath, and find your JAR's foo.bar.* classes. - If the named module is mapped to the application loader, then the application loader will search in that module when code in that module accesses foo.bar.* classes. The classpath JAR is ignored. Even after the application loader has defined foo.bar.* classes from the named module, they're inaccessible to code in the unnamed module, despite being in the same loader. [Strong encapsulation.] The takeaway from all this algebra is that either your classpath JAR's package is used completely (because no named module dominated it) or it's not used at all (because a named module dominated it). [Reliable dependencies -- even a legacy JAR that doesn't declare dependencies is still guaranteed a package that, because it's not split, will work reliably.] Alex From mandy.chung at oracle.com Fri Mar 11 22:22:42 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 11 Mar 2016 14:22:42 -0800 Subject: Initial webrev with changes for JDK 9 In-Reply-To: <219DA2AB-4DE1-4F32-B7AF-F5E42314E86C@oracle.com> References: <56E29267.7070501@oracle.com> <57D437E7-2EC8-45DB-85C0-3ECA3047AA8C@oracle.com> <9AA94BB7-AE00-4DC9-8999-3F5DDBCA3C1B@oracle.com> <219DA2AB-4DE1-4F32-B7AF-F5E42314E86C@oracle.com> Message-ID: <25EAACA2-C582-40FF-8D74-FD27CB3743CC@oracle.com> > On Mar 11, 2016, at 1:19 PM, Paul Sandoz wrote: > >> >> On 11 Mar 2016, at 21:53, Mandy Chung wrote: >> >> I agree. It's also used from ResourceBundle.Control::newBundle. Since core reflection now gets readability for free, setAccessible is no longer needed [1]. So it can call Class::newInstance instead. I fixed both places not to use Unsafe. >> > > Thanks! In fact, I have to keep setAccessible since the type may not exported to java.base. I changed it to use sneaky throw. > Ok. One advantage of the merged-approach is it?s atomic. The former may update an entry twice if there is a race, but that may not matter. OK. Good to change it anyway. In case you want to see the diff: http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/jake-m3/webrev-03-11/index.html Mandy From mandy.chung at oracle.com Fri Mar 11 22:23:58 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 11 Mar 2016 22:23:58 +0000 Subject: hg: jigsaw/jake/jdk: review comment from psandoz Message-ID: <201603112223.u2BMNwmr006054@aojmv0008.oracle.com> Changeset: 5c08f0bb5231 Author: mchung Date: 2016-03-11 14:23 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5c08f0bb5231 review comment from psandoz ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/java/lang/reflect/Proxy.java ! src/java.base/share/classes/java/util/ResourceBundle.java ! src/java.base/share/classes/sun/util/locale/provider/ResourceBundleProviderSupport.java ! src/java.base/share/classes/sun/util/resources/LocaleData.java From njbartlett at gmail.com Fri Mar 11 22:32:34 2016 From: njbartlett at gmail.com (Neil Bartlett) Date: Fri, 11 Mar 2016 22:32:34 +0000 Subject: Unnamed module and duplicate package In-Reply-To: <56E33F0C.4090805@oracle.com> References: <56E286EB.5000904@oracle.com> <56E33F0C.4090805@oracle.com> Message-ID: > On 11 Mar 2016, at 21:56, Alex Buckley wrote: > > On 3/11/2016 2:04 AM, Neil Bartlett wrote: >>> On 11 Mar 2016, at 08:50, Alan Bateman >>> wrote: >>> The transaction API is one of a small number of APIs shared between >>> Java SE and EE. The complete set is non-aggregator modules that >>> java.se.ee requires. In the case of the transaction API then Java >>> SE defines the minimum subset of javax.transaction required to >>> support the mapping of CORBA system exceptions to RMI exceptions. >>> The Java Language to IDL Mapping spec has the details. Java SE >>> defines all the types in javax.transacation.xa, important because >>> JDBC supports XA. >> >> Whatever the motivation, I referred to this package as ?broken? >> because it has caused a great many problems for OSGi users. >> Applications that import the javax.transaction package may encounter >> NoClassDefFoundError due to the missing types if they wire to the >> platform export. The most commonly employed practical solution is to >> add back those types with the application ClassLoader. >> >> A properly constructed set of OSGi bundles *should* never throw >> NoClassDefFoundError or ClassNotFoundException, and I would hope this >> will also be the case in Jigsaw. > > For a set of consistently compiled modules with no unchecked warnings, the JPMS guarantees the JVM will never throw NoClassDefFoundError, nor ClassCastException due to heap pollution ("no unchecked warnings") or split packages (as 'requires' != Require-Bundle). > > Per Alan's comment, guaranteeing no ClassNotFoundException is impossible because consistently compiled code can use Class::forName with random strings. Yes I agree this case cannot be prevented ? it remains a problem in OSGi also, so I should have been more specific. It?s my experience that a CNFE can arise when Class.forName is used to load a known class that references (directly or indirectly) an unknown/nonexistent class. This is the kind of error that can be prevented at build time, similarly to NCDFE. > > Alex From Alan.Bateman at oracle.com Sat Mar 12 08:57:34 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 12 Mar 2016 08:57:34 +0000 Subject: Unnamed module and duplicate package In-Reply-To: <56E2E485.40403@redhat.com> References: <56E286EB.5000904@oracle.com> <56E2A12F.5020000@oracle.com> <56E2DB95.4010600@redhat.com> <56E2E2E9.2050307@oracle.com> <56E2E485.40403@redhat.com> Message-ID: <56E3D9FE.7040504@oracle.com> On 11/03/2016 15:30, David M. Lloyd wrote: > > What are the limiting factors? In my analysis the only problem that > seemed close to insurmountable was the special natives that are used > in the JDK but these only seem to be used from java.base. Does it all > boil down to getClassLoader()==null security checks on the Java side, > or is there a JVM component that I haven't discovered? I have no doubt that it would be a big effort. One of the most difficult issues when de-privileging is identifying the minimum permissions. It gets complicated in areas with callbacks where intermediate frames reduce the effective permissions. For several of these modules then it may be that they end up needing AllPermission so the benefits of moving them out are significantly reduced. Related is performance when running with a security manager. A long standing optimization is that code in the boot loader has AllPermission. At things stand then we can't move any modules that export java.* APIs. If getPlatformClassLoader() and the related spec change to allow java.* classes be loaded by the platform class loader and its ancestors goes in then it removes this hurdle. I'm sure there will be lots of other issues once you get into it. Some of the modules (like java.management) are tightly coupled to the VM. On getClassLoader() returning null then such uses would need to be examined. I don't expect there are too many as we replaced a lot of them in the JDK 8 time frame as part of JEP 162. -Alan From Alan.Bateman at oracle.com Sat Mar 12 09:03:37 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 12 Mar 2016 09:03:37 +0000 Subject: Unnamed module and duplicate package In-Reply-To: <56E33948.5050304@oracle.com> References: <56E286EB.5000904@oracle.com> <56E2A12F.5020000@oracle.com> <56E2DB95.4010600@redhat.com> <56E2E2E9.2050307@oracle.com> <56E2E4EF.7020402@redhat.com> <56E33948.5050304@oracle.com> Message-ID: <56E3DB69.1080708@oracle.com> On 11/03/2016 21:31, Alex Buckley wrote: > > A type in the java.sql module (javax.sql.XAConnection) returns a > javax.transaction.xa.* type. Therefore, the java.sql module would have > to depend on the tiny new module containing the javax.transaction.xa > package. The java.sql module is mapped to the bootstrap loader, so the > the tiny new module would have to be mapped to the bootstrap loader > too. That means it's not upgradeable, so there's little benefit in > carving it out at this time. > > The mapping of java.sql to the bootstrap loader also explains why the > javax.transaction.xa package hasn't been placed in the tiny existing > module java.transaction. Said module has been moved out of the > bootstrap loader, as part of the work to move java.corba out of the > bootstrap loader. > > tl;dr JDBC is a substantial shareholder in the javax.transaction.xa > package. Another point is that is that it would very troublesome to have a module in java.se depending on an upgradeable module. We need to keep the upgradeable modules in java.se.ee\java.se. -Alan From mandy.chung at oracle.com Sat Mar 12 16:02:12 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Sat, 12 Mar 2016 16:02:12 +0000 Subject: hg: jigsaw/jake/jdk: Add ClassLoader::getPlatformClassLoader Message-ID: <201603121602.u2CG2Cld024855@aojmv0008.oracle.com> Changeset: 518cb303897e Author: mchung Date: 2016-03-12 08:02 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/518cb303897e Add ClassLoader::getPlatformClassLoader ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/java/nio/file/FileSystems.java ! src/java.base/share/classes/java/nio/file/Files.java ! src/java.base/share/classes/java/util/ServiceLoader.java + test/java/lang/ClassLoader/platformClassLoader/DefinePlatformClass.java + test/java/lang/ClassLoader/platformClassLoader/jdk.zipfs/java/fake/Fake.java From mandy.chung at oracle.com Sat Mar 12 16:02:14 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Sat, 12 Mar 2016 16:02:14 +0000 Subject: hg: jigsaw/jake/hotspot: Add ClassLoader::getPlatformClassLoader Message-ID: <201603121602.u2CG2EqY024899@aojmv0008.oracle.com> Changeset: aa0d6db40ced Author: mchung Date: 2016-03-12 07:48 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/aa0d6db40ced Add ClassLoader::getPlatformClassLoader ! src/share/vm/classfile/systemDictionary.cpp From mandy.chung at oracle.com Sat Mar 12 21:36:59 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Sat, 12 Mar 2016 21:36:59 +0000 Subject: hg: jigsaw/jake/jdk: Update FileSystems and Files javadoc for platform class loader Message-ID: <201603122136.u2CLaxng025299@aojmv0008.oracle.com> Changeset: 1c8e91d7cd98 Author: mchung Date: 2016-03-12 13:37 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1c8e91d7cd98 Update FileSystems and Files javadoc for platform class loader ! src/java.base/share/classes/java/nio/file/FileSystems.java ! src/java.base/share/classes/java/nio/file/Files.java From mark.reinhold at oracle.com Mon Mar 14 02:54:09 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 14 Mar 2016 02:54:09 +0000 Subject: hg: jigsaw/jake/jdk: java.lang.module.ModuleDescriptor.Version, for real Message-ID: <201603140254.u2E2sAgW007110@aojmv0008.oracle.com> Changeset: be5908284f5b Author: mr Date: 2016-03-12 22:44 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/be5908284f5b java.lang.module.ModuleDescriptor.Version, for real ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java ! test/jdk/jigsaw/module/VersionTest.java From sundararajan.athijegannathan at oracle.com Mon Mar 14 04:39:32 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 14 Mar 2016 10:09:32 +0530 Subject: Review for the new static ClassLoader.getPlatformClassLoader method In-Reply-To: <16FA6B3B-BE75-438A-8429-EB8B2A0AC28C@oracle.com> References: <16FA6B3B-BE75-438A-8429-EB8B2A0AC28C@oracle.com> Message-ID: <56E64084.1040707@oracle.com> +1 ClassLoader.getBuiltinPlatformClassLoader method could be private -Sundar On 3/12/2016 3:26 AM, Mandy Chung wrote: > http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/8146373/webrev.00/ > > This adds a new static ClassLoader.getPlatformClassLoader method to return a class loader via which all of the built-in Java SE and JDK types are visible. This would be useful as several JDK modules are deprivileged. To prepare for the future deprivileging work, this patch also relaxes the check such that java.* classes are defined by the platform class loader or its ancestor. > > Mandy > [1] http://openjdk.java.net/projects/jigsaw/spec/issues/#PlatformClassLoader From david.lloyd at redhat.com Mon Mar 14 07:27:25 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 14 Mar 2016 08:27:25 +0100 Subject: Unnamed module and duplicate package In-Reply-To: <56E3D9FE.7040504@oracle.com> References: <56E286EB.5000904@oracle.com> <56E2A12F.5020000@oracle.com> <56E2DB95.4010600@redhat.com> <56E2E2E9.2050307@oracle.com> <56E2E485.40403@redhat.com> <56E3D9FE.7040504@oracle.com> Message-ID: <56E667DD.6060700@redhat.com> On 3/12/16 9:57 AM, Alan Bateman wrote: > > On 11/03/2016 15:30, David M. Lloyd wrote: >> >> What are the limiting factors? In my analysis the only problem that >> seemed close to insurmountable was the special natives that are used >> in the JDK but these only seem to be used from java.base. Does it all >> boil down to getClassLoader()==null security checks on the Java side, >> or is there a JVM component that I haven't discovered? > I have no doubt that it would be a big effort. > > One of the most difficult issues when de-privileging is identifying the > minimum permissions. It gets complicated in areas with callbacks where > intermediate frames reduce the effective permissions. For several of > these modules then it may be that they end up needing AllPermission so > the benefits of moving them out are significantly reduced. > > Related is performance when running with a security manager. A long > standing optimization is that code in the boot loader has AllPermission. > > At things stand then we can't move any modules that export java.* APIs. > If getPlatformClassLoader() and the related spec change to allow java.* > classes be loaded by the platform class loader and its ancestors goes in > then it removes this hurdle. > > I'm sure there will be lots of other issues once you get into it. Some > of the modules (like java.management) are tightly coupled to the VM. On > getClassLoader() returning null then such uses would need to be > examined. I don't expect there are too many as we replaced a lot of them > in the JDK 8 time frame as part of JEP 162. So really there are multiple parts to be able to move modules out of the bootstrap class loader: 1. Relax the spec so that other class loaders (preferably only trusted/blessed class loaders) can define java.* classes 2. Come up with a replacement for getClassLoader() == null checks (e.g. getClassLoader() == null || getClassLoader().isPrivileged()) 3. Then go back and incrementally deprivilege as many modules as possible/practical, as time permits However the benefits seem attractive: improved security (even if only one module gets deprivileged), ability for core modules to depend on upgradable modules (java.sql case). As far as allowing other class loaders to load java.* classes - could it not just be a matter of setting a flag on ClassLoader which is only settable by a non-public constructor or something like that? The flag could be checked easily by Java or native code, and it doesn't tie the JDK more tightly to specific hierarchical class loading arrangements. -- - DML From michael.haupt at oracle.com Mon Mar 14 12:49:40 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Mon, 14 Mar 2016 13:49:40 +0100 Subject: jlink tool review (Re: Initial webrev with changes for JDK 9) In-Reply-To: <56D84C7D.9020006@oracle.com> References: <56D84C7D.9020006@oracle.com> Message-ID: Alan, all, please find a patch with suggested changes to jlink in the attachment. The patch also contains a file named review-comments.txt, which addresses several topics throughout jlink. I've covered most code; only the jlink.internal package is still missing. I've been able to compile jake with these refactorings applied; I have not yet run all the jlink tests. Unfortunately, I have to lay down the review work at this time; Sundar is taking over (thanks!!). I'm available for clarification matters. Best, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From michael.haupt at oracle.com Mon Mar 14 12:56:15 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Mon, 14 Mar 2016 13:56:15 +0100 Subject: jlink tool review (Re: Initial webrev with changes for JDK 9) In-Reply-To: References: <56D84C7D.9020006@oracle.com> Message-ID: <6B75DCA1-60D1-484A-9EEC-BA45F15BF46B@oracle.com> Hi again, some certain list server doesn't like attachments. ;-) Find it at http://cr.openjdk.java.net/~mhaupt/jigsaw/ Best, Michael > Am 14.03.2016 um 13:49 schrieb Michael Haupt : > > Alan, all, > > please find a patch with suggested changes to jlink in the attachment. The patch also contains a file named review-comments.txt, which addresses several topics throughout jlink. I've covered most code; only the jlink.internal package is still missing. I've been able to compile jake with these refactorings applied; I have not yet run all the jlink tests. > > Unfortunately, I have to lay down the review work at this time; Sundar is taking over (thanks!!). I'm available for clarification matters. > > Best, > > Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From alan.bateman at oracle.com Mon Mar 14 12:58:34 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 14 Mar 2016 12:58:34 +0000 Subject: hg: jigsaw/jake/langtools: API clean-up Message-ID: <201603141258.u2ECwYMZ020370@aojmv0008.oracle.com> Changeset: f93c2f68355b Author: alanb Date: 2016-03-14 12:21 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/f93c2f68355b API clean-up ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/ModuleWrappers.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleAnalyzer.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModulePaths.java ! test/tools/javac/T8003967/DetectMutableStaticFields.java From alan.bateman at oracle.com Mon Mar 14 12:58:44 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 14 Mar 2016 12:58:44 +0000 Subject: hg: jigsaw/jake/hotspot: API clean-up Message-ID: <201603141258.u2ECwirJ020433@aojmv0008.oracle.com> Changeset: 49edd41edc00 Author: alanb Date: 2016-03-14 12:22 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/49edd41edc00 API clean-up ! test/runtime/modules/AccessCheck/CheckRead.java ! test/runtime/modules/AccessCheck/DiffCL_CheckRead.java ! test/runtime/modules/AccessCheck/DiffCL_ExpQualOther.java ! test/runtime/modules/AccessCheck/DiffCL_ExpQualToM1.java ! test/runtime/modules/AccessCheck/DiffCL_ExpUnqual.java ! test/runtime/modules/AccessCheck/DiffCL_PkgNotExp.java ! test/runtime/modules/AccessCheck/DiffCL_Umod.java ! test/runtime/modules/AccessCheck/DiffCL_UmodUpkg.java ! test/runtime/modules/AccessCheck/ExpQualOther.java ! test/runtime/modules/AccessCheck/ExpQualToM1.java ! test/runtime/modules/AccessCheck/ExpUnqual.java ! test/runtime/modules/AccessCheck/ExportAllUnnamed.java ! test/runtime/modules/AccessCheck/PkgNotExp.java ! test/runtime/modules/AccessCheck/Umod.java ! test/runtime/modules/AccessCheck/UmodDiffCL_ExpQualOther.java ! test/runtime/modules/AccessCheck/UmodDiffCL_ExpUnqual.java ! test/runtime/modules/AccessCheck/UmodDiffCL_PkgNotExp.java ! test/runtime/modules/AccessCheck/UmodUPkg.java ! test/runtime/modules/AccessCheck/UmodUpkgDiffCL_ExpQualOther.java ! test/runtime/modules/AccessCheck/UmodUpkgDiffCL_NotExp.java ! test/runtime/modules/AccessCheck/UmodUpkg_ExpQualOther.java ! test/runtime/modules/AccessCheck/UmodUpkg_NotExp.java ! test/runtime/modules/AccessCheck/Umod_ExpQualOther.java ! test/runtime/modules/AccessCheck/Umod_ExpUnqual.java ! test/runtime/modules/AccessCheck/Umod_PkgNotExp.java ! test/runtime/modules/AccessCheck/p1/c1Loose.java From alan.bateman at oracle.com Mon Mar 14 12:58:57 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 14 Mar 2016 12:58:57 +0000 Subject: hg: jigsaw/jake/jdk: 3 new changesets Message-ID: <201603141258.u2ECwvOn020520@aojmv0008.oracle.com> Changeset: 3f8bb97a4b72 Author: alanb Date: 2016-03-14 12:09 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3f8bb97a4b72 Review comments ! src/java.base/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/java.base/share/classes/java/lang/module/ModuleInfo.java ! src/java.base/share/classes/java/lang/module/ModuleReader.java Changeset: d7a8866e470b Author: alanb Date: 2016-03-14 12:10 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d7a8866e470b Fix copyright header ! test/jdk/jigsaw/module/VersionTest.java Changeset: 7ce9360bfcb3 Author: alanb Date: 2016-03-14 12:58 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7ce9360bfcb3 API clean-up -addmods ALL-MODULE-PATH ! make/src/classes/build/tools/jigsaw/GenGraphs.java ! make/src/classes/build/tools/jigsaw/ModuleSummary.java ! src/java.base/share/classes/java/lang/NamedPackage.java ! src/java.base/share/classes/java/lang/System.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/ResolutionException.java + src/java.base/share/classes/java/lang/module/ResolvedModule.java ! src/java.base/share/classes/java/lang/module/Resolver.java ! src/java.base/share/classes/java/lang/reflect/Layer.java ! src/java.base/share/classes/java/lang/reflect/Module.java ! src/java.base/share/classes/java/util/ServiceLoader.java ! src/java.base/share/classes/jdk/internal/loader/BootLoader.java ! src/java.base/share/classes/jdk/internal/loader/Loader.java ! src/java.base/share/classes/jdk/internal/loader/LoaderPool.java ! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java ! src/java.base/share/classes/jdk/internal/module/ModuleLoaderMap.java ! src/java.base/share/classes/module-info.java ! src/java.base/share/classes/sun/launcher/resources/launcher.properties ! src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java ! src/java.instrument/share/classes/java/lang/instrument/package.html ! src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java ! test/java/lang/Class/forName/modules/TestLayer.java ! test/java/lang/Class/forName/modules/src/m3/p3/NoAccess.java ! test/java/lang/Class/getResource/Main.java ! test/java/lang/ClassLoader/getResource/modules/Main.java ! test/java/lang/invoke/AccessControlTest.java ! test/jdk/jigsaw/module/AutomaticModulesTest.java ! test/jdk/jigsaw/module/ConfigurationTest.java ! test/jdk/jigsaw/reflect/Layer/BasicLayerTest.java ! test/jdk/jigsaw/reflect/Layer/LayerAndLoadersTest.java ! test/jdk/jigsaw/reflect/Module/BasicModuleTest.java ! test/jdk/jigsaw/reflect/Proxy/ProxyClassAccessTest.java ! test/jdk/jigsaw/reflect/Proxy/ProxyLayerTest.java ! test/jdk/jigsaw/scenarios/automaticmodules/src/basictest/test/Main.java ! test/jdk/jigsaw/scenarios/container/src/container/container/Main.java ! test/jdk/jigsaw/util/ServiceLoader/ServicesTest.java From Alan.Bateman at oracle.com Mon Mar 14 13:35:22 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 14 Mar 2016 13:35:22 +0000 Subject: Unnamed module and duplicate package In-Reply-To: <56E667DD.6060700@redhat.com> References: <56E286EB.5000904@oracle.com> <56E2A12F.5020000@oracle.com> <56E2DB95.4010600@redhat.com> <56E2E2E9.2050307@oracle.com> <56E2E485.40403@redhat.com> <56E3D9FE.7040504@oracle.com> <56E667DD.6060700@redhat.com> Message-ID: <56E6BE1A.8040902@oracle.com> On 14/03/2016 07:27, David M. Lloyd wrote: > > So really there are multiple parts to be able to move modules out of > the bootstrap class loader: > > 1. Relax the spec so that other class loaders (preferably only > trusted/blessed class loaders) can define java.* classes This is part of the getPlatformClassLoader() patch that Mandy sent mail about a few days ago. As part of this, defineClass is relaxed so that it allows java.* classes to be defined to the platform class loader or any of its ancestors > > 2. Come up with a replacement for getClassLoader() == null checks > (e.g. getClassLoader() == null || getClassLoader().isPrivileged()) jdk.internal.VM.isSystemDomainLoader(ClassLoader) was introduced in JDK 8 for this purpose. > > 3. Then go back and incrementally deprivilege as many modules as > possible/practical, as time permits Easier said that done as it can take a lot of effort to identify the minimum permissions, test, measure performance, assess compatibility and the many other things that need to be done. > > However the benefits seem attractive: improved security (even if only > one module gets deprivileged), ability for core modules to depend on > upgradable modules (java.sql case). Yes, on security although some modules need to granted more permissions that we'd like. So far, we've moved all of the EE/upgradeable modules: java.activation java.annotations.common java.corba java.transaction java.xml.bind java.xml.ws and several service provider (jdk.*) modules have been moved too. I don't see core modules depending on upgradeable modules as a benefit. My personal view is that we should vehemently resist any move in that direction. No issue with core modules using service providers of course. -Alan From pbenedict at apache.org Mon Mar 14 14:56:55 2016 From: pbenedict at apache.org (Paul Benedict) Date: Mon, 14 Mar 2016 09:56:55 -0500 Subject: Relationship between JDK modules and EE modules Message-ID: In the future, is an application server meant to dynamically create a JDK module from an EE module (EAR, WAR, EJB JAR)? I am not asking anyone to define a specification; just curious how they are envisioned to interact. Cheers, Paul From harold.seigel at oracle.com Mon Mar 14 15:37:03 2016 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Mon, 14 Mar 2016 15:37:03 +0000 Subject: hg: jigsaw/jake/hotspot: Fix JDK-8151532 JVM Phase issue Message-ID: <201603141537.u2EFb3KR015688@aojmv0008.oracle.com> Changeset: f6165d13ad82 Author: sspitsyn Date: 2016-03-14 11:08 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f6165d13ad82 Fix JDK-8151532 JVM Phase issue ! src/share/vm/prims/jvmtiExport.cpp From pbenedict at apache.org Mon Mar 14 16:08:05 2016 From: pbenedict at apache.org (Paul Benedict) Date: Mon, 14 Mar 2016 11:08:05 -0500 Subject: Package, import and type declarations are allowed now in module-info.java by spec In-Reply-To: <56E09D62.3060507@oracle.com> References: <56D07F37.1030806@oracle.com> <56D098BB.5070200@oracle.com> <56E021CE.3050801@oracle.com> <56E09D62.3060507@oracle.com> Message-ID: Alex, you wrote: "The JLS doesn't prevent javac from rejecting a package declaration or an import declaration in a file called module-info.java." It seems that a package declaration, in this context, should be prohibited syntax because module-info.class is always in the JAR root which has no package. Cheers, Paul On Wed, Mar 9, 2016 at 4:02 PM, Alex Buckley wrote: > The JLS doesn't prevent javac from rejecting a package declaration or an > import declaration in a file called module-info.java. > > In fact, since a package declaration or import declaration must be > followed by a type declaration, and since a type declaration cannot use a > hyphen, javac is free to take the optional rule from JLS 7.6 -- filename > must align with type declaration -- and develop it further: rejecting a > package declaration or import declaration in module-info.java because the > filename cannot possibly align with any type declaration. > > I can't speak to what a particular EA build of javac is doing with a > particular option. javac options are irrelevant to the JLS. If a compiler > accepts the Java language circa SE 9, then a module declaration is a valid > compilation unit. What's the name of the file containing such a compilation > unit? Anything the compiler likes. > > Alex > > On 3/9/2016 5:14 AM, Georgiy Rakov wrote: > >> Hi Alex, >> >> if I understand correctly you mean about following assertions from JLS >> 7.6: >> >> If and only if packages are stored in a file system (?7.2 >> > >), >> the host system may choose to enforce the restriction that it is a >> compile-time error if a type is not found in a file under a name >> composed of the type name plus an extension (such as |.java|or >> |.jav|) if either of the following is true: >> >> * >> >> The type is referred to by code in other compilation units of >> the package in which the type is declared. >> >> * >> >> The type is declared |public|(and therefore is potentially >> accessible from code in other packages). >> >> Literally these assertion doesn't make presented behavior corresponding >> to spec because the declared type is neither public nor being referred >> to from other sources being compiled. >> >> Nevertheless following sources doesn't compile either despite the fact >> that no types are declared there at all. >> Namely when only package is specified: >> >> mod\module-info.java: >> module mod { >> exports pkg; >> } >> >> mod\pkg\module-info.java: >> package pkg; >> >> then compiling it by following command line with javac from [2]: >> >> javac -modulesourcepath . mod\module-info.java >> mod\pkg\module-info.java >> >> causes following output: >> >> mod\pkg\module-info.java:1: error: expected 'module >> package pkg; >> ^ >> 1 error >> >> When only import statment is specified: >> >> mod\module-info.java: >> module mod { >> exports pkg; >> } >> >> mod\pkg\module-info.java: >> import java.util.List; >> >> then compiling it by following command line with javac from [2]: >> >> javac -modulesourcepath . mod\module-info.java >> mod\pkg\module-info.java >> >> causes following output: >> >> mod\pkg\module-info.java:1: error: expected 'module' >> import java.util.List; >> ^ >> 1 error >> >> Please see minimized test cases attached in tests23.zip. In order to >> reproduce, please: >> >> 1. Unzip the attached archive to some dir on Windows machined, say >> directory A; >> 2. Rename A\test2\test_bat to A\test2\test.bat and A\test3\test_bat to >> A\test3\test.bat; >> 3. Modify these two test.bat files by changing JDK_HOME variable to >> point to your jigsaw JDK 9 installation directory; >> 4. Run test.bat files in turn. >> >> BTW: javac behavior [2] currently differs depending on whether sources >> are compiled "in module" mode or not. By "module mode" I mean specifying >> modulesourcepath option. For instance without modulesourcepath option >> module declarations are not recognized as valid grammar while import >> declarations contained within module-info.java compile successfully. >> This can be seen by experimenting with test3 from the attached >> testcases. Now javac from [2] even can throw exception in "non-module" >> mode, please see https://bugs.openjdk.java.net/browse/JDK-8150733. >> >> Could you please tell if spec will specify somehow two modes of >> processing java-sources, now it [1] doesn't. >> >> [1] http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html >> [2] >> >> http://download.java.net/java/jigsaw/archive/106/binaries/jigsaw-jdk-9-ea+106_windows-x86_bin.zip >> >> Thanks, >> Georgiy. >> >> On 26.02.2016 21:26, Alex Buckley wrote: >> >>> On 2/26/2016 8:37 AM, Georgiy Rakov wrote: >>> >>>> current spec [1] now contains following assertions related to grammar: >>>> >>>> A compilation unit (JLS 7.3) may contain a module declaration, in >>>> which case the filename of the compilation unit is typically >>>> |module-info.java|. >>>> >>>> CompilationUnit: >>>> [PackageDeclaration] {ImportDeclaration} {TypeDeclaration} >>>> ModuleDeclaration >>>> >>>> These assertions allows to specify any of import, package or type >>>> declarations in any compilation unit, for instance module-info.java is >>>> allowed to contain any of the mentioned declarations. However currently >>>> javac in the latest jigsaw build [2] reports an error on such cases >>>> provided they are compiled in module mode. For example if we have >>>> following directory structure: >>>> >>>> mod\module-info.java: >>>> module mod { >>>> exports pkg; >>>> } >>>> >>>> mod\pkg\module-info.java: >>>> package pkg; >>>> >>>> class C { >>>> } >>>> >>>> then compiling it by following command line with javac from [2]: >>>> >>>> javac -modulesourcepath . mod\module-info.java >>>> mod\pkg\module-info.java >>>> >>>> causes following output: >>>> >>>> mod\pkg\module-info.java:1: error: expected 'module' >>>> package pkg; >>>> ^ >>>> 1 error >>>> >>> >>> javac is merely choosing to implement the rule at the end of JLS 7.6 >>> that a type declaration (optionally preceded by package/import >>> declarations) must be provided in a suitably named file. >>> >>> Perhaps I should say "a variant of the rule" because 7.6 as written >>> concerns a public type and your example has a package-access type. >>> Still, bottom line, javac is free to require that a compilation unit >>> which starts with a package declaration _must not_ be in a file called >>> foo-bar.java -- the hyphen indicates a name that can't possibly align >>> with the type declared in the compilation unit. >>> >>> The error message for mod\pkg\module-info.java could be a bit more >>> helpful, but that's a quality-of-implementation detail. >>> >>> Conversely, a compilation unit that contains a module declaration >>> _may_ be in a file called module-info.java, or in a file called >>> foo-bar.java, or in a file called mod_decl.JAV. The "typically" in [1] >>> is meant to indicate that the sub-clause on filename is non-normative. >>> This is akin to how a compilation unit that contains a package-access >>> type declaration for class C _may_ be in a file D.java. >>> >>> Alex >>> >> >> From james.laskey at oracle.com Mon Mar 14 16:28:09 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Mon, 14 Mar 2016 13:28:09 -0300 Subject: Initial webrev with changes for JDK 9 - jimage In-Reply-To: References: <56D84C7D.9020006@oracle.com> <56DF14EE.1050102@Oracle.com> Message-ID: <21098E6E-44A5-462C-8B15-217E0C2C51A3@oracle.com> These are the changes I plan on submitting for M3. http://cr.openjdk.java.net/~jlaskey/jimagereview/webrev/index.html I?ve filed the following bugs as follow up. https://bugs.openjdk.java.net/browse/JDK-8151806 JImage decompress code needs to be revised to be more effective https://bugs.openjdk.java.net/browse/JDK-8151807 ImageBufferCache should use sun.nio.ch.Util ? Jim > On Mar 10, 2016, at 7:22 PM, Jim Laskey (Oracle) wrote: > > Thank you Roger. Comments inline. In general, I will hold off changes until after merge so as not to destabilize. Note that ImageBufferCache and Decompression are not currently used. > >> On Mar 8, 2016, at 2:07 PM, Roger Riggs wrote: >> >> Hi, >> >> Review comments for the jimage code in java.base, mostly cleanup but perhaps a bug or two. >> General: inconsistent style and not following guidelines, copyright dates may need an update. >> Use of assert for error checking is not going to catch or help isolate errors in production builds. > > Noted. > >> >> dir: jdk/src/java.base/share/classes/jdk/internal/jimage/ >> >> >> BasicImageReader: >> - readHeader() exception message should say not a jimage or wrong version >> Other IOExceptions can occur if the file is corrupted or is too small, array index out of bounds, etc. > > Replaced with specific exceptions. > >> >> - findLocation() should use a more explicit computation for the redirection >> than rehashing; this would allow the hash seed to be encapsulated. > > As part of the review change set, I've documented the Minimal Perfect Hash Method (see PerfectHashBuilder.) The algorithm requires a one time one rehash when there is a collision. A new seed forces a different distribution of the colliding strings. If you started with the existing hashCode, you would not get a new distribution, merely a shift of all the colliding elements. Random distribution is the essence of algorithm. > >> >> - slice() synchronizes on the ByteBuffer; does every other access? > > Byte buffer use here is immutable, however slicing of the ByteBuffer does require modifying position and limit. Wrapping or cloning the buffers would be of little benefit and would take a performance hit. The ByteBuffer API might have been well served with an atomic non-modifying slice operation. > >> >> - getAllLocations() is unused and does not respect its sorted argument; >> Best to remove the method for now. > > Removed. > >> >> - getResourceBuffer(): unused - remove > > Removed. > >> >> - getResourceStream(): unused - remove > > Removed. > >> >> ImageStringsReader: >> >> - Is Modified UTF-8 really needed here; using normal UTF-8 would allow >> re-use and better performance. Alternatively, Modified UTF-8 should be >> added as a supported encoding. > > Modified UTF-8 is used to be more compact and to simplify use in native code. The jimage string table has overlapping use with constant pool compaction so is really an older revision of the Modified UTF-8 standard. Not sure why Modifed UTF-8 is not offered as an encoding. It would have made constant pool management easier. And note that relying on a particular encoding is problematic. Encoding standards do change, affecting the stability of the hash algorithm and may prevent the reading of older jimage files. > >> >> - The ImageStringsReader.hashCode() should be defined so it can take advantage of 32 or 64 bit accesses; since it is used frequently. And it needs to be stable across revisions that may be accessing jimages from different JDK versions. >> > > Reasonable and will consider. Not sure what you mean by stable across revisions. This is not string hashCode. This is a hashCode that is specific to MPHM and is deterministic. > >> - stringFromMUTF8(byte[]) - there may be some optimization to avoid expanding ascii to chars and then re-encoding in String. > > Will touch base with the Aleksey. > >> >> - charsFromByteBufferLength/charsFromByteBuffer should throw an exception if no terminating null, not just when assertions are enabled > > Will throw InternalError instead. > >> >> - inconsistent assert errors vs exceptions for malformed mutf8. >> Use of assert will not detect errors in production builds > > Will throw InternalError instead. > >> >> - mutf8FromChars allocates a new working buffer (byte[8]) potentially for every UNICODE char. > > Will hoist the buffer allocation and reuse. > >> >> - mutf8FromString: should take advantage of new String(bytes, offset, length, charsetName) to avoid extra allocations. >> (would need a Modified utf-8 charset). > > Modified UTF-8 not available. > >> >> - hashCode(byte[0, seed) should be private; the hashcode algorithm should not be variable. >> > > This is not String hashCode. see above. > >> ImageLocation: >> - Merge ImageLocation functions into ImageLocationBase and rename. >> ImageLocation does not have enough unique functionality to be a separate class. > > Merged. > >> >> - It is a poor design to create an instance that may not be valid. >> It would be better to have an ImageLocation factory method that encapsulated the creation and checking >> > > Noted. > >> >> ImageLocationBase: >> - Failing asserts will not cause a runtime error in production. >> But will degenerate into unpredictable other exceptions > > Will throw InternalError instead. > >> >> ImageStream: >> - compress(): Too heavyweight an object to be used and discarded just for compress / decompress of small values. > > compress()? I don?t see ImageStream used anywhere except for large buffers. As a note, dynamic ByteBuffers really should be part of the JDK. > >> >> >> ImageBufferCache: >> - Comments on each method would make the intent clear > > Will add comments. > >> >> - getBuffer: mixing for loop and explicit indexes is fragile >> - releaseBuffer: check buffer.capacity before threadLocal.get() for early return >> - Logic of i,j is flawed, i is never changed; j is/becomes 0 >> The first buffer is removed if there are more than max >> Its not clear what algorithm was intended. >> A buffer that is in use can be removed. > > Rewrote using lambdas to clarify the algorithm. > >> >> - ImageBufferCache constructor: the isUsed flag should be set in getBuffer() >> when it is added to the list (not in the constructor) >> It keeps it consistent with when it is set for a re-used buffer. >> > > Modified. > >> ImageHeader: >> - BADMAGIC is not used > > Removed. > >> >> - readFrom could throw BufferUnderflowException - undocumented > > get(i) can IndexOutOfBoundsException [and get() BufferUnderflowException] Will add explicit check. > > >> >> ImageModuleData: >> - ImageModuleData seems to be unused; allModuleNames() is unreferenced >> > > Removed. > >> >> ImageReader: >> - ImageReader(path): unused - remove > > Removed. > >> >> - Use of assert is non-reassuring, ineffective in production builds > > Added explicit check. > >> >> - In a long running application the per thread buffers will get to the point wehere they are unused and should be released. >> There is no support for soft or weak references to handle that case. >> Alternatively, if the buffers were not per thread then they would have a lesser impact. > > The core libs team was concerned about the performance of class loading. The pattern used here is the one followed by NIO. We will probably come up with a shared NIO cache at some point. > >> Also, why should there be more than one buffer per thread? > > The image cache is only used by 32 bit systems and decompression. It is possible for a channel read buffer and a decompression buffer to be allocated at the same time. > >> >> ImageReader.Resource: >> - unused create method > > Removed. > >> >> - unused parent argument (0) in Resource constructor (dir, loc, attr) > > Removed. > >> >> ImageReader.LinkNode: >> - constructor has unused parent arg >> >> > > Removed > >> decompress/CompressIndexes: >> - readInt: wasteful allocation of a single byte array and then another small byte array; >> and then another heap buffer allocation in the ByteBuffer. > > Removed all allocation. > >> >> - decompress is hugely wasteful of allocations of ByteBuffers of small sizes. >> > > Removed all allocation. > > >> decompress/CompressedResourceHeader: >> - MAGIC does not need to be public >> >> >> decompress/Decompressor: >> - IOException "Plugin name not found" should include the missing name >> >> - StringsProvider is an unnecessary interface; could use Supplier >> >> - Redundant public modifiers in interface declarations >> >> decompress/SignatureParser: >> - Comments describing the input and output formats needed >> >> - style around operators does not consistently include spaces; and "if("... >> >> decompress/StringSharingDecompressor: >> - Wasteful use of ByteBuffers and small arrays without re-use (safeAdd...) >> >> - StringSharingDecompressor constructor with unused argument - remove >> >> >> decompress/ZipDecompressor: >> - Should be more specific about the zip algorithms supported >> since it needs to be stable across releases >> >> - decompress(): use try-with-resources for safer inflation >> > > I think decompression needs significant reworking.. > >> src/java.base/share/native/libjimage/imageDecompressor.cpp >> - "// If ptr is not aligned, sparc will fail." implies input argument must be aligned >> >> - General doubt about using assert; for example to check on malloc allocation failure >> >> - In production environment will exhibit as segv >> > > Noted. From alan.bateman at oracle.com Mon Mar 14 16:33:25 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 14 Mar 2016 16:33:25 +0000 Subject: hg: jigsaw/jake/jdk: Fix a few typos in javadoc Message-ID: <201603141633.u2EGXPxo005730@aojmv0008.oracle.com> Changeset: 7081e2446f43 Author: alanb Date: 2016-03-14 16:33 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7081e2446f43 Fix a few typos in javadoc ! src/java.base/share/classes/java/lang/module/Configuration.java ! src/java.base/share/classes/java/lang/module/ModuleFinder.java From Alan.Bateman at oracle.com Mon Mar 14 16:38:44 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 14 Mar 2016 16:38:44 +0000 Subject: Relationship between JDK modules and EE modules In-Reply-To: References: Message-ID: <56E6E914.2010108@oracle.com> On 14/03/2016 14:56, Paul Benedict wrote: > In the future, is an application server meant to dynamically create a JDK > module from an EE module (EAR, WAR, EJB JAR)? I am not asking anyone to > define a specification; just curious how they are envisioned to interact. > I would assume, that in time, EE will define something like modular WAR or EAR. It might be that there are several modules in the same archive. At run-time then the app server will use the API to create a configuration (essentially the graph of modules for the application) and then instantiate it in the run-time as a module Layer. The app server creating the configuration would provide a ModuleFinder that knows about WARs and EARs, it also gets to control the modules that are overridden, say where a web app uses a different version of a JAX-* API to what the container/app server ships with. -Alan. From mandy.chung at oracle.com Mon Mar 14 16:42:06 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Mon, 14 Mar 2016 16:42:06 +0000 Subject: hg: jigsaw/jake/jdk: 2 new changesets Message-ID: <201603141642.u2EGg7xe008812@aojmv0008.oracle.com> Changeset: 3cf8c366ce88 Author: naoto Date: 2016-03-11 14:37 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3cf8c366ce88 jlink --include-locales plugin ! make/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/IncludeLocalesPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/InstalledModuleDescriptorPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties ! src/jdk.jlink/share/classes/module-info.java ! test/jdk/jigsaw/tools/jlink/JLinkTest.java + test/jdk/jigsaw/tools/jlink/plugins/GetAvailableLocales.java + test/jdk/jigsaw/tools/jlink/plugins/IncludeLocalesPluginTest.java Changeset: d0e6bde710b0 Author: mchung Date: 2016-03-14 09:42 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d0e6bde710b0 Merge From mandy.chung at oracle.com Mon Mar 14 17:43:47 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Mon, 14 Mar 2016 17:43:47 +0000 Subject: hg: jigsaw/jake/hotspot: Rename extension class loader to platform class loader Message-ID: <201603141743.u2EHhlMP001102@aojmv0008.oracle.com> Changeset: 3c73a6ce4fc9 Author: mchung Date: 2016-03-14 10:42 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3c73a6ce4fc9 Rename extension class loader to platform class loader ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoader.hpp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/method.cpp From mandy.chung at oracle.com Mon Mar 14 17:44:03 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Mon, 14 Mar 2016 17:44:03 +0000 Subject: hg: jigsaw/jake/jdk: Rename extension class loader to platform class loader Message-ID: <201603141744.u2EHi3cp001317@aojmv0008.oracle.com> Changeset: e97320e9c0ef Author: mchung Date: 2016-03-14 10:42 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e97320e9c0ef Rename extension class loader to platform class loader ! make/gensrc/GensrcModuleLoaderMap.gmk ! make/src/classes/build/tools/module/GenModuleLoaderMap.java ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java ! src/java.base/share/classes/jdk/internal/loader/ClassLoaders.java ! src/java.base/share/classes/jdk/internal/loader/Loader.java - src/java.base/share/classes/jdk/internal/module/ModuleLoaderMap.dat ! src/java.base/share/classes/jdk/internal/module/ModuleLoaderMap.java + src/java.base/share/classes/jdk/internal/vm/cds/resources/ModuleLoaderMap.dat ! src/java.base/share/classes/sun/reflect/Reflection.java ! test/com/sun/jdi/ModulesTest.java ! test/jdk/jigsaw/launcher/patch/PatchTest.java ! test/jdk/jigsaw/launcher/upgrademodulepath/src/test/jdk/test/Main.java From philip.race at oracle.com Mon Mar 14 19:37:39 2016 From: philip.race at oracle.com (Phil Race) Date: Mon, 14 Mar 2016 12:37:39 -0700 Subject: Initial webrev with changes for JDK 9 In-Reply-To: <56E29267.7070501@oracle.com> References: <56E29267.7070501@oracle.com> Message-ID: <56E71303.5020009@oracle.com> http://cr.openjdk.java.net/~alanb/8142968/2/jdk/test/java/awt/patchlib/java.desktop/java/awt/Helper.java.html 30 //java.awt.Helper.class.getModule().addExports(pn, target); Can we remove the commented out line ? http://cr.openjdk.java.net/~alanb/8142968/2/jdk/src/java.desktop/macosx/classes/com/apple/laf/AquaUtils.java.sdiff.html 368 // can we use ClassLoader.getSystemClassLoader here? 369 final ClassLoader launcherClassLoader = ClassLoaders.appClassLoader(); I suspect yes, although it doesn't really matter and maybe this workaround method is not needed any more but that is for another day. http://cr.openjdk.java.net/~alanb/8142968/2/jdk/src/java.desktop/share/classes/java/awt/color/ICC_Profile.java.sdiff.html This edit seems to be associated with the following change :- changeset: 13355:df27ca47fd34 user: alanb date: Sun Jul 12 21:24:44 2015 +0100 summary: ICC_Profile.standardProfileExists doesn't close stream This bug would affected mainline so why was this change not fixed there ? I'm curious how it was found since there is no bug report mentioned. Also I wonder if we really have to have to open a stream to test existence ? http://cr.openjdk.java.net/~alanb/8142968/2/jdk/src/java.desktop/share/classes/javax/swing/text/DefaultFormatter.java.sdiff.html < 34 import javax.swing.text.*; http://cr.openjdk.java.net/~alanb/8142968/2/jdk/src/java.desktop/share/classes/javax/swing/text/html/ObjectView.java.sdiff.html < 27 import java.util.Enumeration; http://cr.openjdk.java.net/~alanb/8142968/2/jdk/src/java.desktop/share/classes/sun/applet/AppletSecurity.java.sdiff.html < 46 import sun.security.provider.*; Not sure why deleting a few unused imports needed to be part of this change. It would have been less odd were it not the only change in these source files. http://cr.openjdk.java.net/~alanb/8142968/2/jdk/src/java.desktop/share/classes/sun/print/ServiceDialog.java.sdiff.html Why were these changes made in jake ? I thought the policy was to make all changes in mainline unless they could only be made in jake ? Also I 1) don't see where/how the stream is closed 2) The doPrivileged at line 2823 no longer seems likely to be necessary. Looking over the client related tests (or at least as many of them as I noticed) I am curious why this one :- http://cr.openjdk.java.net/~alanb/8142968/2/jdk/test/java/awt/xembed/server/TesterClient.java.sdiff.html uses 35 cl.getModule().addExports("sun.awt.X11",TesterClient.class.getModule()); Instead ofjava.awt.Helper.addExports(..) http://cr.openjdk.java.net/~alanb/8142968/2/jdk/test/java/awt/Toolkit/Headless/WrappedToolkitTest/WrappedToolkitTest.sh.sdiff.html Why was the "@" removed from this line :- 31 # compile TestWrapped.java 31 # compile TestWrapped.java http://cr.openjdk.java.net/~alanb/8142968/2/jdk/test/java/awt/Mixing/AWT_Mixing /OverlappingTestBase.java.sdiff.html Why were lines 111&112 commented out but not lines 114 ? -phil. On 03/11/2016 01:39 AM, Alan Bateman wrote: > > I've refreshed the webrevs here: > http://cr.openjdk.java.net/~alanb/8142968/2 > > so that we have a snapshot of what is currently in the jigsaw/jake > forest. The webrevs are against jdk-9+109. > > As I said in the last mail, we would like to integrate this snapshot > into JDK 9 before the end of March. The proposal is to aim to > integrate during the week of March 21, with the the week of March 28 > as fallback in event of problems. > > The related JEPs (JEP 200, JEP 260, JEP 261 and JEP 282) are now in > "Proposed to Target" state. Mark send mail to jdk9-dev with this list > and other proposals yesterday. > > -Alan From jan.lahoda at oracle.com Mon Mar 14 19:56:17 2016 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Mon, 14 Mar 2016 19:56:17 +0000 Subject: hg: jigsaw/jake/langtools: Introducing -addmods ALL-MODULE-PATH, supporting -addmods ALL-SYSTEM; disallowing -addmods/-limitmods with -target <= 8. Message-ID: <201603141956.u2EJuH1o023618@aojmv0008.oracle.com> Changeset: fe889e047657 Author: jlahoda Date: 2016-03-14 20:55 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/fe889e047657 Introducing -addmods ALL-MODULE-PATH, supporting -addmods ALL-SYSTEM; disallowing -addmods/-limitmods with -target <= 8. ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Arguments.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/modules/AddLimitMods.java From xueming.shen at oracle.com Mon Mar 14 19:50:10 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 14 Mar 2016 12:50:10 -0700 Subject: Initial webrev with changes for JDK 9 In-Reply-To: <56E71303.5020009@oracle.com> References: <56E29267.7070501@oracle.com> <56E71303.5020009@oracle.com> Message-ID: <56E715F2.1010203@oracle.com> jar.Main: comments (1) InputstreamSupplier: since what we really need here is the byte[], maybe just go straightforward to use InputStream/Files.(path)readAllBytes() ? (2) #273 don't the "moduleInfo" used for consistency check the same one as the used for updating at #244? can't be shared? (3) if it was me I would simply have passed the "moduleInfoBytes" around as a byte[], we might not even need this "InputStreamSupplier" interface. (4) printModuleDescriptor: for a "file" jar, it might be much faster to open the zip file with a ZipFile, then entry -> input stream. otherwise, the ZIS might be very slow if it's a big jar and the descriptor file is at the end of the file. (5) hashDependences: "matcher" can be reused as Matcher m = dependenciesToHash.matcher(""); for (...) { m.reset(...).find() ... } btw, what's the spec of the "mach" here? a "match()" or a "find()"? just check. -sherman From jan.lahoda at oracle.com Mon Mar 14 19:58:25 2016 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Mon, 14 Mar 2016 19:58:25 +0000 Subject: hg: jigsaw/jake/langtools: DocTrees.getElement shouldn't crash on an invalid package#member reference. Message-ID: <201603141958.u2EJwPXE024558@aojmv0008.oracle.com> Changeset: 6cacf96c868b Author: jlahoda Date: 2016-03-14 20:58 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/6cacf96c868b DocTrees.getElement shouldn't crash on an invalid package#member reference. ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java ! test/tools/javac/doctree/ReferenceTest.java From james.laskey at oracle.com Mon Mar 14 20:08:22 2016 From: james.laskey at oracle.com (james.laskey at oracle.com) Date: Mon, 14 Mar 2016 20:08:22 +0000 Subject: hg: jigsaw/jake/jdk: M3 jdk8-dev review changes. Message-ID: <201603142008.u2EK8MaM028443@aojmv0008.oracle.com> Changeset: 3067409f5ab9 Author: jlaskey Date: 2016-03-14 16:53 -0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3067409f5ab9 M3 jdk8-dev review changes. ! src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java ! src/java.base/share/classes/jdk/internal/jimage/ImageBufferCache.java ! src/java.base/share/classes/jdk/internal/jimage/ImageHeader.java ! src/java.base/share/classes/jdk/internal/jimage/ImageLocation.java - src/java.base/share/classes/jdk/internal/jimage/ImageLocationBase.java - src/java.base/share/classes/jdk/internal/jimage/ImageModuleData.java ! src/java.base/share/classes/jdk/internal/jimage/ImageReader.java ! src/java.base/share/classes/jdk/internal/jimage/ImageReaderFactory.java ! src/java.base/share/classes/jdk/internal/jimage/ImageStream.java ! src/java.base/share/classes/jdk/internal/jimage/ImageStrings.java ! src/java.base/share/classes/jdk/internal/jimage/ImageStringsReader.java ! src/java.base/share/classes/jdk/internal/jimage/NativeImageBuffer.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/CompressIndexes.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/CompressedResourceHeader.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/Decompressor.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/ResourceDecompressor.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/ResourceDecompressorFactory.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/ResourceDecompressorRepository.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/SignatureParser.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/StringSharingDecompressor.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/StringSharingDecompressorFactory.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/ZipDecompressor.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/ZipDecompressorFactory.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageLocationWriter.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/PerfectHashBuilder.java From Alan.Bateman at oracle.com Mon Mar 14 20:09:19 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 14 Mar 2016 20:09:19 +0000 Subject: Initial webrev with changes for JDK 9 In-Reply-To: <56E71303.5020009@oracle.com> References: <56E29267.7070501@oracle.com> <56E71303.5020009@oracle.com> Message-ID: <56E71A6F.3040508@oracle.com> On 14/03/2016 19:37, Phil Race wrote: > : > > http://cr.openjdk.java.net/~alanb/8142968/2/jdk/src/java.desktop/macosx/classes/com/apple/laf/AquaUtils.java.sdiff.html > > > 368 // can we use ClassLoader.getSystemClassLoader here? > 369 final ClassLoader launcherClassLoader = > ClassLoaders.appClassLoader(); > > I suspect yes, although it doesn't really matter and maybe this > workaround method > is not needed any more but that is for another day. Right, although we haven't really changed anything here. I assume the check for com.installshield.wizard.platform.macosx.MacOSXUtils is something that came from Apple originally. > > > http://cr.openjdk.java.net/~alanb/8142968/2/jdk/src/java.desktop/share/classes/java/awt/color/ICC_Profile.java.sdiff.html > > > : > > This bug would affected mainline so why was this change not fixed there ? > I'm curious how it was found since there is no bug report mentioned. > Also I wonder if we really have to have to open a stream to test > existence ? I think we can revert this. There was a time where it wasn't possible to get a URL to a resource. > : > > Not sure why deleting a few unused imports needed to be part of this > change. We had to remove several unused imports in places where it attempted to import types from non-exported packages or from modules that are declared as a dependency. > : > > http://cr.openjdk.java.net/~alanb/8142968/2/jdk/src/java.desktop/share/classes/sun/print/ServiceDialog.java.sdiff.html > > > Why were these changes made in jake ? I thought the policy was to make > all changes in mainline unless they could only be made in jake ? This is also related to URL to resources, I think we can revert this one too. > > Also I > 1) don't see where/how the stream is closed > 2) The doPrivileged at line 2823 no longer seems likely to be necessary. BTW: try (in) { .. } will ensure that the input stream is closed. Also the doPrivileged is needed as there may be user code on the stack. I'll leave it to Yuri for the AWT tests as I think he contributed all the changes to the tests. -Alan. From mandy.chung at oracle.com Mon Mar 14 20:37:11 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 14 Mar 2016 13:37:11 -0700 Subject: Initial webrev with changes for JDK 9 In-Reply-To: <56E29267.7070501@oracle.com> References: <56E29267.7070501@oracle.com> Message-ID: <45A05D29-1062-437A-9DE3-CCE14599352A@oracle.com> > On Mar 11, 2016, at 1:39 AM, Alan Bateman wrote: > > > I've refreshed the webrevs here: > http://cr.openjdk.java.net/~alanb/8142968/2 I have reviewed the jmod tool and some comments: 299 private boolean printModuleDescriptor(InputStream in) jmod -p option prints the output in different sections. java -listmods: prints the module descriptor closer to module-info.java declaration. Also jmod -p does not do any sorting and names are unordered. It would be better for both options to use similar format. I think closer to how it is declared in module-info.java would be preferred. The optional attributes will follow it - the existing format is fine. It?d help if the package names and uses are printed in alphabetical order. 584 } catch (ZipException x) { 585 // Skip. Do nothing. No packages will be added When ZipException is thrown? Should it be handled in the same way as IOException? 603 .filter(pkg -> pkg.length() > 0) // module-info I think jmod should detect if there is any unnamed package and output an error since unnamed package is not allowed in named module. Currently any classes in unnamed package are include in the jmod file. findPackages should filter module-info.class explicitly. 396 Path tempTarget = target.resolveSibling(target.getFileName() + ".tmp?); When any error occurs, foo.mod.tmp is left behind. jmods.properties - some unused messages. err.cp.must.be.specified:--class-path must be specified err.dir.not.empty=not empty: {0} err.invalid.arg.for.option=invalid argument for option: {0} err.option.after.class=option must be specified before classes: {0} Mandy From pbenedict at apache.org Mon Mar 14 21:13:09 2016 From: pbenedict at apache.org (Paul Benedict) Date: Mon, 14 Mar 2016 16:13:09 -0500 Subject: Support for multiple modules in one JAR-File Message-ID: Stefan, I am curious about your suggestion. Truthfully, I am not a fan of making the JAR structure more complex; I think the 1:1 relationship between physical artifact and module is easy and clean. However, I do wonder if your suggestion can be met by the JMOD format? I think that format has as one of its requirements the ability to bundle multiple resources together. If that's the case, I see that as an easier avenue than adding complexity to the JAR. Cheers, Paul From chris.hegarty at oracle.com Mon Mar 14 21:21:36 2016 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 14 Mar 2016 21:21:36 +0000 Subject: hg: jigsaw/jake/jdk: Update jmod tool options and subcommands as per JEP 261 Message-ID: <201603142121.u2ELLaqN023681@aojmv0008.oracle.com> Changeset: f57c9999dcac Author: chegar Date: 2016-03-14 21:19 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f57c9999dcac Update jmod tool options and subcommands as per JEP 261 ! src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java ! src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod.properties ! test/jdk/jigsaw/launcher/basic/BasicTest.java ! test/jdk/jigsaw/module/ModuleReader/ModuleReaderTest.java ! test/jdk/jigsaw/tools/jlink/basic/BasicTest.java ! test/jdk/jigsaw/tools/jmod/JmodNegativeTest.java ! test/jdk/jigsaw/tools/jmod/JmodTest.java ! test/jdk/jigsaw/tools/lib/tests/JImageGenerator.java ! test/tools/jar/compat/CLICompatibility.java From chris.hegarty at oracle.com Mon Mar 14 21:33:02 2016 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 14 Mar 2016 21:33:02 +0000 Subject: hg: jigsaw/jake: Update jmod tool options and subcommands as per JEP 261 Message-ID: <201603142133.u2ELX2VF027576@aojmv0008.oracle.com> Changeset: aee43f8fb92a Author: chegar Date: 2016-03-14 21:32 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/aee43f8fb92a Update jmod tool options and subcommands as per JEP 261 ! make/CreateJmods.gmk From jonathan.gibbons at oracle.com Mon Mar 14 21:42:21 2016 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 14 Mar 2016 21:42:21 +0000 Subject: hg: jigsaw/jake/langtools: improve javac -X output Message-ID: <201603142142.u2ELgL8b000618@aojmv0008.oracle.com> Changeset: ed65135d4cd4 Author: jjg Date: 2016-03-14 14:42 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/ed65135d4cd4 improve javac -X output ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties From mandy.chung at oracle.com Mon Mar 14 21:47:41 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Mon, 14 Mar 2016 21:47:41 +0000 Subject: hg: jigsaw/jake/jdk: Rename --plugins-modulepath to --plugin-module-path Message-ID: <201603142147.u2ELlfnQ002655@aojmv0008.oracle.com> Changeset: e5bda5dfed8c Author: mchung Date: 2016-03-14 14:47 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e5bda5dfed8c Rename --plugins-modulepath to --plugin-module-path ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties From jonathan.gibbons at oracle.com Mon Mar 14 21:56:56 2016 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 14 Mar 2016 21:56:56 +0000 Subject: hg: jigsaw/jake/langtools: remove obsolete dependence on java.lagging Message-ID: <201603142156.u2ELuuPR005786@aojmv0008.oracle.com> Changeset: 46bf8a56f516 Author: jjg Date: 2016-03-14 14:56 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/46bf8a56f516 remove obsolete dependence on java.lagging ! src/java.compiler/share/classes/module-info.java From jonathan.gibbons at oracle.com Mon Mar 14 22:13:00 2016 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 14 Mar 2016 22:13:00 +0000 Subject: hg: jigsaw/jake/langtools: remove temporary copy of old option Message-ID: <201603142213.u2EMD0GY011225@aojmv0008.oracle.com> Changeset: afbcbbe35fe7 Author: jjg Date: 2016-03-14 15:12 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/afbcbbe35fe7 remove temporary copy of old option ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java From alex.buckley at oracle.com Mon Mar 14 22:21:14 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 14 Mar 2016 15:21:14 -0700 Subject: Package, import and type declarations are allowed now in module-info.java by spec In-Reply-To: References: <56D07F37.1030806@oracle.com> <56D098BB.5070200@oracle.com> <56E021CE.3050801@oracle.com> <56E09D62.3060507@oracle.com> Message-ID: <56E7395A.4000202@oracle.com> The JLS doesn't know what the string "module-info.class" means or what a "JAR root" is. It only knows about Unicode input matching the CompilationUnit production. Nothing is mandated about the filesystem layout of files containing CompilationUnit productions that include a PackageDeclaration. For clarity, we could extend 7.6's compiler guidance to cover a file called module-info.java, but technically the guidance is already broad enough to allow a compiler to "do the right thing". Alex On 3/14/2016 9:08 AM, Paul Benedict wrote: > Alex, you wrote: "The JLS doesn't prevent javac from rejecting a package > declaration or an import declaration in a file called module-info.java." > > It seems that a package declaration, in this context, should be > prohibited syntax because module-info.class is always in the JAR root > which has no package. > > Cheers, > Paul > > On Wed, Mar 9, 2016 at 4:02 PM, Alex Buckley > wrote: > > The JLS doesn't prevent javac from rejecting a package declaration > or an import declaration in a file called module-info.java. > > In fact, since a package declaration or import declaration must be > followed by a type declaration, and since a type declaration cannot > use a hyphen, javac is free to take the optional rule from JLS 7.6 > -- filename must align with type declaration -- and develop it > further: rejecting a package declaration or import declaration in > module-info.java because the filename cannot possibly align with any > type declaration. > > I can't speak to what a particular EA build of javac is doing with a > particular option. javac options are irrelevant to the JLS. If a > compiler accepts the Java language circa SE 9, then a module > declaration is a valid compilation unit. What's the name of the file > containing such a compilation unit? Anything the compiler likes. > > Alex > > On 3/9/2016 5:14 AM, Georgiy Rakov wrote: > > Hi Alex, > > if I understand correctly you mean about following assertions > from JLS 7.6: > > If and only if packages are stored in a file system (?7.2 > > ), > the host system may choose to enforce the restriction that > it is a > compile-time error if a type is not found in a file under a > name > composed of the type name plus an extension (such as |.java|or > |.jav|) if either of the following is true: > > * > > The type is referred to by code in other compilation > units of > the package in which the type is declared. > > * > > The type is declared |public|(and therefore is potentially > accessible from code in other packages). > > Literally these assertion doesn't make presented behavior > corresponding > to spec because the declared type is neither public nor being > referred > to from other sources being compiled. > > Nevertheless following sources doesn't compile either despite > the fact > that no types are declared there at all. > Namely when only package is specified: > > mod\module-info.java: > module mod { > exports pkg; > } > > mod\pkg\module-info.java: > package pkg; > > then compiling it by following command line with javac from [2]: > > javac -modulesourcepath . mod\module-info.java > mod\pkg\module-info.java > > causes following output: > > mod\pkg\module-info.java:1: error: expected 'module > package pkg; > ^ > 1 error > > When only import statment is specified: > > mod\module-info.java: > module mod { > exports pkg; > } > > mod\pkg\module-info.java: > import java.util.List; > > then compiling it by following command line with javac from [2]: > > javac -modulesourcepath . mod\module-info.java > mod\pkg\module-info.java > > causes following output: > > mod\pkg\module-info.java:1: error: expected 'module' > import java.util.List; > ^ > 1 error > > Please see minimized test cases attached in tests23.zip. In order to > reproduce, please: > > 1. Unzip the attached archive to some dir on Windows machined, say > directory A; > 2. Rename A\test2\test_bat to A\test2\test.bat and > A\test3\test_bat to > A\test3\test.bat; > 3. Modify these two test.bat files by changing JDK_HOME variable to > point to your jigsaw JDK 9 installation directory; > 4. Run test.bat files in turn. > > BTW: javac behavior [2] currently differs depending on whether > sources > are compiled "in module" mode or not. By "module mode" I mean > specifying > modulesourcepath option. For instance without modulesourcepath > option > module declarations are not recognized as valid grammar while import > declarations contained within module-info.java compile successfully. > This can be seen by experimenting with test3 from the attached > testcases. Now javac from [2] even can throw exception in > "non-module" > mode, please see https://bugs.openjdk.java.net/browse/JDK-8150733. > > Could you please tell if spec will specify somehow two modes of > processing java-sources, now it [1] doesn't. > > [1] http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html > [2] > http://download.java.net/java/jigsaw/archive/106/binaries/jigsaw-jdk-9-ea+106_windows-x86_bin.zip > > Thanks, > Georgiy. > > On 26.02.2016 21:26, Alex Buckley wrote: > > On 2/26/2016 8:37 AM, Georgiy Rakov wrote: > > current spec [1] now contains following assertions > related to grammar: > > A compilation unit (JLS 7.3) may contain a module > declaration, in > which case the filename of the compilation unit is > typically > |module-info.java|. > > CompilationUnit: > [PackageDeclaration] {ImportDeclaration} > {TypeDeclaration} > ModuleDeclaration > > These assertions allows to specify any of import, > package or type > declarations in any compilation unit, for instance > module-info.java is > allowed to contain any of the mentioned declarations. > However currently > javac in the latest jigsaw build [2] reports an error on > such cases > provided they are compiled in module mode. For example > if we have > following directory structure: > > mod\module-info.java: > module mod { > exports pkg; > } > > mod\pkg\module-info.java: > package pkg; > > class C { > } > > then compiling it by following command line with javac > from [2]: > > javac -modulesourcepath . mod\module-info.java > mod\pkg\module-info.java > > causes following output: > > mod\pkg\module-info.java:1: error: expected 'module' > package pkg; > ^ > 1 error > > > javac is merely choosing to implement the rule at the end of > JLS 7.6 > that a type declaration (optionally preceded by package/import > declarations) must be provided in a suitably named file. > > Perhaps I should say "a variant of the rule" because 7.6 as > written > concerns a public type and your example has a package-access > type. > Still, bottom line, javac is free to require that a > compilation unit > which starts with a package declaration _must not_ be in a > file called > foo-bar.java -- the hyphen indicates a name that can't > possibly align > with the type declared in the compilation unit. > > The error message for mod\pkg\module-info.java could be a > bit more > helpful, but that's a quality-of-implementation detail. > > Conversely, a compilation unit that contains a module > declaration > _may_ be in a file called module-info.java, or in a file called > foo-bar.java, or in a file called mod_decl.JAV. The > "typically" in [1] > is meant to indicate that the sub-clause on filename is > non-normative. > This is akin to how a compilation unit that contains a > package-access > type declaration for class C _may_ be in a file D.java. > > Alex > > > From mandy.chung at oracle.com Mon Mar 14 22:49:45 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Mon, 14 Mar 2016 22:49:45 +0000 Subject: hg: jigsaw/jake/jdk: Missing closing bracket in javadoc Message-ID: <201603142249.u2EMnj4E024666@aojmv0008.oracle.com> Changeset: db679f8c1122 Author: mchung Date: 2016-03-14 15:49 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/db679f8c1122 Missing closing bracket in javadoc ! src/java.base/share/classes/java/lang/reflect/Module.java From xueming.shen at oracle.com Mon Mar 14 23:08:28 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 14 Mar 2016 16:08:28 -0700 Subject: Initial webrev with changes for JDK 9 jrtfs In-Reply-To: <56E715F2.1010203@oracle.com> References: <56E29267.7070501@oracle.com> <56E71303.5020009@oracle.com> <56E715F2.1010203@oracle.com> Message-ID: <56E7446C.7030607@oracle.com> (1) JrtFilePath: it does not seem to help performance to use the byte[] as the internal storage. (2) AbstractJrtFilesystem.java getPathMatcher: .... if (syntax.equalsIgnoreCase(GLOB_SYNTAX)) { expr = JrtUtils.toRegexPattern(input); } else if (syntax.equalsIgnoreCase(REGEX_SYNTAX)) { expr = input; } else { throw new UnsupportedOperationException("Syntax '" + syntax + "' not recognized"); } (3) can't JrtFileSystem use sun.nio.fs.Globs ? instead of its own copy? (4) JrtFilesystem.nodesToIterator() Stream has a "iterator() method. why need a collect() here? different performance? for example private Iterator nodesToIterator(AbstractJrtPath dir, List childNodes) { return childNodes.stream() .map(child -> (Path)dir.resolve(toJrtPath(child.getNameString()).getFileName())) .iterator(); } sherman From xueming.shen at oracle.com Mon Mar 14 23:21:33 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 14 Mar 2016 16:21:33 -0700 Subject: Initial webrev with changes for JDK 9 jrtfs In-Reply-To: <56E7446C.7030607@oracle.com> References: <56E29267.7070501@oracle.com> <56E71303.5020009@oracle.com> <56E715F2.1010203@oracle.com> <56E7446C.7030607@oracle.com> Message-ID: <56E7477D.9040107@oracle.com> (5) JrtFileSystemProvider.copy(src, dst, ...options) The "dst/target" should not be cast to "AbstractJrtPath"? the jrtfs itself is a readonly, I'm not sure if we want to support the operation of copying a "file" output jrtfs. The copy/paste "copyToTarget" appears to be functional, if it's not a "AbstractJrtPath". On 03/14/2016 04:08 PM, Xueming Shen wrote: > (1) JrtFilePath: it does not seem to help performance to use the byte[] as the > internal storage. > > (2) AbstractJrtFilesystem.java > > getPathMatcher: > .... > if (syntax.equalsIgnoreCase(GLOB_SYNTAX)) { > expr = JrtUtils.toRegexPattern(input); > } else if (syntax.equalsIgnoreCase(REGEX_SYNTAX)) { > expr = input; > } else { > throw new UnsupportedOperationException("Syntax '" + syntax > + "' not recognized"); > } > > (3) can't JrtFileSystem use sun.nio.fs.Globs ? instead of its own copy? > > (4) JrtFilesystem.nodesToIterator() > > Stream has a "iterator() method. why need a collect() here? different performance? > for example > > private Iterator nodesToIterator(AbstractJrtPath dir, List childNodes) { > return childNodes.stream() > .map(child -> (Path)dir.resolve(toJrtPath(child.getNameString()).getFileName())) > .iterator(); > } > > > sherman > > From mandy.chung at oracle.com Mon Mar 14 23:59:27 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Mon, 14 Mar 2016 23:59:27 +0000 Subject: hg: jigsaw/jake/jdk: Test update per --plugin-module-path option rename Message-ID: <201603142359.u2ENxR5b022091@aojmv0008.oracle.com> Changeset: aaa5d9612312 Author: mchung Date: 2016-03-14 16:59 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/aaa5d9612312 Test update per --plugin-module-path option rename ! test/jdk/jigsaw/tools/lib/tests/JImageGenerator.java From mandy.chung at oracle.com Tue Mar 15 00:09:21 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 15 Mar 2016 00:09:21 +0000 Subject: hg: jigsaw/jake/langtools: ModulePathTest.java test fails after jmod --create is changed as subcommand Message-ID: <201603150009.u2F09LNT025776@aojmv0008.oracle.com> Changeset: 062f84e9c5a0 Author: mchung Date: 2016-03-14 17:09 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/062f84e9c5a0 ModulePathTest.java test fails after jmod --create is changed as subcommand ! test/tools/javac/modules/ModulePathTest.java From kevin.rushforth at oracle.com Tue Mar 15 02:38:12 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 14 Mar 2016 19:38:12 -0700 Subject: [9] Review request for FX Jigsaw changes Message-ID: <56E77594.8030401@oracle.com> Please review the webrev for reviewing the jigsaw changes for FX. https://bugs.openjdk.java.net/browse/JDK-8092093 http://cr.openjdk.java.net/~kcr/8092093/webrev.00/rt/ http://cr.openjdk.java.net/~kcr/8092093/webrev.00/rt-fxpackager/ I have separated out the in-progress changes to modules/fxpackager* (jdk.packager and jdk.packager.services modules) so they can be reviewed separately. However, they will be pushed along with the other changes as a single changeset. These changes are planned to be integrated into FX 9 at the same time as the JDK changes are integrated (probably next week). They will be synced down to FX 9-dev shortly after that. Please note the following: * The required boot JDK to build FX after the Jigsaw integration will be JDK 9 build 109. We are not yet able to build with a Jigsaw-based JDK 9 as the boot JDK yet, so we will be sticking at JDK 9 build 109 for a few weeks. * gradle 2.11 is required to build using JDK 9 * In addition to building JavaFX as modules for use with a Jigsaw-capable JDK, we still build the "legacy sdk" using the existing pre-Jigsaw layout, including jfxrt.jar, etc. As such, most developers during the transition will hopefully not notice too much change. * If you do want to run tests using the modules, you will need a Jigsaw-based JDK with javafx modules included, and point to that with a JDK9_HOME (likely to be changed to JIGSAW_HOME) env variable. If you actually want to build the JDK (which you will need to do if any module dependencies change), we will send out separate instructions. These will eventually make it onto the OpenJFX Wiki. * The fxpackager modules are disabled by default. To enable them, you need to build a Jigsaw-based JDK *without* the jdk.pacakger* modules and point to that with a JDK9_HOME (likely to be changed to JIGSAW_HOME) env variable. Since most developers will not build in this mode, you need to set 'gradle -PBUILD_FXPACKAGER' to enable building the packager. * I will refresh the webrev tomorrow afternoon, after making a couple of planned changes and reacting to any feedback, and again on Wednesday afternoon. -- Kevin From sundararajan.athijegannathan at oracle.com Tue Mar 15 02:48:41 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 15 Mar 2016 08:18:41 +0530 Subject: Initial webrev with changes for JDK 9 jrtfs In-Reply-To: <56E7477D.9040107@oracle.com> References: <56E29267.7070501@oracle.com> <56E71303.5020009@oracle.com> <56E715F2.1010203@oracle.com> <56E7446C.7030607@oracle.com> <56E7477D.9040107@oracle.com> Message-ID: <56E77809.2000804@oracle.com> Hi, Thanks for the review. I've filed a bug to track the cleanups suggested: https://bugs.openjdk.java.net/browse/JDK-8151860 Quick comments: 1) jrt fs is read-only file system as you noted. Copying content into jrt fs does not make sense. Eventually read-only file system exception is thrown. But, yes that cast can be avoided. 2) jrt-fs.jar is generated from jimage and jrt-fs sources and expected to work on previous JDK (jdk 8 in this case). This is to support cross-JDK reference to platform classes (from IDEs). So, it is better to avoid internal JDK classes such as sun.nio.fs.Globs in jrt-fs code. Thanks, -Sundar On 3/15/2016 4:51 AM, Xueming Shen wrote: > > (5) JrtFileSystemProvider.copy(src, dst, ...options) > > The "dst/target" should not be cast to "AbstractJrtPath"? the jrtfs > itself is > a readonly, I'm not sure if we want to support the operation of copying > a "file" output jrtfs. The copy/paste "copyToTarget" appears to be > functional, > if it's not a "AbstractJrtPath". > > > On 03/14/2016 04:08 PM, Xueming Shen wrote: >> (1) JrtFilePath: it does not seem to help performance to use the >> byte[] as the >> internal storage. >> >> (2) AbstractJrtFilesystem.java >> >> getPathMatcher: >> .... >> if (syntax.equalsIgnoreCase(GLOB_SYNTAX)) { >> expr = JrtUtils.toRegexPattern(input); >> } else if (syntax.equalsIgnoreCase(REGEX_SYNTAX)) { >> expr = input; >> } else { >> throw new UnsupportedOperationException("Syntax '" + >> syntax >> + "' not recognized"); >> } >> >> (3) can't JrtFileSystem use sun.nio.fs.Globs ? instead of its own copy? >> >> (4) JrtFilesystem.nodesToIterator() >> >> Stream has a "iterator() method. why need a collect() here? >> different performance? >> for example >> >> private Iterator nodesToIterator(AbstractJrtPath dir, >> List childNodes) { >> return childNodes.stream() >> .map(child -> >> (Path)dir.resolve(toJrtPath(child.getNameString()).getFileName())) >> .iterator(); >> } >> >> >> sherman >> >> > From mandy.chung at oracle.com Tue Mar 15 02:57:47 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 15 Mar 2016 02:57:47 +0000 Subject: hg: jigsaw/jake/jdk: Un-problem list javax/management/mxbean/MXBeanLoadingTest1.java Message-ID: <201603150257.u2F2vle6019145@aojmv0008.oracle.com> Changeset: 28cdd78d9e76 Author: mchung Date: 2016-03-14 19:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/28cdd78d9e76 Un-problem list javax/management/mxbean/MXBeanLoadingTest1.java ! test/ProblemList.jake.txt From mandy.chung at oracle.com Tue Mar 15 03:51:29 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 15 Mar 2016 03:51:29 +0000 Subject: hg: jigsaw/jake/jdk: 2 new changesets Message-ID: <201603150351.u2F3pTqr006012@aojmv0008.oracle.com> Changeset: 01eba0a38afe Author: mchung Date: 2016-03-14 20:50 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/01eba0a38afe Update problem list with proper bug id ! test/ProblemList.jake.txt Changeset: a2177e0d0f89 Author: mchung Date: 2016-03-14 20:51 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a2177e0d0f89 Add @modules for test/sun/security/krb5/auto/HttpNegotiateServer.java ! test/sun/security/krb5/auto/HttpNegotiateServer.java From mandy.chung at oracle.com Tue Mar 15 05:49:36 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 14 Mar 2016 22:49:36 -0700 Subject: Unnamed module and duplicate package In-Reply-To: <56E667DD.6060700@redhat.com> References: <56E286EB.5000904@oracle.com> <56E2A12F.5020000@oracle.com> <56E2DB95.4010600@redhat.com> <56E2E2E9.2050307@oracle.com> <56E2E485.40403@redhat.com> <56E3D9FE.7040504@oracle.com> <56E667DD.6060700@redhat.com> Message-ID: <5370F0C5-89D4-40CB-9755-93A7B2E4F0CE@oracle.com> > On Mar 14, 2016, at 12:27 AM, David M. Lloyd wrote: > > On 3/12/16 9:57 AM, Alan Bateman wrote: >> >> On 11/03/2016 15:30, David M. Lloyd wrote: >>> >>> What are the limiting factors? In my analysis the only problem that >>> seemed close to insurmountable was the special natives that are used >>> in the JDK but these only seem to be used from java.base. Does it all >>> boil down to getClassLoader()==null security checks on the Java side, >>> or is there a JVM component that I haven't discovered? >> I have no doubt that it would be a big effort. >> >> One of the most difficult issues when de-privileging is identifying the >> minimum permissions. It gets complicated in areas with callbacks where >> intermediate frames reduce the effective permissions. For several of >> these modules then it may be that they end up needing AllPermission so >> the benefits of moving them out are significantly reduced. >> >> Related is performance when running with a security manager. A long >> standing optimization is that code in the boot loader has AllPermission. >> >> At things stand then we can't move any modules that export java.* APIs. >> If getPlatformClassLoader() and the related spec change to allow java.* >> classes be loaded by the platform class loader and its ancestors goes in >> then it removes this hurdle. >> >> I'm sure there will be lots of other issues once you get into it. Some >> of the modules (like java.management) are tightly coupled to the VM. On >> getClassLoader() returning null then such uses would need to be >> examined. I don't expect there are too many as we replaced a lot of them >> in the JDK 8 time frame as part of JEP 162. > > So really there are multiple parts to be able to move modules out of the bootstrap class loader: > > 1. Relax the spec so that other class loaders (preferably only trusted/blessed class loaders) can define java.* classes > This is only needed for modules defining java.* types. > 2. Come up with a replacement for getClassLoader() == null checks (e.g. getClassLoader() == null || getClassLoader().isPrivileged()) > We had attempted to clean up JDK code in JDK 8 and added jdk.internal.VM.isSystemDomainLoader(ClassLoader). This is not that hard to identify. Once it?s moved to be defined by the platform class loader, caller?s sensitive operations may require permission (e.g. methods that does security check based on the caller?s class loader). The bootstrap class loader is also the root class loader which has access to all types defined by its child class loader. But that may not be true once it?s deprivileged. We need to identify those caller-sensitive operations and wrap with doPrivileged if missing. Also class resolution does a package-access check using the initiating class' protection domain. This is extremely hard to diagnose. The diagnosability of that area is really bugging me that really needs to be improved. Not to mention when native code is involved but modularization is not cleaned. > 3. Then go back and incrementally deprivilege as many modules as possible/practical, as time permits > There is no good existing tool to help analysis. It heavily depends how well the existing test coverage is to run with security manager. Minimum set of permissions is the first step. As Alan mentions, test, performance, compatibility and many other things to be thought through. > However the benefits seem attractive: improved security (even if only one module gets deprivileged), ability for core modules to depend on upgradable modules (java.sql case). > ?core modules? - I assume you refer to the modules defined by the boot module. I don?t see why they need to depend on the upgradeable modules and don?t see any benefit. > As far as allowing other class loaders to load java.* classes - could it not just be a matter of setting a flag on ClassLoader which is only settable by a non-public constructor or something like that? I don?t follow your suggestion on a flag. java.* types currently is restricted to be defined by the bootstrap class loader. The spec change is necessary to allow future deprivileging work to take place. > The flag could be checked easily by Java or native code, and it doesn't tie the JDK more tightly to specific hierarchical class loading arrangements. What defining class loader of java.* type is unrelated to the class loader hierarchy. Mandy From xueming.shen at oracle.com Tue Mar 15 05:54:57 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 14 Mar 2016 22:54:57 -0700 Subject: Initial webrev with changes for JDK 9 jrtfs In-Reply-To: <56E77809.2000804@oracle.com> References: <56E29267.7070501@oracle.com> <56E71303.5020009@oracle.com> <56E715F2.1010203@oracle.com> <56E7446C.7030607@oracle.com> <56E7477D.9040107@oracle.com> <56E77809.2000804@oracle.com> Message-ID: <56E7A3B1.3090608@oracle.com> On 3/14/2016 7:48 PM, Sundararajan Athijegannathan wrote: > Hi, > > Thanks for the review. I've filed a bug to track the cleanups > suggested: https://bugs.openjdk.java.net/browse/JDK-8151860 > > Quick comments: > > 1) jrt fs is read-only file system as you noted. Copying content into > jrt fs does not make sense. Eventually read-only file system exception > is thrown. > But, yes that cast can be avoided. Hi Sundar, What I meant is without that "check&cast-ing", the copyToTarget might actually work if the "dst/target" is a non-jrtfs-path", for example, copy a "class" file out of the jrtfs and store into the local file system (those code originally is designed/implemented to work that way, whether or not it works depends on if the src is readable and if the dst is writable). The question here is if this is something we want to do for the jrtfs. That is a design decision to make. -Sherman > > 2) jrt-fs.jar is generated from jimage and jrt-fs sources and expected > to work on previous JDK (jdk 8 in this case). This is to support > cross-JDK reference to platform classes (from IDEs). > So, it is better to avoid internal JDK classes such as sun.nio.fs.Globs > in jrt-fs code. > > Thanks, > -Sundar > > On 3/15/2016 4:51 AM, Xueming Shen wrote: >> (5) JrtFileSystemProvider.copy(src, dst, ...options) >> >> The "dst/target" should not be cast to "AbstractJrtPath"? the jrtfs >> itself is >> a readonly, I'm not sure if we want to support the operation of copying >> a "file" output jrtfs. The copy/paste "copyToTarget" appears to be >> functional, >> if it's not a "AbstractJrtPath". >> >> >> On 03/14/2016 04:08 PM, Xueming Shen wrote: >>> (1) JrtFilePath: it does not seem to help performance to use the >>> byte[] as the >>> internal storage. >>> >>> (2) AbstractJrtFilesystem.java >>> >>> getPathMatcher: >>> .... >>> if (syntax.equalsIgnoreCase(GLOB_SYNTAX)) { >>> expr = JrtUtils.toRegexPattern(input); >>> } else if (syntax.equalsIgnoreCase(REGEX_SYNTAX)) { >>> expr = input; >>> } else { >>> throw new UnsupportedOperationException("Syntax '" + >>> syntax >>> + "' not recognized"); >>> } >>> >>> (3) can't JrtFileSystem use sun.nio.fs.Globs ? instead of its own copy? >>> >>> (4) JrtFilesystem.nodesToIterator() >>> >>> Stream has a "iterator() method. why need a collect() here? >>> different performance? >>> for example >>> >>> private Iterator nodesToIterator(AbstractJrtPath dir, >>> List childNodes) { >>> return childNodes.stream() >>> .map(child -> >>> (Path)dir.resolve(toJrtPath(child.getNameString()).getFileName())) >>> .iterator(); >>> } >>> >>> >>> sherman >>> >>> From sundararajan.athijegannathan at oracle.com Tue Mar 15 05:52:35 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 15 Mar 2016 11:22:35 +0530 Subject: Initial webrev with changes for JDK 9 jrtfs In-Reply-To: <56E7A3B1.3090608@oracle.com> References: <56E29267.7070501@oracle.com> <56E71303.5020009@oracle.com> <56E715F2.1010203@oracle.com> <56E7446C.7030607@oracle.com> <56E7477D.9040107@oracle.com> <56E77809.2000804@oracle.com> <56E7A3B1.3090608@oracle.com> Message-ID: <56E7A323.3050508@oracle.com> On 3/15/2016 11:24 AM, Xueming Shen wrote: > > On 3/14/2016 7:48 PM, Sundararajan Athijegannathan wrote: >> Hi, >> >> Thanks for the review. I've filed a bug to track the cleanups >> suggested: https://bugs.openjdk.java.net/browse/JDK-8151860 >> >> Quick comments: >> >> 1) jrt fs is read-only file system as you noted. Copying content into >> jrt fs does not make sense. Eventually read-only file system exception >> is thrown. >> But, yes that cast can be avoided. > > Hi Sundar, > > What I meant is without that "check&cast-ing", the copyToTarget might > actually work if the "dst/target" is a non-jrtfs-path", for example, copy > a "class" file out of the jrtfs and store into the local file system > (those code > originally is designed/implemented to work that way, whether or not it > works depends on if the src is readable and if the dst is writable). The > question here is if this is something we want to do for the jrtfs. > That is > a design decision to make. That's right. That has to be revisited. -Sundar > > -Sherman > > > >> >> 2) jrt-fs.jar is generated from jimage and jrt-fs sources and expected >> to work on previous JDK (jdk 8 in this case). This is to support >> cross-JDK reference to platform classes (from IDEs). >> So, it is better to avoid internal JDK classes such as sun.nio.fs.Globs >> in jrt-fs code. >> >> Thanks, >> -Sundar >> >> On 3/15/2016 4:51 AM, Xueming Shen wrote: >>> (5) JrtFileSystemProvider.copy(src, dst, ...options) >>> >>> The "dst/target" should not be cast to "AbstractJrtPath"? the jrtfs >>> itself is >>> a readonly, I'm not sure if we want to support the operation of copying >>> a "file" output jrtfs. The copy/paste "copyToTarget" appears to be >>> functional, >>> if it's not a "AbstractJrtPath". >>> >>> >>> On 03/14/2016 04:08 PM, Xueming Shen wrote: >>>> (1) JrtFilePath: it does not seem to help performance to use the >>>> byte[] as the >>>> internal storage. >>>> >>>> (2) AbstractJrtFilesystem.java >>>> >>>> getPathMatcher: >>>> .... >>>> if (syntax.equalsIgnoreCase(GLOB_SYNTAX)) { >>>> expr = JrtUtils.toRegexPattern(input); >>>> } else if (syntax.equalsIgnoreCase(REGEX_SYNTAX)) { >>>> expr = input; >>>> } else { >>>> throw new UnsupportedOperationException("Syntax '" + >>>> syntax >>>> + "' not recognized"); >>>> } >>>> >>>> (3) can't JrtFileSystem use sun.nio.fs.Globs ? instead of its own >>>> copy? >>>> >>>> (4) JrtFilesystem.nodesToIterator() >>>> >>>> Stream has a "iterator() method. why need a collect() here? >>>> different performance? >>>> for example >>>> >>>> private Iterator nodesToIterator(AbstractJrtPath dir, >>>> List childNodes) { >>>> return childNodes.stream() >>>> .map(child -> >>>> (Path)dir.resolve(toJrtPath(child.getNameString()).getFileName())) >>>> .iterator(); >>>> } >>>> >>>> >>>> sherman >>>> >>>> > From mandy.chung at oracle.com Tue Mar 15 06:27:30 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 15 Mar 2016 06:27:30 +0000 Subject: hg: jigsaw/jake: 16 new changesets Message-ID: <201603150627.u2F6RUO2022178@aojmv0008.oracle.com> Changeset: 20b062ae4123 Author: erikj Date: 2016-03-08 15:51 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/20b062ae4123 8151435: Windows devkit missing 32bit msvcdis120.dll Reviewed-by: tbell ! make/devkit/createWindowsDevkit.sh Changeset: 73287079abaf Author: bchristi Date: 2016-03-08 11:36 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/73287079abaf 8148187: Remove OS X-specific com.apple.concurrent package Summary: Removed jdk.deploy.osx module (including com.apple.concurrent) Reviewed-by: alanb, erikj, mchung ! common/bin/unshuffle_list.txt ! make/Images.gmk ! make/Main.gmk ! make/common/NON_CORE_PKGS.gmk ! modules.xml Changeset: 06622a7047a8 Author: kshefov Date: 2016-02-20 11:43 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/06622a7047a8 8141616: Add new methods to the java Whitebox API Reviewed-by: kvn, dpochepk ! test/lib/sun/hotspot/WhiteBox.java Changeset: d5d0272959aa Author: thartmann Date: 2016-02-22 08:04 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/d5d0272959aa Merge Changeset: 42f50a15674f Author: neliasso Date: 2016-02-25 10:43 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/42f50a15674f 8148159: [TESTBUG] TestCompilerDirectivesCompatibility tests fails on non-tiered server VMs Summary: Add whitebox for checking available compilers Reviewed-by: kvn ! test/lib/sun/hotspot/WhiteBox.java Changeset: add4d35c3625 Author: thartmann Date: 2016-02-29 09:02 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/add4d35c3625 Merge Changeset: 53d8e79dcfc2 Author: mgronlun Date: 2016-03-01 23:41 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/53d8e79dcfc2 8143228: Update module exports for Java Flight Recorder Reviewed-by: alanb, egahlin ! common/bin/compare_exceptions.sh.incl ! modules.xml Changeset: 50a1521b75f9 Author: ysuenaga Date: 2016-02-29 22:55 +0900 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/50a1521b75f9 8150723: HSDB toolbar icons are missing. Reviewed-by: erikj, dsamersoff ! make/CompileJavaModules.gmk Changeset: 6bd3985e54e8 Author: jwilhelm Date: 2016-03-05 10:10 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/6bd3985e54e8 Merge Changeset: da69589a08fc Author: amurillo Date: 2016-03-05 20:46 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/da69589a08fc Merge Changeset: 672174fe5bf9 Author: amurillo Date: 2016-03-08 19:03 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/672174fe5bf9 Merge ! modules.xml Changeset: 34c2b2497b60 Author: simonis Date: 2016-03-09 11:15 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/34c2b2497b60 8151497: Set REQUIRED_OS_NAME and REQUIRED_OS_VERSION on AIX Reviewed-by: erikj ! common/autoconf/generated-configure.sh ! common/autoconf/platform.m4 Changeset: 55fdc41df143 Author: lana Date: 2016-03-10 09:49 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/55fdc41df143 Merge Changeset: 925be13b3740 Author: erikj Date: 2016-03-11 09:27 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/925be13b3740 8151685: Fix the version of required jdk in configure help text Reviewed-by: erikj Contributed-by: kubota.yuji at gmail.com ! common/autoconf/generated-configure.sh ! common/autoconf/help.m4 Changeset: 657bcb98e4a4 Author: henryjen Date: 2016-03-14 20:44 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/657bcb98e4a4 Merge ! common/autoconf/generated-configure.sh ! common/autoconf/platform.m4 ! make/CompileJavaModules.gmk ! make/Images.gmk ! make/Main.gmk ! make/common/NON_CORE_PKGS.gmk ! test/lib/sun/hotspot/WhiteBox.java Changeset: 6e6cc75018b6 Author: henryjen Date: 2016-03-14 22:12 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/6e6cc75018b6 Merge From mandy.chung at oracle.com Tue Mar 15 06:27:53 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 15 Mar 2016 06:27:53 +0000 Subject: hg: jigsaw/jake/jaxp: 3 new changesets Message-ID: <201603150627.u2F6RrWd022420@aojmv0008.oracle.com> Changeset: 0fe7231b64a6 Author: joehw Date: 2016-03-09 16:09 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/0fe7231b64a6 8150704: XALAN: ERROR: 'No more DTM IDs are available' when transforming with lots of temporary result trees Reviewed-by: joehw Contributed-by: christoph.langer at sap.com ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/DOM.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/ApplyTemplates.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/CallTemplate.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Sort.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/SyntaxTreeNode.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Template.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/VariableBase.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/WithParam.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/AdaptiveResultTreeImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/DOMAdapter.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/MultiDOM.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/SAXImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/SimpleResultTreeImpl.java - test/javax/xml/jaxp/unittest/transform/Bug4693341.out ! test/javax/xml/jaxp/unittest/transform/Bug4693341Test.java - test/javax/xml/jaxp/unittest/transform/Bug4693341_golden.dtd - test/javax/xml/jaxp/unittest/transform/Bug4693341_golden.xml - test/javax/xml/jaxp/unittest/transform/Bug6505031.java + test/javax/xml/jaxp/unittest/transform/Bug8150704-1.ref + test/javax/xml/jaxp/unittest/transform/Bug8150704-1.xml + test/javax/xml/jaxp/unittest/transform/Bug8150704-1.xsl + test/javax/xml/jaxp/unittest/transform/Bug8150704-2.ref + test/javax/xml/jaxp/unittest/transform/Bug8150704-2.xml + test/javax/xml/jaxp/unittest/transform/Bug8150704-2.xsl ! test/javax/xml/jaxp/unittest/transform/TransformerTest.java Changeset: 1c1bb661d35b Author: lana Date: 2016-03-10 09:51 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/1c1bb661d35b Merge - test/javax/xml/jaxp/unittest/transform/Bug4693341.out - test/javax/xml/jaxp/unittest/transform/Bug4693341_golden.dtd - test/javax/xml/jaxp/unittest/transform/Bug4693341_golden.xml - test/javax/xml/jaxp/unittest/transform/Bug6505031.java Changeset: bc96fc213c03 Author: henryjen Date: 2016-03-14 20:44 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/bc96fc213c03 Merge - test/javax/xml/jaxp/unittest/transform/Bug4693341.out - test/javax/xml/jaxp/unittest/transform/Bug4693341_golden.dtd - test/javax/xml/jaxp/unittest/transform/Bug4693341_golden.xml - test/javax/xml/jaxp/unittest/transform/Bug6505031.java From mandy.chung at oracle.com Tue Mar 15 06:27:49 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 15 Mar 2016 06:27:49 +0000 Subject: hg: jigsaw/jake/hotspot: 111 new changesets Message-ID: <201603150627.u2F6RoRN022374@aojmv0008.oracle.com> Changeset: 9900740dd51f Author: ppunegov Date: 2016-02-17 17:48 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9900740dd51f 8144621: CompilerControl: inline tests timeout with Xcomp Summary: Restrict patterns that lead to timeout Reviewed-by: kvn, neliasso ! test/compiler/compilercontrol/share/AbstractTestBase.java Changeset: 2c3c43037e14 Author: thartmann Date: 2016-02-19 10:06 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2c3c43037e14 8145707: 4 Null pointer dereference defect groups in compileBroker.cpp. Summary: Added explicit null checks to fix possible null pointer dereference errors for internal tests. Reviewed-by: kvn Contributed-by: Rahul Raghavan ! src/share/vm/compiler/compileBroker.cpp Changeset: a97431603d3f Author: vlivanov Date: 2016-02-19 20:40 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a97431603d3f 7177745: JSR292: Many Callsite relinkages cause target method to always run in interpreter mode Reviewed-by: jrose, kvn ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/code/dependencies.hpp ! src/share/vm/code/dependencyContext.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/runtime/vmStructs.cpp + test/compiler/jsr292/ContinuousCallSiteTargetChange.java Changeset: b3434fcd4e11 Author: vlivanov Date: 2016-02-19 20:41 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b3434fcd4e11 8149741: Don't refer to stub entry points by index in external_word relocations Reviewed-by: kvn ! src/cpu/x86/vm/templateInterpreterGenerator_x86.cpp ! src/os_cpu/windows_x86/vm/assembler_windows_x86.cpp ! src/share/vm/code/relocInfo.cpp ! src/share/vm/code/relocInfo.hpp ! src/share/vm/prims/jvmtiCodeBlobEvents.cpp ! src/share/vm/runtime/stubCodeGenerator.cpp ! src/share/vm/runtime/stubCodeGenerator.hpp Changeset: d743113e99e2 Author: vlivanov Date: 2016-02-19 20:45 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d743113e99e2 8067014: LinearScan::is_sorted significantly slows down fastdebug builds' performance Reviewed-by: vlivanov, shade ! src/share/vm/c1/c1_CFGPrinter.hpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_LinearScan.hpp Changeset: f1c5937e76a2 Author: mdoerr Date: 2016-02-19 11:09 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f1c5937e76a2 8149655: PPC64: Implement CompactString intrinsics Reviewed-by: goetz, kvn ! src/cpu/ppc/vm/globals_ppc.hpp ! src/cpu/ppc/vm/macroAssembler_ppc.cpp ! src/cpu/ppc/vm/macroAssembler_ppc.hpp ! src/cpu/ppc/vm/ppc.ad ! src/cpu/ppc/vm/stubGenerator_ppc.cpp ! src/cpu/ppc/vm/vm_version_ppc.cpp ! src/cpu/ppc/vm/vm_version_ppc.hpp ! test/compiler/intrinsics/string/TestStringIntrinsics2.java Changeset: bc4aca25ef2a Author: kshefov Date: 2016-02-20 11:44 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/bc4aca25ef2a 8141616: Add new methods to the java Whitebox API Reviewed-by: kvn, dpochepk ! src/share/vm/prims/whitebox.cpp Changeset: ed4f837cee25 Author: kshefov Date: 2016-02-20 11:49 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ed4f837cee25 8141618: Change JVMCI compilerToVM constant pool tests to support CP cache Reviewed-by: twisti, dpochepk ! test/compiler/jvmci/common/testcases/MultipleAbstractImplementer.java ! test/compiler/jvmci/common/testcases/MultipleImplementer2.java ! test/compiler/jvmci/common/testcases/MultipleImplementersInterface.java ! test/compiler/jvmci/compilerToVM/ConstantPoolTestCase.java ! test/compiler/jvmci/compilerToVM/ConstantPoolTestsHelper.java ! test/compiler/jvmci/compilerToVM/LookupKlassInPoolTest.java ! test/compiler/jvmci/compilerToVM/ResolveConstantInPoolTest.java ! test/compiler/jvmci/compilerToVM/ResolveTypeInPoolTest.java Changeset: a8377a286e90 Author: kshefov Date: 2016-02-20 11:49 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a8377a286e90 8141619: Develop new tests for JVMCI compilerToVM class' CP related methods Reviewed-by: twisti, dpochepk + test/compiler/jvmci/compilerToVM/LookupKlassRefIndexInPoolTest.java + test/compiler/jvmci/compilerToVM/LookupMethodInPoolTest.java + test/compiler/jvmci/compilerToVM/LookupNameAndTypeRefIndexInPoolTest.java + test/compiler/jvmci/compilerToVM/LookupNameInPoolTest.java + test/compiler/jvmci/compilerToVM/LookupSignatureInPoolTest.java + test/compiler/jvmci/compilerToVM/ResolveFieldInPoolTest.java + test/compiler/jvmci/compilerToVM/ResolvePossiblyCachedConstantInPoolTest.java Changeset: e06b9173b181 Author: thartmann Date: 2016-02-22 08:04 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e06b9173b181 Merge ! src/cpu/ppc/vm/globals_ppc.hpp Changeset: 55778b6121e3 Author: roland Date: 2016-02-15 10:14 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/55778b6121e3 8087341: C2 doesn't optimize redundant memory operations with G1 Summary: effect of memory barrier in post barrier is too wide Reviewed-by: kvn, aph Contributed-by: adinn ! src/cpu/aarch64/vm/aarch64.ad ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp Changeset: db7934bcad3b Author: roland Date: 2016-02-17 10:59 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/db7934bcad3b 8148786: xml.tranform fails on x86-64 Summary: CCP computes wrong type for CountedLoop iv Phi Reviewed-by: kvn ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/phaseX.hpp Changeset: adf6fb6c302f Author: shade Date: 2016-02-19 11:16 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/adf6fb6c302f 8150102: C1 should fold arraylength for constant/trusted arrays Reviewed-by: vlivanov, kvn ! src/share/vm/c1/c1_Canonicalizer.cpp Changeset: 23abf2feec96 Author: roland Date: 2016-02-16 12:54 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/23abf2feec96 8149916: Test case for 8149797 Reviewed-by: kvn + test/compiler/c2/TestDominatingDeadCheckCast.java Changeset: df3a274ff883 Author: roland Date: 2016-02-23 10:22 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/df3a274ff883 Merge Changeset: 94f78e8d4d83 Author: jcm Date: 2016-02-22 23:37 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/94f78e8d4d83 8145333: -XX:+EnableJVMCI -XX:+UseJVMCICompiler -XX:-EnableJVMCI makes JVM crash Summary: JVMCI Flags are checked for consistency after parse. Reviewed-by: twisti - src/share/vm/jvmci/commandLineFlagConstraintsJVMCI.cpp - src/share/vm/jvmci/commandLineFlagConstraintsJVMCI.hpp ! src/share/vm/jvmci/jvmci_globals.cpp ! src/share/vm/jvmci/jvmci_globals.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/commandLineFlagConstraintList.cpp Changeset: 0bdb1a9d1fd1 Author: shade Date: 2016-02-23 17:55 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0bdb1a9d1fd1 8150180: String.value contents should be trusted Reviewed-by: vlivanov, redestad, jrose, twisti ! src/share/vm/opto/library_call.cpp Changeset: dfa7d9934ab4 Author: roland Date: 2016-02-23 17:59 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/dfa7d9934ab4 8007986: GrowableArray should implement binary search Summary: binary search method for GrowableArray Reviewed-by: vlivanov, jrose ! src/share/vm/ci/ciConstantPoolCache.cpp ! src/share/vm/ci/ciConstantPoolCache.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciObjectFactory.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/utilities/growableArray.hpp Changeset: 8b9fdaeb8c57 Author: shade Date: 2016-02-23 22:09 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/8b9fdaeb8c57 8148146: Integrate new internal Unsafe entry points, and basic intrinsic support for VarHandles Reviewed-by: psandoz, kvn, jrose, adinn, simonis, coleenp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/classfile/vmSymbols.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/node.hpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/vmStructs.cpp ! 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/X-UnsafeAccessTest.java.template + test/compiler/unsafe/generate-unsafe-tests.sh Changeset: 86d78449f472 Author: shade Date: 2016-02-24 18:43 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/86d78449f472 8150514: C1 crashes in Canonicalizer::do_ArrayLength() after fix for JDK-8150102 Reviewed-by: thartmann, vlivanov ! src/share/vm/c1/c1_Canonicalizer.cpp + test/compiler/c1/CanonicalizeArrayLength.java Changeset: 1f4f4866aee0 Author: roland Date: 2016-02-23 17:18 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1f4f4866aee0 8148353: [linux-sparc] Crash in libawt.so on Linux SPARC Summary: gcc expects clean 32 bit int in 64 bit register on function entry Reviewed-by: kvn, dlong ! make/test/JtregNative.gmk ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp + test/compiler/native/TestDirtyInt.java + test/compiler/native/libTestDirtyInt.c Changeset: 0fc557e05fc0 Author: roland Date: 2016-02-24 20:18 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0fc557e05fc0 Merge Changeset: d8386cb3528c Author: thartmann Date: 2016-02-25 08:47 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d8386cb3528c 8150441: CompileTask::print_impl() is broken after JDK-8146905 Summary: Timestamps should be explicitly initialized. Reviewed-by: dholmes ! src/share/vm/utilities/vmError.cpp Changeset: 8f0e2c77a6da Author: neliasso Date: 2016-02-25 10:42 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/8f0e2c77a6da 8148159: [TESTBUG] TestCompilerDirectivesCompatibility tests fails on non-tiered server VMs Summary: Add whitebox for checking available compilers Reviewed-by: kvn ! src/share/vm/prims/whitebox.cpp ! test/compiler/compilercontrol/TestCompilerDirectivesCompatibilityBase.java ! test/compiler/compilercontrol/TestCompilerDirectivesCompatibilityCommandOff.java ! test/compiler/compilercontrol/TestCompilerDirectivesCompatibilityCommandOn.java ! test/compiler/compilercontrol/TestCompilerDirectivesCompatibilityFlag.java Changeset: 5c91d4315495 Author: neliasso Date: 2016-02-25 10:44 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5c91d4315495 8149789: SIGSEGV in CompileTask::print Summary: Print tasks from active compile threads requires safepoint Reviewed-by: kvn ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/runtime/vm_operations.cpp ! src/share/vm/runtime/vm_operations.hpp ! src/share/vm/services/diagnosticCommand.cpp Changeset: f4915777c32c Author: neliasso Date: 2016-02-25 10:44 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f4915777c32c 8069160: serviceability/dcmd/compiler/CompilerQueueTest.java fails due to class not found Summary: Use whitebox to test specific cases making test less fragile Reviewed-by: kvn ! test/serviceability/dcmd/compiler/CompilerQueueTest.java Changeset: dc9643c06abb Author: neliasso Date: 2016-02-25 11:17 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/dc9643c06abb Merge Changeset: fb4ca0e4cc42 Author: shade Date: 2016-02-25 15:10 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/fb4ca0e4cc42 8150534: C1 compilation fails with "Constant field loads are folded during parsing" Reviewed-by: vlivanov, thartmann ! src/share/vm/c1/c1_Canonicalizer.cpp ! test/compiler/c1/CanonicalizeArrayLength.java Changeset: 3f537d831d9d Author: aph Date: 2016-02-17 14:06 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3f537d831d9d 8150045: arraycopy causes segfaults in SATB during garbage collection Reviewed-by: roland ! src/cpu/aarch64/vm/stubGenerator_aarch64.cpp Changeset: fd111e8fa412 Author: aph Date: 2016-02-24 12:38 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/fd111e8fa412 Merge - src/share/vm/jvmci/commandLineFlagConstraintsJVMCI.cpp - src/share/vm/jvmci/commandLineFlagConstraintsJVMCI.hpp Changeset: 57f7f86ae5c8 Author: aph Date: 2016-02-25 14:47 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/57f7f86ae5c8 Merge Changeset: 1e4d74c1b3d0 Author: twisti Date: 2016-02-24 09:22 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1e4d74c1b3d0 8150561: [AArch64] JVMCI improvements Reviewed-by: kvn ! src/cpu/aarch64/vm/jvmciCodeInstaller_aarch64.cpp ! src/cpu/aarch64/vm/nativeInst_aarch64.hpp ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java ! src/share/vm/jvmci/jvmciCodeInstaller.cpp ! src/share/vm/jvmci/vmStructs_jvmci.cpp ! src/share/vm/runtime/frame.cpp Changeset: b71124b1ffab Author: vlivanov Date: 2016-02-26 01:58 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b71124b1ffab 8150186: Folding mismatched accesses with @Stable is incorrect Reviewed-by: kvn, jrose, shade ! src/share/vm/ci/ciArray.cpp ! src/share/vm/opto/memnode.cpp + test/compiler/unsafe/UnsafeGetStableArrayElement.java Changeset: cb59d649446d Author: vlivanov Date: 2016-02-26 01:58 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/cb59d649446d 8150436: Incorrect invocation mode when linkToInteface linker is eliminated Reviewed-by: kvn, shade ! src/share/vm/runtime/sharedRuntime.cpp ! test/compiler/jsr292/NonInlinedCall/InvokeTest.java Changeset: 01601d6e4a94 Author: vlivanov Date: 2016-02-26 15:54 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/01601d6e4a94 8068038: C2: large constant offsets aren't handled on SPARC Reviewed-by: kvn ! src/cpu/sparc/vm/sparc.ad Changeset: dafb744545f3 Author: twisti Date: 2016-02-26 11:13 -1000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/dafb744545f3 8150738: [JVMCI] runtime/CommandLine/TraceExceptionsTest.java fails with: java.lang.RuntimeException: '' missing Reviewed-by: coleenp ! src/share/vm/jvmci/jvmciRuntime.cpp Changeset: 4c5fe83bf5a6 Author: thartmann Date: 2016-02-29 09:02 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4c5fe83bf5a6 Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/services/diagnosticCommand.cpp Changeset: c6c141c46516 Author: zmajo Date: 2016-02-29 13:02 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c6c141c46516 8150349: Reduce the execution time of the hotspot_compiler_3 group Summary: Exclude long-running intrinsic-related tests that check functionality that is not likely to be changed soon. Reviewed-by: kvn, neliasso ! test/TEST.groups Changeset: e3dbb1e46e26 Author: redestad Date: 2016-02-29 15:05 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e3dbb1e46e26 8150720: Cleanup code around PrintOptoStatistics Reviewed-by: kvn, shade, vlivanov ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse2.cpp Changeset: d882a7c5753e Author: vlivanov Date: 2016-02-29 23:46 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d882a7c5753e 8150543: Mismatched access detection is inaccurate Reviewed-by: kvn, shade ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/memnode.cpp ! test/compiler/unsafe/UnsafeGetConstantField.java ! test/compiler/unsafe/UnsafeGetStableArrayElement.java Changeset: ccfc1e54bbcd Author: hshi Date: 2016-02-24 04:45 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ccfc1e54bbcd 8149733: AArch64: refactor array_equals/string_equals Summary: combine similar code for string_equals/char_array_equals/byte_array_equals into same implemenation Reviewed-by: aph, shade ! src/cpu/aarch64/vm/aarch64.ad ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/aarch64/vm/macroAssembler_aarch64.hpp Changeset: fe9e0761c550 Author: fyang Date: 2016-02-17 20:19 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/fe9e0761c550 8150038: aarch64: make use of CBZ and CBNZ when comparing narrow pointer with zero Summary: aarch64: c2 make use of CBZ and CBNZ when comparing narrow pointer with zero Reviewed-by: aph Contributed-by: felix.yang at linaro.org ! src/cpu/aarch64/vm/aarch64.ad Changeset: 161aa091d841 Author: fyang Date: 2016-02-18 21:53 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/161aa091d841 8149907: aarch64: use load/store pair instructions in call_stub Summary: aarch64: make use of load/store pair instructions in call_stub to save space Reviewed-by: aph Contributed-by: felix.yang at linaro.org ! src/cpu/aarch64/vm/stubGenerator_aarch64.cpp Changeset: 77836bd8ec95 Author: fyang Date: 2016-02-19 17:12 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/77836bd8ec95 8150229: aarch64: pipeline class for several instructions is not set correctly Summary: aarch64: c2 fix pipeline class for several instructions. Reviewed-by: aph Contributed-by: felix.yang at linaro.org ! src/cpu/aarch64/vm/aarch64.ad Changeset: 1b6fb1351811 Author: vlivanov Date: 2016-03-01 20:06 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1b6fb1351811 8150933: System::arraycopy intrinsic doesn't mark mismatched loads Reviewed-by: kvn, shade ! src/share/vm/opto/macroArrayCopy.cpp ! src/share/vm/opto/memnode.cpp Changeset: 5bc1bcc01d13 Author: twisti Date: 2016-02-26 13:21 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5bc1bcc01d13 8150727: [JVMCI] add LoadLoad to the implicit memory barriers on AMD64 Reviewed-by: rschatz, twisti Contributed-by: Benoit Daloze ! src/jdk.vm.ci/share/classes/jdk.vm.ci.amd64/src/jdk/vm/ci/amd64/AMD64.java Changeset: 8a8b603542ca Author: twisti Date: 2016-03-01 18:29 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/8a8b603542ca Merge Changeset: 41d58013ab47 Author: cjplummer Date: 2016-02-26 09:13 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/41d58013ab47 8147978: Remove Method::_method_data for C1 Summary: Method::_method_data field removed when not using C2 or JVMCI Reviewed-by: dholmes, kvn ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/macros.hpp Changeset: be30670bbd35 Author: iveresov Date: 2016-03-01 12:35 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/be30670bbd35 8134119: Use new API to get cache line sizes Summary: Using new sysconf and sysinfo API on Solaris 12, avoid using libpicl and libkstat. Reviewed-by: kvn ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.hpp ! src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp Changeset: 13d02d8f9616 Author: iveresov Date: 2016-03-01 21:56 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/13d02d8f9616 Merge Changeset: 35345fc5423d Author: shade Date: 2016-03-02 12:29 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/35345fc5423d 8151017: [TESTBUG] test/compiler/c1/CanonicalizeArrayLength does not work on product builds Reviewed-by: thartmann, zmajo ! test/compiler/c1/CanonicalizeArrayLength.java Changeset: 323b8370b0f6 Author: vlivanov Date: 2016-03-02 15:42 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/323b8370b0f6 8151020: [TESTBUG] UnsafeGetStableArrayElement::testL_* fail intermittently Reviewed-by: zmajo, shade ! test/compiler/unsafe/UnsafeGetStableArrayElement.java Changeset: 13f653804b97 Author: thartmann Date: 2016-03-03 13:18 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/13f653804b97 8151130: [BACKOUT] Remove Method::_method_data for C1 Summary: Backing out the fix for JDK-8147978 because it fails and blocks integration. Reviewed-by: vlivanov, zmajo ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/macros.hpp Changeset: 5df9d1b68979 Author: vlivanov Date: 2016-03-03 16:46 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5df9d1b68979 8151157: Quarantine test/compiler/unsafe/UnsafeGetStableArrayElement.java Reviewed-by: zmajo, thartmann ! test/compiler/unsafe/UnsafeGetStableArrayElement.java Changeset: 3c531219fc38 Author: vlivanov Date: 2016-03-03 14:07 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3c531219fc38 Merge Changeset: 8750312a7452 Author: aeriksso Date: 2016-02-18 16:15 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/8750312a7452 8149743: JVM crash after debugger hotswap with lambdas Reviewed-by: sspitsyn, coleenp, dcubed ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 422d373c4e3f Author: kbarrett Date: 2016-02-24 13:18 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/422d373c4e3f 8150419: Cleanup BufferNode API Summary: Fewer public functions, cleanup allocation. Reviewed-by: tschatzl, drwhite ! src/share/vm/gc/g1/ptrQueue.cpp ! src/share/vm/gc/g1/ptrQueue.hpp Changeset: 1c53edac6621 Author: stuefe Date: 2016-02-24 18:06 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1c53edac6621 8149036: Add tracing for thread related events at os level Reviewed-by: coleenp, mlarsson, dholmes ! src/os/aix/vm/os_aix.cpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/posix/vm/os_posix.cpp ! src/os/posix/vm/os_posix.hpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/logging/logTag.hpp ! src/share/vm/runtime/thread.cpp Changeset: 3c856080f830 Author: coleenp Date: 2016-02-24 21:55 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3c856080f830 Merge Changeset: c487d066a42d Author: dholmes Date: 2016-02-24 16:04 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c487d066a42d 8150506: Remove unused locks Reviewed-by: mgronlun, tschatzl, mgerdin, coleenp ! src/share/vm/runtime/fprofiler.cpp ! src/share/vm/runtime/mutex.cpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp Changeset: 6ab1b2eaa26f Author: dholmes Date: 2016-02-24 22:22 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6ab1b2eaa26f Merge Changeset: e06c15b0844e Author: kbarrett Date: 2016-02-23 18:58 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e06c15b0844e 8150426: Wrong cast in metadata_at_put Summary: Fix cast. Reviewed-by: dholmes, coleenp, jprovino Contributed-by: timo.kinnunen at gmail.com ! src/share/vm/oops/typeArrayOop.hpp Changeset: e4af68ae1ece Author: kbarrett Date: 2016-02-25 01:23 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e4af68ae1ece Merge Changeset: 6416cd3a77b3 Author: ctornqvi Date: 2016-02-24 16:34 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6416cd3a77b3 8150490: Update OS detection code to recognize Windows Server 2016 Reviewed-by: mgronlun, alanb, dholmes ! src/os/windows/vm/os_windows.cpp Changeset: ca074069a447 Author: ctornqvi Date: 2016-02-25 01:55 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ca074069a447 Merge ! src/os/windows/vm/os_windows.cpp Changeset: a4b13629ac4f Author: drwhite Date: 2016-02-24 09:25 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a4b13629ac4f 8134992: vm/gc/compact/Compact_InternedStrings_Strings failed due to a malloc() failure Reviewed-by: mgerdin, brutisso ! src/share/vm/gc/shared/collectedHeap.cpp Changeset: c313340df3d5 Author: mockner Date: 2016-02-25 13:09 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c313340df3d5 8150103: Convert TraceClassPaths to Unified Logging Summary: TraceClassPaths has been reimplemented with Unified Logging Reviewed-by: coleenp, dholmes, iklam ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoader.hpp ! src/share/vm/classfile/sharedPathsMiscInfo.cpp ! src/share/vm/classfile/sharedPathsMiscInfo.hpp ! src/share/vm/logging/logTag.hpp ! src/share/vm/memory/filemap.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 69f183dacdb4 Author: mgerdin Date: 2016-02-25 11:20 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/69f183dacdb4 8150390: Move rs length sampling data to the sampling thread Reviewed-by: drwhite, jwilhelm ! src/share/vm/gc/g1/g1CollectedHeap.cpp ! src/share/vm/gc/g1/g1CollectedHeap.hpp ! src/share/vm/gc/g1/g1CollectorPolicy.cpp ! src/share/vm/gc/g1/g1CollectorPolicy.hpp ! src/share/vm/gc/g1/g1YoungRemSetSamplingThread.cpp ! src/share/vm/gc/g1/youngList.cpp ! src/share/vm/gc/g1/youngList.hpp Changeset: dcac6f3d1255 Author: tschatzl Date: 2016-02-26 13:02 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/dcac6f3d1255 8140777: Make Adaptive IHOP logging information the same as JFR logging Reviewed-by: tbenson, jmasa ! src/share/vm/gc/g1/g1IHOPControl.cpp Changeset: d2e7206f86f8 Author: tschatzl Date: 2016-02-26 13:02 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d2e7206f86f8 8076463: Add logging for the preserve CM referents task Summary: Add logging and do minor refactoring to CM referents handling task. Reviewed-by: jmasa ! src/share/vm/gc/g1/g1CollectedHeap.cpp ! src/share/vm/gc/g1/g1CollectedHeap.hpp ! src/share/vm/gc/g1/g1GCPhaseTimes.cpp ! src/share/vm/gc/g1/g1GCPhaseTimes.hpp ! test/gc/g1/TestGCLogMessages.java Changeset: bf7095ff645e Author: tschatzl Date: 2016-02-26 13:02 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/bf7095ff645e 8150630: Add logging for ParScanThreadState merge phase Summary: Improve visibility of the per-thread scan state merge phase by adding appropriate logging. Reviewed-by: jmasa, tbenson ! src/share/vm/gc/g1/g1CollectedHeap.cpp ! src/share/vm/gc/g1/g1CollectedHeap.hpp ! src/share/vm/gc/g1/g1GCPhaseTimes.cpp ! src/share/vm/gc/g1/g1GCPhaseTimes.hpp ! test/gc/g1/TestGCLogMessages.java Changeset: 96124925d5aa Author: tschatzl Date: 2016-02-26 13:02 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/96124925d5aa 8150629: Initializing all ParScanThreadStates causes significant unaccounted "Other" times Summary: Lazily allocate ParScanThreadStates within the worker threads instead of doing this work upfront serially. Reviewed-by: mgerdin, jmasa ! src/share/vm/gc/g1/g1ParScanThreadState.cpp ! src/share/vm/gc/g1/g1ParScanThreadState.hpp Changeset: 8c1a2e4f633f Author: tschatzl Date: 2016-02-26 17:55 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/8c1a2e4f633f Merge ! src/share/vm/gc/g1/g1CollectedHeap.cpp ! src/share/vm/gc/g1/g1CollectedHeap.hpp Changeset: 373a5a1f865c Author: jprovino Date: 2016-02-26 14:02 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/373a5a1f865c 8139651: ConcurrentG1Refine uses ints for many of its members that should be unsigned types Summary: ints need to be changed to size_t Reviewed-by: kbarrett, tbenson ! src/share/vm/gc/g1/concurrentG1Refine.cpp ! src/share/vm/gc/g1/concurrentG1Refine.hpp ! src/share/vm/gc/g1/concurrentG1RefineThread.cpp ! src/share/vm/gc/g1/concurrentG1RefineThread.hpp ! src/share/vm/gc/g1/dirtyCardQueue.cpp ! src/share/vm/gc/g1/dirtyCardQueue.hpp ! src/share/vm/gc/g1/g1CollectedHeap.cpp ! src/share/vm/gc/g1/g1CollectorPolicy.cpp ! src/share/vm/gc/g1/g1ConcurrentMark.cpp ! src/share/vm/gc/g1/g1RemSet.cpp ! src/share/vm/gc/g1/g1_globals.hpp ! src/share/vm/gc/g1/ptrQueue.cpp ! src/share/vm/gc/g1/ptrQueue.hpp Changeset: 63a9e10565c4 Author: jprovino Date: 2016-02-27 00:07 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/63a9e10565c4 Merge ! src/share/vm/gc/g1/g1CollectedHeap.cpp Changeset: d509f28e025c Author: kbarrett Date: 2016-02-28 12:22 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d509f28e025c 8150421: Delete experimental G1UseConcMarkReferenceProcessing Summary: Removed the option and supporting code. Reviewed-by: jmasa, tamao ! src/share/vm/gc/g1/g1ConcurrentMark.cpp ! src/share/vm/gc/g1/g1_globals.hpp Changeset: a39b4d597162 Author: brutisso Date: 2016-02-29 13:06 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a39b4d597162 8150068: Log the main G1 phases at info level Reviewed-by: sjohanss, tschatzl ! src/share/vm/gc/g1/g1CollectorPolicy.cpp ! src/share/vm/gc/g1/g1GCPhaseTimes.cpp ! src/share/vm/gc/g1/g1GCPhaseTimes.hpp ! src/share/vm/gc/g1/g1HotCardCache.cpp ! src/share/vm/gc/g1/g1RemSet.cpp ! src/share/vm/gc/g1/workerDataArray.cpp ! src/share/vm/gc/g1/workerDataArray.hpp ! src/share/vm/gc/g1/workerDataArray.inline.hpp ! src/share/vm/logging/logPrefix.hpp ! test/gc/g1/TestGCLogMessages.java Changeset: 36aaa9ceed16 Author: aeriksso Date: 2016-02-26 16:28 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/36aaa9ceed16 8144732: VM_HeapDumper hits assert with bad dump_len Reviewed-by: dsamersoff ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/services/heapDumper.cpp Changeset: b1f8f786bf0d Author: jwilhelm Date: 2016-02-29 15:24 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b1f8f786bf0d Merge Changeset: 1af0e347a76e Author: jwilhelm Date: 2016-02-29 15:42 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1af0e347a76e Merge Changeset: 4766e03eaf19 Author: drwhite Date: 2016-02-29 11:32 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4766e03eaf19 8140600: Convert unnecessarily malloc'd Monitors to value members Summary: Change a malloc'd monitor into an embedded monitor. Reviewed-by: tschatzl, kbarrett ! src/share/vm/gc/g1/g1YoungRemSetSamplingThread.cpp ! src/share/vm/gc/g1/g1YoungRemSetSamplingThread.hpp Changeset: f146301c971f Author: stuefe Date: 2016-02-29 08:50 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f146301c971f 8150619: Improve thread based logging introduced with 8149036 Reviewed-by: coleenp, dholmes ! src/os/aix/vm/os_aix.cpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/thread.cpp + test/runtime/logging/ThreadLoggingTest.java Changeset: 2778191158c6 Author: dholmes Date: 2016-02-29 23:35 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2778191158c6 Merge Changeset: 62d355fd1283 Author: mockner Date: 2016-02-29 16:58 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/62d355fd1283 8149064: TraceProtectionDomainVerification has been converted to Unified Logging. Summary: TraceProtectionDomainVerification has been converted to Unified Logging with tag protectiondomain. Reviewed-by: coleenp, iklam ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/dictionary.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/logging/logTag.hpp ! src/share/vm/runtime/globals.hpp + test/runtime/logging/ProtectionDomainVerificationTest.java Changeset: c13e1f468027 Author: mockner Date: 2016-03-01 02:15 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c13e1f468027 Merge Changeset: 5c4f8192021e Author: erikj Date: 2016-03-01 09:42 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5c4f8192021e 8150822: Fix typo in JDK-8150201 Reviewed-by: ihse, dholmes ! make/solaris/makefiles/amd64.make Changeset: 6b59d8ba8fc5 Author: mgronlun Date: 2016-03-01 23:46 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6b59d8ba8fc5 8143226: Minor updates to Event Based tracing Reviewed-by: jbachorik, egahlin ! make/aix/makefiles/trace.make ! make/bsd/makefiles/trace.make ! make/linux/makefiles/trace.make ! make/solaris/makefiles/trace.make ! make/windows/makefiles/trace.make ! src/share/vm/c1/c1_Compiler.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/vmSymbols.cpp ! src/share/vm/gc/shared/copyFailedInfo.hpp ! src/share/vm/gc/shared/gcTraceSend.cpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/trace/trace.xml ! src/share/vm/trace/traceBackend.hpp ! src/share/vm/trace/traceDataTypes.hpp ! src/share/vm/trace/traceEvent.hpp ! src/share/vm/trace/traceEventClasses.xsl ! src/share/vm/trace/traceEventIds.xsl ! src/share/vm/trace/traceMacros.hpp ! src/share/vm/trace/tracetypes.xml ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/hashtable.cpp Changeset: 56fbd5c60c96 Author: mgronlun Date: 2016-03-01 23:47 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/56fbd5c60c96 8066814: Reduce accessibility in TraceEvent Reviewed-by: egahlin, jbachorik ! src/share/vm/trace/traceEvent.hpp Changeset: a6ff1064c4d7 Author: mgronlun Date: 2016-03-01 23:48 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a6ff1064c4d7 8147442: Event-based tracing to allow for tracing Klass creation Reviewed-by: jbachorik, egahlin ! src/share/vm/classfile/klassFactory.cpp ! src/share/vm/trace/traceMacros.hpp Changeset: 7f44dc58ebb9 Author: brutisso Date: 2016-03-02 08:41 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7f44dc58ebb9 8058944: Unify the reporting strings for the GC debug level logging in G1 Reviewed-by: sjohanss, tschatzl ! src/share/vm/gc/g1/g1ConcurrentMark.cpp ! src/share/vm/gc/g1/g1GCPhaseTimes.cpp Changeset: 752f25ffe2cb Author: dsamersoff Date: 2016-03-02 17:08 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/752f25ffe2cb 8150318: serviceability/dcmd/jvmti/LoadAgentDcmdTest.java - Could not find JDK_DIR/lib/x86_64/libinstrument.so Summary: refactor test Reviewed-by: jbachorik, sspitsyn ! test/serviceability/dcmd/jvmti/LoadAgentDcmdTest.java - test/serviceability/dcmd/jvmti/LoadJavaAgentDcmdTest.java ! test/testlibrary/jdk/test/lib/Platform.java Changeset: 1286286af412 Author: tschatzl Date: 2016-03-02 15:55 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1286286af412 8147121: Evacuation failure allocation statistics added too late Summary: Move adding evacuation failure statistics to after free_collection_set. Reviewed-by: brutisso, drwhite ! src/share/vm/gc/g1/g1CollectedHeap.cpp Changeset: bab3650ec5e6 Author: tschatzl Date: 2016-03-02 15:57 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/bab3650ec5e6 8141141: Young and Old gen PLAB stats are similar in output with -XX:+PrintPLAB Summary: Improve PLAB statistic by adding generation, output values are now in bytes, including units, and split it into multiple messages. Reviewed-by: brutisso, sjohanss ! src/share/vm/gc/cms/parNewGeneration.cpp ! src/share/vm/gc/g1/g1CollectedHeap.cpp ! src/share/vm/gc/g1/g1EvacStats.cpp ! src/share/vm/gc/g1/g1EvacStats.hpp ! src/share/vm/gc/shared/plab.cpp ! src/share/vm/gc/shared/plab.hpp ! test/gc/g1/TestPLABOutput.java ! test/gc/g1/plab/TestPLABPromotion.java ! test/gc/g1/plab/TestPLABResize.java ! test/gc/g1/plab/lib/LogParser.java Changeset: e0f999893ca8 Author: tschatzl Date: 2016-03-02 17:08 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e0f999893ca8 Merge Changeset: d7750079ebe0 Author: rprotacio Date: 2016-03-02 10:59 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d7750079ebe0 8150746: runtime/logging/ItablesTest.java fails with: java.lang.RuntimeException: 'Resolving: klass: ' missing from stdout/stderr Summary: Deleted logging line from code and test because unnecessary Reviewed-by: twisti, coleenp ! src/share/vm/interpreter/interpreterRuntime.cpp ! test/runtime/logging/ItablesTest.java Changeset: 8d89fd576550 Author: coleenp Date: 2016-03-02 17:09 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/8d89fd576550 Merge Changeset: 55fe28454251 Author: poonam Date: 2016-02-25 11:27 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/55fe28454251 8150002: Check for the validity of oop before printing it in verify_remembered_set Summary: Adding missing check for valid oop. Reviewed-by: dcubed Contributed-by: Shafi Ahmad ! src/share/vm/gc/g1/heapRegion.cpp Changeset: b10d60e33756 Author: poonam Date: 2016-03-02 19:15 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b10d60e33756 Merge Changeset: ac4b6ebbdd6c Author: rprotacio Date: 2016-03-02 15:10 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ac4b6ebbdd6c 8145098: JNI GetVersion should return JNI_VERSION_9 Summary: Updated JNI_VERSION for current version to be JNI_VERSION_9 Reviewed-by: hseigel, gtriantafill, dholmes, alanb ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jni.h ! src/share/vm/runtime/thread.cpp ! test/native_sanity/JniVersion.java Changeset: 69f55dd802b8 Author: hseigel Date: 2016-03-02 23:48 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/69f55dd802b8 Merge Changeset: 11e230ff047a Author: gziemski Date: 2016-03-02 14:36 -0600 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/11e230ff047a 8146849: Remove TraceJNIHandleAllocation rather than converting to UL Summary: Removed TraceJNIHandleAllocation Reviewed-by: coleenp, dholmes ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/jniHandles.cpp Changeset: eb16739251ff Author: gziemski Date: 2016-03-03 00:49 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/eb16739251ff Merge Changeset: 904b2fb4a2f6 Author: dsamersoff Date: 2016-03-03 11:28 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/904b2fb4a2f6 8150723: HSDB toolbar icons are missing. Reviewed-by: erikj, dsamersoff Contributed-by: yasuenag at gmail.com - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/development/Server16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/development/Server24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/About16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/About24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Delete16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Delete24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Find16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Help16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Help24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/History16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/History24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Information16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Information24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/New16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/New24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Open16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Open24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Save24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/SaveAs16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/SaveAs24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Zoom16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/ZoomIn16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/ZoomIn24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/navigation/Down16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/navigation/Up16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/text/AlignCenter16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/text/AlignCenter24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/text/AlignLeft16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/text/AlignLeft24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/text/AlignRight16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/text/AlignRight24.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/development/Server16.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/development/Server24.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/general/About16.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/general/About24.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/general/Delete16.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/general/Delete24.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/general/Find16.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/general/Help16.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/general/Help24.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/general/History16.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/general/History24.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/general/Information16.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/general/Information24.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/general/New16.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/general/New24.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/general/Open16.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/general/Open24.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/general/Save24.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/general/SaveAs16.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/general/SaveAs24.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/general/Zoom16.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/general/ZoomIn16.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/general/ZoomIn24.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/navigation/Down16.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/navigation/Up16.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/text/AlignCenter16.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/text/AlignCenter24.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/text/AlignLeft16.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/text/AlignLeft24.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/text/AlignRight16.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/text/AlignRight24.gif Changeset: 93826ec555da Author: aeriksso Date: 2016-03-03 12:36 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/93826ec555da 8150986: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java failing because expects HPROF JAVA PROFILE 1.0.1 file format Reviewed-by: dcubed, dsamersoff ! test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java Changeset: 65797e98baf2 Author: jprovino Date: 2016-03-03 12:20 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/65797e98baf2 8150984: Invalid VM argument causes crash -XX:G1ConcRefinementServiceIntervalMillis=2147483648 Summary: Change maximum range so it can't be negative Reviewed-by: kbarrett, sangheki ! src/share/vm/gc/g1/concurrentG1RefineThread.cpp ! src/share/vm/gc/g1/g1YoungRemSetSamplingThread.cpp ! src/share/vm/gc/g1/g1_globals.hpp Changeset: 27b6bff990d5 Author: jprovino Date: 2016-03-03 17:33 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/27b6bff990d5 Merge - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/development/Server16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/development/Server24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/About16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/About24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Delete16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Delete24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Find16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Help16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Help24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/History16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/History24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Information16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Information24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/New16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/New24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Open16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Open24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Save24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/SaveAs16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/SaveAs24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Zoom16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/ZoomIn16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/ZoomIn24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/navigation/Down16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/navigation/Up16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/text/AlignCenter16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/text/AlignCenter24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/text/AlignLeft16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/text/AlignLeft24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/text/AlignRight16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/text/AlignRight24.gif - test/serviceability/dcmd/jvmti/LoadJavaAgentDcmdTest.java Changeset: 7b19da0e0dd6 Author: jwilhelm Date: 2016-03-05 10:10 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7b19da0e0dd6 Merge - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/development/Server16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/development/Server24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/About16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/About24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Delete16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Delete24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Find16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Help16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Help24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/History16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/History24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Information16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Information24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/New16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/New24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Open16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Open24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Save24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/SaveAs16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/SaveAs24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Zoom16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/ZoomIn16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/ZoomIn24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/navigation/Down16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/navigation/Up16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/text/AlignCenter16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/text/AlignCenter24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/text/AlignLeft16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/text/AlignLeft24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/text/AlignRight16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/text/AlignRight24.gif ! src/share/vm/classfile/vmSymbols.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/runtime/arguments.cpp - test/serviceability/dcmd/jvmti/LoadJavaAgentDcmdTest.java Changeset: 797e6aac6d53 Author: amurillo Date: 2016-03-05 20:46 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/797e6aac6d53 Merge - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/development/Server16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/development/Server24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/About16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/About24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Delete16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Delete24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Find16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Help16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Help24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/History16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/History24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Information16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Information24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/New16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/New24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Open16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Open24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Save24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/SaveAs16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/SaveAs24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Zoom16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/ZoomIn16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/ZoomIn24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/navigation/Down16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/navigation/Up16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/text/AlignCenter16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/text/AlignCenter24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/text/AlignLeft16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/text/AlignLeft24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/text/AlignRight16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/text/AlignRight24.gif ! src/share/vm/classfile/vmSymbols.hpp - src/share/vm/jvmci/commandLineFlagConstraintsJVMCI.cpp - src/share/vm/jvmci/commandLineFlagConstraintsJVMCI.hpp ! src/share/vm/runtime/thread.cpp - test/serviceability/dcmd/jvmti/LoadJavaAgentDcmdTest.java Changeset: 2f5d1578b240 Author: lana Date: 2016-03-10 09:50 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2f5d1578b240 Merge - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/development/Server16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/development/Server24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/About16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/About24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Delete16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Delete24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Find16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Help16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Help24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/History16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/History24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Information16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Information24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/New16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/New24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Open16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Open24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Save24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/SaveAs16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/SaveAs24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Zoom16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/ZoomIn16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/ZoomIn24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/navigation/Down16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/navigation/Up16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/text/AlignCenter16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/text/AlignCenter24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/text/AlignLeft16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/text/AlignLeft24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/text/AlignRight16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/text/AlignRight24.gif - src/share/vm/jvmci/commandLineFlagConstraintsJVMCI.cpp - src/share/vm/jvmci/commandLineFlagConstraintsJVMCI.hpp - test/serviceability/dcmd/jvmti/LoadJavaAgentDcmdTest.java Changeset: 8dd9a87aaae2 Author: henryjen Date: 2016-03-14 20:44 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/8dd9a87aaae2 Merge ! make/test/JtregNative.gmk - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/development/Server16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/development/Server24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/About16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/About24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Delete16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Delete24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Find16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Help16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Help24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/History16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/History24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Information16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Information24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/New16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/New24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Open16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Open24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Save24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/SaveAs16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/SaveAs24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Zoom16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/ZoomIn16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/ZoomIn24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/navigation/Down16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/navigation/Up16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/text/AlignCenter16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/text/AlignCenter24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/text/AlignLeft16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/text/AlignLeft24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/text/AlignRight16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/text/AlignRight24.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/development/Server16.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/development/Server24.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/general/About16.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/general/About24.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/general/Delete16.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/general/Delete24.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/general/Find16.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/general/Help16.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/general/Help24.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/general/History16.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/general/History24.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/general/Information16.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/general/Information24.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/general/New16.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/general/New24.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/general/Open16.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/general/Open24.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/general/Save24.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/general/SaveAs16.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/general/SaveAs24.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/general/Zoom16.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/general/ZoomIn16.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/general/ZoomIn24.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/navigation/Down16.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/navigation/Up16.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/text/AlignCenter16.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/text/AlignCenter24.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/text/AlignLeft16.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/text/AlignLeft24.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/text/AlignRight16.gif + src/jdk.hotspot.agent/share/classes/toolbarButtonGraphics/text/AlignRight24.gif ! src/os/aix/vm/os_aix.cpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoader.hpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/klassFactory.cpp ! src/share/vm/classfile/sharedPathsMiscInfo.cpp ! src/share/vm/classfile/sharedPathsMiscInfo.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp - src/share/vm/jvmci/commandLineFlagConstraintsJVMCI.cpp - src/share/vm/jvmci/commandLineFlagConstraintsJVMCI.hpp ! src/share/vm/logging/logTag.hpp ! src/share/vm/memory/filemap.cpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jni.h ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/jniHandles.cpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/trace/traceDataTypes.hpp ! src/share/vm/trace/traceMacros.hpp ! src/share/vm/trace/traceTypes.xsl ! src/share/vm/trace/tracetypes.xml ! test/compiler/jsr292/NonInlinedCall/InvokeTest.java ! test/compiler/jvmci/compilerToVM/LookupKlassInPoolTest.java ! test/compiler/jvmci/compilerToVM/ResolveConstantInPoolTest.java ! test/compiler/jvmci/compilerToVM/ResolveTypeInPoolTest.java ! test/compiler/unsafe/UnsafeGetConstantField.java ! test/serviceability/dcmd/compiler/CompilerQueueTest.java - test/serviceability/dcmd/jvmti/LoadJavaAgentDcmdTest.java ! test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java Changeset: 4f7a2ef050cb Author: henryjen Date: 2016-03-14 22:12 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4f7a2ef050cb Merge ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoader.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/method.cpp From mandy.chung at oracle.com Tue Mar 15 06:28:09 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 15 Mar 2016 06:28:09 +0000 Subject: hg: jigsaw/jake/jdk: 68 new changesets Message-ID: <201603150628.u2F6SBev022594@aojmv0008.oracle.com> Changeset: dbb0fd7f2a2b Author: amlu Date: 2016-03-08 09:33 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/dbb0fd7f2a2b 8151352: jdk/test/sample fails with "effective library path is outside the test suite" Reviewed-by: darcy Contributed-by: Felix Yang + test/sample/TEST.properties ! test/sample/chatserver/ChatTest.java ! test/sample/mergesort/MergeSortTest.java Changeset: 81cf21b33839 Author: mli Date: 2016-03-08 11:01 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/81cf21b33839 8143610: (dc) java/nio/channels/DatagramChannel/AdaptDatagramSocket.java failed intermittently due to SocketTimeoutException Reviewed-by: alanb ! test/java/nio/channels/DatagramChannel/AdaptDatagramSocket.java Changeset: c82be424393e Author: chegar Date: 2016-03-08 12:11 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c82be424393e 8151384: Improve String.CASE_INSENSITIVE_ORDER and remove sun.misc.ASCIICaseInsensitiveComparator Reviewed-by: shade, sherman ! src/java.base/share/classes/java/lang/String.java ! src/java.base/share/classes/java/lang/StringLatin1.java ! src/java.base/share/classes/java/lang/StringUTF16.java ! src/java.base/share/classes/java/nio/charset/Charset.java ! src/java.base/share/classes/java/util/jar/Attributes.java - src/java.base/share/classes/sun/misc/ASCIICaseInsensitiveComparator.java ! src/jdk.charsets/share/classes/sun/nio/cs/ext/AbstractCharsetProvider.java Changeset: 19fd39919452 Author: bchristi Date: 2016-03-08 11:36 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/19fd39919452 8148187: Remove OS X-specific com.apple.concurrent package Summary: Removed jdk.deploy.osx module (including com.apple.concurrent) Reviewed-by: alanb, erikj, mchung ! make/lib/Lib-java.desktop.gmk - make/lib/Lib-jdk.deploy.osx.gmk + make/lib/LibosxLibraries.gmk ! make/src/classes/build/tools/module/boot.modules + src/java.desktop/macosx/native/libosx/CFileManager.m - src/jdk.deploy.osx/macosx/classes/com/apple/concurrent/Dispatch.java - src/jdk.deploy.osx/macosx/classes/com/apple/concurrent/LibDispatchConcurrentQueue.java - src/jdk.deploy.osx/macosx/classes/com/apple/concurrent/LibDispatchMainQueue.java - src/jdk.deploy.osx/macosx/classes/com/apple/concurrent/LibDispatchNative.java - src/jdk.deploy.osx/macosx/classes/com/apple/concurrent/LibDispatchQueue.java - src/jdk.deploy.osx/macosx/classes/com/apple/concurrent/LibDispatchRetainedResource.java - src/jdk.deploy.osx/macosx/classes/com/apple/concurrent/LibDispatchSerialQueue.java - src/jdk.deploy.osx/macosx/classes/com/apple/concurrent/package.html - src/jdk.deploy.osx/macosx/native/libosx/CFileManager.m - src/jdk.deploy.osx/macosx/native/libosx/Dispatch.m Changeset: c234831ff203 Author: shade Date: 2016-02-23 17:55 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c234831ff203 8150180: String.value contents should be trusted Reviewed-by: vlivanov, redestad, jrose, twisti ! src/java.base/share/classes/java/lang/String.java Changeset: b00576870c29 Author: shade Date: 2016-02-23 22:10 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b00576870c29 8148146: Integrate new internal Unsafe entry points, and basic intrinsic support for VarHandles Reviewed-by: psandoz, kvn, jrose, adinn, simonis, coleenp ! src/java.base/share/classes/jdk/internal/misc/Unsafe.java Changeset: 0c46dfa7fcf2 Author: zmajo Date: 2016-02-29 07:58 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0c46dfa7fcf2 8148940: java/lang/ref/FinalizeOverride.java can time out due to frequent safepointing Summary: Reduce the freqency of triggering GCs by sleeping between GCs. Reviewed-by: thartmann, shade ! test/java/lang/ref/FinalizeOverride.java Changeset: 3ff1515f4bdd Author: thartmann Date: 2016-02-29 09:02 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3ff1515f4bdd Merge - make/src/classes/build/tools/generatebreakiteratordata/BreakIteratorRBControl.java - src/java.base/share/classes/sun/text/resources/en/FormatData_en.java - src/java.base/share/classes/sun/text/resources/en/JavaTimeSupplementary_en.java - src/java.base/share/classes/sun/text/resources/en/US/FormatData_en_US.java - src/java.base/share/classes/sun/util/resources/en/CalendarData_en.properties - src/java.base/share/classes/sun/util/resources/en/LocaleNames_en.properties - src/java.base/share/classes/sun/util/resources/en/TimeZoneNames_en.java - src/java.base/share/classes/sun/util/resources/en/US/CurrencyNames_en_US.properties - src/jdk.localedata/share/classes/sun/text/resources/ar/CollationData_ar.java - src/jdk.localedata/share/classes/sun/text/resources/ar/FormatData_ar.java - src/jdk.localedata/share/classes/sun/text/resources/ar/JO/FormatData_ar_JO.java - src/jdk.localedata/share/classes/sun/text/resources/ar/JO/JavaTimeSupplementary_ar_JO.java - src/jdk.localedata/share/classes/sun/text/resources/ar/JavaTimeSupplementary_ar.java - src/jdk.localedata/share/classes/sun/text/resources/ar/LB/FormatData_ar_LB.java - src/jdk.localedata/share/classes/sun/text/resources/ar/LB/JavaTimeSupplementary_ar_LB.java - src/jdk.localedata/share/classes/sun/text/resources/ar/SY/FormatData_ar_SY.java - src/jdk.localedata/share/classes/sun/text/resources/ar/SY/JavaTimeSupplementary_ar_SY.java - src/jdk.localedata/share/classes/sun/text/resources/be/BY/FormatData_be_BY.java - src/jdk.localedata/share/classes/sun/text/resources/be/CollationData_be.java - src/jdk.localedata/share/classes/sun/text/resources/be/FormatData_be.java - src/jdk.localedata/share/classes/sun/text/resources/be/JavaTimeSupplementary_be.java - src/jdk.localedata/share/classes/sun/text/resources/bg/BG/FormatData_bg_BG.java - src/jdk.localedata/share/classes/sun/text/resources/bg/CollationData_bg.java - src/jdk.localedata/share/classes/sun/text/resources/bg/FormatData_bg.java - src/jdk.localedata/share/classes/sun/text/resources/bg/JavaTimeSupplementary_bg.java - src/jdk.localedata/share/classes/sun/text/resources/ca/CollationData_ca.java - src/jdk.localedata/share/classes/sun/text/resources/ca/ES/FormatData_ca_ES.java - src/jdk.localedata/share/classes/sun/text/resources/ca/FormatData_ca.java - src/jdk.localedata/share/classes/sun/text/resources/ca/JavaTimeSupplementary_ca.java - src/jdk.localedata/share/classes/sun/text/resources/cs/CZ/FormatData_cs_CZ.java - src/jdk.localedata/share/classes/sun/text/resources/cs/CollationData_cs.java - src/jdk.localedata/share/classes/sun/text/resources/cs/FormatData_cs.java - src/jdk.localedata/share/classes/sun/text/resources/cs/JavaTimeSupplementary_cs.java - src/jdk.localedata/share/classes/sun/text/resources/da/CollationData_da.java - src/jdk.localedata/share/classes/sun/text/resources/da/DK/FormatData_da_DK.java - src/jdk.localedata/share/classes/sun/text/resources/da/FormatData_da.java - src/jdk.localedata/share/classes/sun/text/resources/da/JavaTimeSupplementary_da.java - src/jdk.localedata/share/classes/sun/text/resources/de/AT/FormatData_de_AT.java - src/jdk.localedata/share/classes/sun/text/resources/de/AT/JavaTimeSupplementary_de_AT.java - src/jdk.localedata/share/classes/sun/text/resources/de/CH/FormatData_de_CH.java - src/jdk.localedata/share/classes/sun/text/resources/de/DE/FormatData_de_DE.java - src/jdk.localedata/share/classes/sun/text/resources/de/FormatData_de.java - src/jdk.localedata/share/classes/sun/text/resources/de/JavaTimeSupplementary_de.java - src/jdk.localedata/share/classes/sun/text/resources/de/LU/FormatData_de_LU.java - src/jdk.localedata/share/classes/sun/text/resources/el/CY/FormatData_el_CY.java - src/jdk.localedata/share/classes/sun/text/resources/el/CollationData_el.java - src/jdk.localedata/share/classes/sun/text/resources/el/FormatData_el.java - src/jdk.localedata/share/classes/sun/text/resources/el/GR/FormatData_el_GR.java - src/jdk.localedata/share/classes/sun/text/resources/el/JavaTimeSupplementary_el.java - src/jdk.localedata/share/classes/sun/text/resources/en/AU/FormatData_en_AU.java - src/jdk.localedata/share/classes/sun/text/resources/en/AU/JavaTimeSupplementary_en_AU.java - src/jdk.localedata/share/classes/sun/text/resources/en/CA/FormatData_en_CA.java - src/jdk.localedata/share/classes/sun/text/resources/en/CA/JavaTimeSupplementary_en_CA.java - src/jdk.localedata/share/classes/sun/text/resources/en/GB/FormatData_en_GB.java - src/jdk.localedata/share/classes/sun/text/resources/en/GB/JavaTimeSupplementary_en_GB.java - src/jdk.localedata/share/classes/sun/text/resources/en/IE/FormatData_en_IE.java - src/jdk.localedata/share/classes/sun/text/resources/en/IE/JavaTimeSupplementary_en_IE.java - src/jdk.localedata/share/classes/sun/text/resources/en/IN/FormatData_en_IN.java - src/jdk.localedata/share/classes/sun/text/resources/en/IN/JavaTimeSupplementary_en_IN.java - src/jdk.localedata/share/classes/sun/text/resources/en/MT/FormatData_en_MT.java - src/jdk.localedata/share/classes/sun/text/resources/en/MT/JavaTimeSupplementary_en_MT.java - src/jdk.localedata/share/classes/sun/text/resources/en/NZ/FormatData_en_NZ.java - src/jdk.localedata/share/classes/sun/text/resources/en/NZ/JavaTimeSupplementary_en_NZ.java - src/jdk.localedata/share/classes/sun/text/resources/en/PH/FormatData_en_PH.java - src/jdk.localedata/share/classes/sun/text/resources/en/SG/FormatData_en_SG.java - src/jdk.localedata/share/classes/sun/text/resources/en/SG/JavaTimeSupplementary_en_SG.java - src/jdk.localedata/share/classes/sun/text/resources/en/ZA/FormatData_en_ZA.java - src/jdk.localedata/share/classes/sun/text/resources/en/ZA/JavaTimeSupplementary_en_ZA.java - src/jdk.localedata/share/classes/sun/text/resources/es/AR/FormatData_es_AR.java - src/jdk.localedata/share/classes/sun/text/resources/es/BO/FormatData_es_BO.java - src/jdk.localedata/share/classes/sun/text/resources/es/CL/FormatData_es_CL.java - src/jdk.localedata/share/classes/sun/text/resources/es/CL/JavaTimeSupplementary_es_CL.java - src/jdk.localedata/share/classes/sun/text/resources/es/CO/FormatData_es_CO.java - src/jdk.localedata/share/classes/sun/text/resources/es/CO/JavaTimeSupplementary_es_CO.java - src/jdk.localedata/share/classes/sun/text/resources/es/CR/FormatData_es_CR.java - src/jdk.localedata/share/classes/sun/text/resources/es/CollationData_es.java - src/jdk.localedata/share/classes/sun/text/resources/es/DO/FormatData_es_DO.java - src/jdk.localedata/share/classes/sun/text/resources/es/EC/FormatData_es_EC.java - src/jdk.localedata/share/classes/sun/text/resources/es/ES/FormatData_es_ES.java - src/jdk.localedata/share/classes/sun/text/resources/es/FormatData_es.java - src/jdk.localedata/share/classes/sun/text/resources/es/GT/FormatData_es_GT.java - src/jdk.localedata/share/classes/sun/text/resources/es/GT/JavaTimeSupplementary_es_GT.java - src/jdk.localedata/share/classes/sun/text/resources/es/HN/FormatData_es_HN.java - src/jdk.localedata/share/classes/sun/text/resources/es/HN/JavaTimeSupplementary_es_HN.java - src/jdk.localedata/share/classes/sun/text/resources/es/JavaTimeSupplementary_es.java - src/jdk.localedata/share/classes/sun/text/resources/es/MX/FormatData_es_MX.java - src/jdk.localedata/share/classes/sun/text/resources/es/MX/JavaTimeSupplementary_es_MX.java - src/jdk.localedata/share/classes/sun/text/resources/es/NI/FormatData_es_NI.java - src/jdk.localedata/share/classes/sun/text/resources/es/PA/FormatData_es_PA.java - src/jdk.localedata/share/classes/sun/text/resources/es/PA/JavaTimeSupplementary_es_PA.java - src/jdk.localedata/share/classes/sun/text/resources/es/PE/FormatData_es_PE.java - src/jdk.localedata/share/classes/sun/text/resources/es/PE/JavaTimeSupplementary_es_PE.java - src/jdk.localedata/share/classes/sun/text/resources/es/PR/FormatData_es_PR.java - src/jdk.localedata/share/classes/sun/text/resources/es/PR/JavaTimeSupplementary_es_PR.java - src/jdk.localedata/share/classes/sun/text/resources/es/PY/FormatData_es_PY.java - src/jdk.localedata/share/classes/sun/text/resources/es/SV/FormatData_es_SV.java - src/jdk.localedata/share/classes/sun/text/resources/es/US/FormatData_es_US.java - src/jdk.localedata/share/classes/sun/text/resources/es/UY/FormatData_es_UY.java - src/jdk.localedata/share/classes/sun/text/resources/es/UY/JavaTimeSupplementary_es_UY.java - src/jdk.localedata/share/classes/sun/text/resources/es/VE/FormatData_es_VE.java - src/jdk.localedata/share/classes/sun/text/resources/et/CollationData_et.java - src/jdk.localedata/share/classes/sun/text/resources/et/EE/FormatData_et_EE.java - src/jdk.localedata/share/classes/sun/text/resources/et/FormatData_et.java - src/jdk.localedata/share/classes/sun/text/resources/et/JavaTimeSupplementary_et.java - src/jdk.localedata/share/classes/sun/text/resources/fi/CollationData_fi.java - src/jdk.localedata/share/classes/sun/text/resources/fi/FI/FormatData_fi_FI.java - src/jdk.localedata/share/classes/sun/text/resources/fi/FormatData_fi.java - src/jdk.localedata/share/classes/sun/text/resources/fi/JavaTimeSupplementary_fi.java - src/jdk.localedata/share/classes/sun/text/resources/fr/BE/FormatData_fr_BE.java - src/jdk.localedata/share/classes/sun/text/resources/fr/BE/JavaTimeSupplementary_fr_BE.java - src/jdk.localedata/share/classes/sun/text/resources/fr/CA/FormatData_fr_CA.java - src/jdk.localedata/share/classes/sun/text/resources/fr/CA/JavaTimeSupplementary_fr_CA.java - src/jdk.localedata/share/classes/sun/text/resources/fr/CH/FormatData_fr_CH.java - src/jdk.localedata/share/classes/sun/text/resources/fr/CH/JavaTimeSupplementary_fr_CH.java - src/jdk.localedata/share/classes/sun/text/resources/fr/CollationData_fr.java - src/jdk.localedata/share/classes/sun/text/resources/fr/FR/FormatData_fr_FR.java - src/jdk.localedata/share/classes/sun/text/resources/fr/FormatData_fr.java - src/jdk.localedata/share/classes/sun/text/resources/fr/JavaTimeSupplementary_fr.java - src/jdk.localedata/share/classes/sun/text/resources/ga/FormatData_ga.java - src/jdk.localedata/share/classes/sun/text/resources/ga/IE/FormatData_ga_IE.java - src/jdk.localedata/share/classes/sun/text/resources/ga/JavaTimeSupplementary_ga.java - src/jdk.localedata/share/classes/sun/text/resources/hi/CollationData_hi.java - src/jdk.localedata/share/classes/sun/text/resources/hi/IN/FormatData_hi_IN.java - src/jdk.localedata/share/classes/sun/text/resources/hi/IN/JavaTimeSupplementary_hi_IN.java - src/jdk.localedata/share/classes/sun/text/resources/hr/CollationData_hr.java - src/jdk.localedata/share/classes/sun/text/resources/hr/FormatData_hr.java - src/jdk.localedata/share/classes/sun/text/resources/hr/HR/FormatData_hr_HR.java - src/jdk.localedata/share/classes/sun/text/resources/hr/JavaTimeSupplementary_hr.java - src/jdk.localedata/share/classes/sun/text/resources/hu/CollationData_hu.java - src/jdk.localedata/share/classes/sun/text/resources/hu/FormatData_hu.java - src/jdk.localedata/share/classes/sun/text/resources/hu/HU/FormatData_hu_HU.java - src/jdk.localedata/share/classes/sun/text/resources/hu/JavaTimeSupplementary_hu.java - src/jdk.localedata/share/classes/sun/text/resources/in/FormatData_in.java - src/jdk.localedata/share/classes/sun/text/resources/in/ID/FormatData_in_ID.java - src/jdk.localedata/share/classes/sun/text/resources/is/CollationData_is.java - src/jdk.localedata/share/classes/sun/text/resources/is/FormatData_is.java - src/jdk.localedata/share/classes/sun/text/resources/is/IS/FormatData_is_IS.java - src/jdk.localedata/share/classes/sun/text/resources/is/JavaTimeSupplementary_is.java - src/jdk.localedata/share/classes/sun/text/resources/it/CH/FormatData_it_CH.java - src/jdk.localedata/share/classes/sun/text/resources/it/CH/JavaTimeSupplementary_it_CH.java - src/jdk.localedata/share/classes/sun/text/resources/it/FormatData_it.java - src/jdk.localedata/share/classes/sun/text/resources/it/IT/FormatData_it_IT.java - src/jdk.localedata/share/classes/sun/text/resources/it/JavaTimeSupplementary_it.java - src/jdk.localedata/share/classes/sun/text/resources/iw/CollationData_iw.java - src/jdk.localedata/share/classes/sun/text/resources/iw/FormatData_iw.java - src/jdk.localedata/share/classes/sun/text/resources/iw/IL/FormatData_iw_IL.java - src/jdk.localedata/share/classes/sun/text/resources/iw/IL/JavaTimeSupplementary_iw_IL.java - src/jdk.localedata/share/classes/sun/text/resources/iw/JavaTimeSupplementary_iw.java - src/jdk.localedata/share/classes/sun/text/resources/ja/CollationData_ja.java - src/jdk.localedata/share/classes/sun/text/resources/ja/FormatData_ja.java - src/jdk.localedata/share/classes/sun/text/resources/ja/JP/FormatData_ja_JP.java - src/jdk.localedata/share/classes/sun/text/resources/ja/JavaTimeSupplementary_ja.java - src/jdk.localedata/share/classes/sun/text/resources/ko/CollationData_ko.java - src/jdk.localedata/share/classes/sun/text/resources/ko/FormatData_ko.java - src/jdk.localedata/share/classes/sun/text/resources/ko/JavaTimeSupplementary_ko.java - src/jdk.localedata/share/classes/sun/text/resources/ko/KR/FormatData_ko_KR.java - src/jdk.localedata/share/classes/sun/text/resources/lt/CollationData_lt.java - src/jdk.localedata/share/classes/sun/text/resources/lt/FormatData_lt.java - src/jdk.localedata/share/classes/sun/text/resources/lt/JavaTimeSupplementary_lt.java - src/jdk.localedata/share/classes/sun/text/resources/lt/LT/FormatData_lt_LT.java - src/jdk.localedata/share/classes/sun/text/resources/lv/CollationData_lv.java - src/jdk.localedata/share/classes/sun/text/resources/lv/FormatData_lv.java - src/jdk.localedata/share/classes/sun/text/resources/lv/JavaTimeSupplementary_lv.java - src/jdk.localedata/share/classes/sun/text/resources/lv/LV/FormatData_lv_LV.java - src/jdk.localedata/share/classes/sun/text/resources/mk/CollationData_mk.java - src/jdk.localedata/share/classes/sun/text/resources/mk/FormatData_mk.java - src/jdk.localedata/share/classes/sun/text/resources/mk/JavaTimeSupplementary_mk.java - src/jdk.localedata/share/classes/sun/text/resources/mk/MK/FormatData_mk_MK.java - src/jdk.localedata/share/classes/sun/text/resources/ms/FormatData_ms.java - src/jdk.localedata/share/classes/sun/text/resources/ms/JavaTimeSupplementary_ms.java - src/jdk.localedata/share/classes/sun/text/resources/ms/MY/FormatData_ms_MY.java - src/jdk.localedata/share/classes/sun/text/resources/mt/FormatData_mt.java - src/jdk.localedata/share/classes/sun/text/resources/mt/JavaTimeSupplementary_mt.java - src/jdk.localedata/share/classes/sun/text/resources/mt/MT/FormatData_mt_MT.java - src/jdk.localedata/share/classes/sun/text/resources/nl/BE/FormatData_nl_BE.java - src/jdk.localedata/share/classes/sun/text/resources/nl/BE/JavaTimeSupplementary_nl_BE.java - src/jdk.localedata/share/classes/sun/text/resources/nl/FormatData_nl.java - src/jdk.localedata/share/classes/sun/text/resources/nl/JavaTimeSupplementary_nl.java - src/jdk.localedata/share/classes/sun/text/resources/nl/NL/FormatData_nl_NL.java - src/jdk.localedata/share/classes/sun/text/resources/no/CollationData_no.java - src/jdk.localedata/share/classes/sun/text/resources/no/FormatData_no.java - src/jdk.localedata/share/classes/sun/text/resources/no/JavaTimeSupplementary_no.java - src/jdk.localedata/share/classes/sun/text/resources/no/NO/FormatData_no_NO.java - src/jdk.localedata/share/classes/sun/text/resources/no/NO/FormatData_no_NO_NY.java - src/jdk.localedata/share/classes/sun/text/resources/pl/CollationData_pl.java - src/jdk.localedata/share/classes/sun/text/resources/pl/FormatData_pl.java - src/jdk.localedata/share/classes/sun/text/resources/pl/JavaTimeSupplementary_pl.java - src/jdk.localedata/share/classes/sun/text/resources/pl/PL/FormatData_pl_PL.java - src/jdk.localedata/share/classes/sun/text/resources/pt/BR/FormatData_pt_BR.java - src/jdk.localedata/share/classes/sun/text/resources/pt/FormatData_pt.java - src/jdk.localedata/share/classes/sun/text/resources/pt/JavaTimeSupplementary_pt.java - src/jdk.localedata/share/classes/sun/text/resources/pt/PT/FormatData_pt_PT.java - src/jdk.localedata/share/classes/sun/text/resources/pt/PT/JavaTimeSupplementary_pt_PT.java - src/jdk.localedata/share/classes/sun/text/resources/ro/CollationData_ro.java - src/jdk.localedata/share/classes/sun/text/resources/ro/FormatData_ro.java - src/jdk.localedata/share/classes/sun/text/resources/ro/JavaTimeSupplementary_ro.java - src/jdk.localedata/share/classes/sun/text/resources/ro/RO/FormatData_ro_RO.java - src/jdk.localedata/share/classes/sun/text/resources/ru/CollationData_ru.java - src/jdk.localedata/share/classes/sun/text/resources/ru/FormatData_ru.java - src/jdk.localedata/share/classes/sun/text/resources/ru/JavaTimeSupplementary_ru.java - src/jdk.localedata/share/classes/sun/text/resources/ru/RU/FormatData_ru_RU.java - src/jdk.localedata/share/classes/sun/text/resources/sk/CollationData_sk.java - src/jdk.localedata/share/classes/sun/text/resources/sk/FormatData_sk.java - src/jdk.localedata/share/classes/sun/text/resources/sk/JavaTimeSupplementary_sk.java - src/jdk.localedata/share/classes/sun/text/resources/sk/SK/FormatData_sk_SK.java - src/jdk.localedata/share/classes/sun/text/resources/sl/CollationData_sl.java - src/jdk.localedata/share/classes/sun/text/resources/sl/FormatData_sl.java - src/jdk.localedata/share/classes/sun/text/resources/sl/JavaTimeSupplementary_sl.java - src/jdk.localedata/share/classes/sun/text/resources/sl/SI/FormatData_sl_SI.java - src/jdk.localedata/share/classes/sun/text/resources/sq/AL/FormatData_sq_AL.java - src/jdk.localedata/share/classes/sun/text/resources/sq/CollationData_sq.java - src/jdk.localedata/share/classes/sun/text/resources/sq/FormatData_sq.java - src/jdk.localedata/share/classes/sun/text/resources/sq/JavaTimeSupplementary_sq.java - src/jdk.localedata/share/classes/sun/text/resources/sr/BA/FormatData_sr_BA.java - src/jdk.localedata/share/classes/sun/text/resources/sr/CS/FormatData_sr_CS.java - src/jdk.localedata/share/classes/sun/text/resources/sr/CollationData_sr.java - src/jdk.localedata/share/classes/sun/text/resources/sr/CollationData_sr_Latn.java - src/jdk.localedata/share/classes/sun/text/resources/sr/FormatData_sr.java - src/jdk.localedata/share/classes/sun/text/resources/sr/FormatData_sr_Latn.java - src/jdk.localedata/share/classes/sun/text/resources/sr/JavaTimeSupplementary_sr.java - src/jdk.localedata/share/classes/sun/text/resources/sr/JavaTimeSupplementary_sr_Latn.java - src/jdk.localedata/share/classes/sun/text/resources/sr/ME/FormatData_sr_Latn_ME.java - src/jdk.localedata/share/classes/sun/text/resources/sr/ME/FormatData_sr_ME.java - src/jdk.localedata/share/classes/sun/text/resources/sr/RS/FormatData_sr_RS.java - src/jdk.localedata/share/classes/sun/text/resources/sv/CollationData_sv.java - src/jdk.localedata/share/classes/sun/text/resources/sv/FormatData_sv.java - src/jdk.localedata/share/classes/sun/text/resources/sv/JavaTimeSupplementary_sv.java - src/jdk.localedata/share/classes/sun/text/resources/sv/SE/FormatData_sv_SE.java - src/jdk.localedata/share/classes/sun/text/resources/th/BreakIteratorInfo_th.java - src/jdk.localedata/share/classes/sun/text/resources/th/BreakIteratorRules_th.java - src/jdk.localedata/share/classes/sun/text/resources/th/CollationData_th.java - src/jdk.localedata/share/classes/sun/text/resources/th/FormatData_th.java - src/jdk.localedata/share/classes/sun/text/resources/th/JavaTimeSupplementary_th.java - src/jdk.localedata/share/classes/sun/text/resources/th/TH/FormatData_th_TH.java - src/jdk.localedata/share/classes/sun/text/resources/th/thai_dict - src/jdk.localedata/share/classes/sun/text/resources/tr/CollationData_tr.java - src/jdk.localedata/share/classes/sun/text/resources/tr/FormatData_tr.java - src/jdk.localedata/share/classes/sun/text/resources/tr/JavaTimeSupplementary_tr.java - src/jdk.localedata/share/classes/sun/text/resources/tr/TR/FormatData_tr_TR.java - src/jdk.localedata/share/classes/sun/text/resources/uk/CollationData_uk.java - src/jdk.localedata/share/classes/sun/text/resources/uk/FormatData_uk.java - src/jdk.localedata/share/classes/sun/text/resources/uk/JavaTimeSupplementary_uk.java - src/jdk.localedata/share/classes/sun/text/resources/uk/UA/FormatData_uk_UA.java - src/jdk.localedata/share/classes/sun/text/resources/vi/CollationData_vi.java - src/jdk.localedata/share/classes/sun/text/resources/vi/FormatData_vi.java - src/jdk.localedata/share/classes/sun/text/resources/vi/JavaTimeSupplementary_vi.java - src/jdk.localedata/share/classes/sun/text/resources/vi/VN/FormatData_vi_VN.java - src/jdk.localedata/share/classes/sun/text/resources/zh/CN/FormatData_zh_CN.java - src/jdk.localedata/share/classes/sun/text/resources/zh/CollationData_zh.java - src/jdk.localedata/share/classes/sun/text/resources/zh/FormatData_zh.java - src/jdk.localedata/share/classes/sun/text/resources/zh/HK/CollationData_zh_HK.java - src/jdk.localedata/share/classes/sun/text/resources/zh/HK/FormatData_zh_HK.java - src/jdk.localedata/share/classes/sun/text/resources/zh/JavaTimeSupplementary_zh.java - src/jdk.localedata/share/classes/sun/text/resources/zh/SG/FormatData_zh_SG.java - src/jdk.localedata/share/classes/sun/text/resources/zh/TW/CollationData_zh_TW.java - src/jdk.localedata/share/classes/sun/text/resources/zh/TW/FormatData_zh_TW.java - src/jdk.localedata/share/classes/sun/text/resources/zh/TW/JavaTimeSupplementary_zh_TW.java - src/jdk.localedata/share/classes/sun/util/resources/ar/AE/CurrencyNames_ar_AE.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/BH/CurrencyNames_ar_BH.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/CalendarData_ar.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/DZ/CurrencyNames_ar_DZ.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/EG/CurrencyNames_ar_EG.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/IQ/CurrencyNames_ar_IQ.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/JO/CurrencyNames_ar_JO.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/KW/CurrencyNames_ar_KW.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/LB/CurrencyNames_ar_LB.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/LY/CurrencyNames_ar_LY.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/LocaleNames_ar.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/MA/CurrencyNames_ar_MA.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/OM/CurrencyNames_ar_OM.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/QA/CurrencyNames_ar_QA.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/SA/CurrencyNames_ar_SA.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/SD/CurrencyNames_ar_SD.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/SY/CurrencyNames_ar_SY.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/TN/CurrencyNames_ar_TN.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/YE/CurrencyNames_ar_YE.properties - src/jdk.localedata/share/classes/sun/util/resources/be/BY/CurrencyNames_be_BY.properties - src/jdk.localedata/share/classes/sun/util/resources/be/CalendarData_be.properties - src/jdk.localedata/share/classes/sun/util/resources/be/LocaleNames_be.properties - src/jdk.localedata/share/classes/sun/util/resources/bg/BG/CurrencyNames_bg_BG.properties - src/jdk.localedata/share/classes/sun/util/resources/bg/CalendarData_bg.properties - src/jdk.localedata/share/classes/sun/util/resources/bg/LocaleNames_bg.properties - src/jdk.localedata/share/classes/sun/util/resources/ca/CalendarData_ca.properties - src/jdk.localedata/share/classes/sun/util/resources/ca/ES/CurrencyNames_ca_ES.properties - src/jdk.localedata/share/classes/sun/util/resources/ca/LocaleNames_ca.properties - src/jdk.localedata/share/classes/sun/util/resources/cs/CZ/CurrencyNames_cs_CZ.properties - src/jdk.localedata/share/classes/sun/util/resources/cs/CalendarData_cs.properties - src/jdk.localedata/share/classes/sun/util/resources/cs/LocaleNames_cs.properties - src/jdk.localedata/share/classes/sun/util/resources/da/CalendarData_da.properties - src/jdk.localedata/share/classes/sun/util/resources/da/DK/CurrencyNames_da_DK.properties - src/jdk.localedata/share/classes/sun/util/resources/da/LocaleNames_da.properties - src/jdk.localedata/share/classes/sun/util/resources/de/AT/CurrencyNames_de_AT.properties - src/jdk.localedata/share/classes/sun/util/resources/de/CH/CurrencyNames_de_CH.properties - src/jdk.localedata/share/classes/sun/util/resources/de/CalendarData_de.properties - src/jdk.localedata/share/classes/sun/util/resources/de/CurrencyNames_de.properties - src/jdk.localedata/share/classes/sun/util/resources/de/DE/CurrencyNames_de_DE.properties - src/jdk.localedata/share/classes/sun/util/resources/de/GR/CurrencyNames_de_GR.properties - src/jdk.localedata/share/classes/sun/util/resources/de/LU/CurrencyNames_de_LU.properties - src/jdk.localedata/share/classes/sun/util/resources/de/LocaleNames_de.properties - src/jdk.localedata/share/classes/sun/util/resources/de/TimeZoneNames_de.java - src/jdk.localedata/share/classes/sun/util/resources/el/CY/CalendarData_el_CY.properties - src/jdk.localedata/share/classes/sun/util/resources/el/CY/CurrencyNames_el_CY.properties - src/jdk.localedata/share/classes/sun/util/resources/el/CY/LocaleNames_el_CY.properties - src/jdk.localedata/share/classes/sun/util/resources/el/CalendarData_el.properties - src/jdk.localedata/share/classes/sun/util/resources/el/GR/CurrencyNames_el_GR.properties - src/jdk.localedata/share/classes/sun/util/resources/el/LocaleNames_el.properties - src/jdk.localedata/share/classes/sun/util/resources/en/AU/CurrencyNames_en_AU.properties - src/jdk.localedata/share/classes/sun/util/resources/en/CA/CurrencyNames_en_CA.properties - src/jdk.localedata/share/classes/sun/util/resources/en/CA/TimeZoneNames_en_CA.java - src/jdk.localedata/share/classes/sun/util/resources/en/GB/CalendarData_en_GB.properties - src/jdk.localedata/share/classes/sun/util/resources/en/GB/CurrencyNames_en_GB.properties - src/jdk.localedata/share/classes/sun/util/resources/en/GB/TimeZoneNames_en_GB.java - src/jdk.localedata/share/classes/sun/util/resources/en/IE/CalendarData_en_IE.properties - src/jdk.localedata/share/classes/sun/util/resources/en/IE/CurrencyNames_en_IE.properties - src/jdk.localedata/share/classes/sun/util/resources/en/IE/TimeZoneNames_en_IE.java - src/jdk.localedata/share/classes/sun/util/resources/en/IN/CurrencyNames_en_IN.properties - src/jdk.localedata/share/classes/sun/util/resources/en/MT/CalendarData_en_MT.properties - src/jdk.localedata/share/classes/sun/util/resources/en/MT/CurrencyNames_en_MT.properties - src/jdk.localedata/share/classes/sun/util/resources/en/MT/LocaleNames_en_MT.properties - src/jdk.localedata/share/classes/sun/util/resources/en/NZ/CurrencyNames_en_NZ.properties - src/jdk.localedata/share/classes/sun/util/resources/en/PH/CurrencyNames_en_PH.properties - src/jdk.localedata/share/classes/sun/util/resources/en/PH/LocaleNames_en_PH.properties - src/jdk.localedata/share/classes/sun/util/resources/en/SG/CurrencyNames_en_SG.properties - src/jdk.localedata/share/classes/sun/util/resources/en/SG/LocaleNames_en_SG.properties - src/jdk.localedata/share/classes/sun/util/resources/en/ZA/CurrencyNames_en_ZA.properties - src/jdk.localedata/share/classes/sun/util/resources/es/AR/CurrencyNames_es_AR.properties - src/jdk.localedata/share/classes/sun/util/resources/es/BO/CurrencyNames_es_BO.properties - src/jdk.localedata/share/classes/sun/util/resources/es/CL/CurrencyNames_es_CL.properties - src/jdk.localedata/share/classes/sun/util/resources/es/CO/CurrencyNames_es_CO.properties - src/jdk.localedata/share/classes/sun/util/resources/es/CR/CurrencyNames_es_CR.properties - src/jdk.localedata/share/classes/sun/util/resources/es/CU/CurrencyNames_es_CU.properties - src/jdk.localedata/share/classes/sun/util/resources/es/CalendarData_es.properties - src/jdk.localedata/share/classes/sun/util/resources/es/CurrencyNames_es.properties - src/jdk.localedata/share/classes/sun/util/resources/es/DO/CurrencyNames_es_DO.properties - src/jdk.localedata/share/classes/sun/util/resources/es/EC/CurrencyNames_es_EC.properties - src/jdk.localedata/share/classes/sun/util/resources/es/ES/CalendarData_es_ES.properties - src/jdk.localedata/share/classes/sun/util/resources/es/ES/CurrencyNames_es_ES.properties - src/jdk.localedata/share/classes/sun/util/resources/es/GT/CurrencyNames_es_GT.properties - src/jdk.localedata/share/classes/sun/util/resources/es/HN/CurrencyNames_es_HN.properties - src/jdk.localedata/share/classes/sun/util/resources/es/LocaleNames_es.properties - src/jdk.localedata/share/classes/sun/util/resources/es/MX/CurrencyNames_es_MX.properties - src/jdk.localedata/share/classes/sun/util/resources/es/NI/CurrencyNames_es_NI.properties - src/jdk.localedata/share/classes/sun/util/resources/es/PA/CurrencyNames_es_PA.properties - src/jdk.localedata/share/classes/sun/util/resources/es/PE/CurrencyNames_es_PE.properties - src/jdk.localedata/share/classes/sun/util/resources/es/PR/CurrencyNames_es_PR.properties - src/jdk.localedata/share/classes/sun/util/resources/es/PY/CurrencyNames_es_PY.properties - src/jdk.localedata/share/classes/sun/util/resources/es/SV/CurrencyNames_es_SV.properties - src/jdk.localedata/share/classes/sun/util/resources/es/TimeZoneNames_es.java - src/jdk.localedata/share/classes/sun/util/resources/es/US/CalendarData_es_US.properties - src/jdk.localedata/share/classes/sun/util/resources/es/US/CurrencyNames_es_US.properties - src/jdk.localedata/share/classes/sun/util/resources/es/US/LocaleNames_es_US.properties - src/jdk.localedata/share/classes/sun/util/resources/es/UY/CurrencyNames_es_UY.properties - src/jdk.localedata/share/classes/sun/util/resources/es/VE/CurrencyNames_es_VE.properties - src/jdk.localedata/share/classes/sun/util/resources/et/CalendarData_et.properties - src/jdk.localedata/share/classes/sun/util/resources/et/EE/CurrencyNames_et_EE.properties - src/jdk.localedata/share/classes/sun/util/resources/et/LocaleNames_et.properties - src/jdk.localedata/share/classes/sun/util/resources/fi/CalendarData_fi.properties - src/jdk.localedata/share/classes/sun/util/resources/fi/FI/CurrencyNames_fi_FI.properties - src/jdk.localedata/share/classes/sun/util/resources/fi/LocaleNames_fi.properties - src/jdk.localedata/share/classes/sun/util/resources/fr/BE/CurrencyNames_fr_BE.properties - src/jdk.localedata/share/classes/sun/util/resources/fr/CA/CalendarData_fr_CA.properties - src/jdk.localedata/share/classes/sun/util/resources/fr/CA/CurrencyNames_fr_CA.properties - src/jdk.localedata/share/classes/sun/util/resources/fr/CH/CurrencyNames_fr_CH.properties - src/jdk.localedata/share/classes/sun/util/resources/fr/CalendarData_fr.properties - src/jdk.localedata/share/classes/sun/util/resources/fr/CurrencyNames_fr.properties - src/jdk.localedata/share/classes/sun/util/resources/fr/FR/CurrencyNames_fr_FR.properties - src/jdk.localedata/share/classes/sun/util/resources/fr/LU/CurrencyNames_fr_LU.properties - src/jdk.localedata/share/classes/sun/util/resources/fr/LocaleNames_fr.properties - src/jdk.localedata/share/classes/sun/util/resources/fr/TimeZoneNames_fr.java - src/jdk.localedata/share/classes/sun/util/resources/ga/IE/CurrencyNames_ga_IE.properties - src/jdk.localedata/share/classes/sun/util/resources/ga/LocaleNames_ga.properties - src/jdk.localedata/share/classes/sun/util/resources/hi/CalendarData_hi.properties - src/jdk.localedata/share/classes/sun/util/resources/hi/IN/CurrencyNames_hi_IN.properties - src/jdk.localedata/share/classes/sun/util/resources/hi/LocaleNames_hi.properties - src/jdk.localedata/share/classes/sun/util/resources/hi/TimeZoneNames_hi.java - src/jdk.localedata/share/classes/sun/util/resources/hr/CalendarData_hr.properties - src/jdk.localedata/share/classes/sun/util/resources/hr/HR/CurrencyNames_hr_HR.properties - src/jdk.localedata/share/classes/sun/util/resources/hr/LocaleNames_hr.properties - src/jdk.localedata/share/classes/sun/util/resources/hu/CalendarData_hu.properties - src/jdk.localedata/share/classes/sun/util/resources/hu/HU/CurrencyNames_hu_HU.properties - src/jdk.localedata/share/classes/sun/util/resources/hu/LocaleNames_hu.properties - src/jdk.localedata/share/classes/sun/util/resources/in/ID/CalendarData_in_ID.properties - src/jdk.localedata/share/classes/sun/util/resources/in/ID/CurrencyNames_in_ID.properties - src/jdk.localedata/share/classes/sun/util/resources/in/LocaleNames_in.properties - src/jdk.localedata/share/classes/sun/util/resources/is/CalendarData_is.properties - src/jdk.localedata/share/classes/sun/util/resources/is/IS/CurrencyNames_is_IS.properties - src/jdk.localedata/share/classes/sun/util/resources/is/LocaleNames_is.properties - src/jdk.localedata/share/classes/sun/util/resources/it/CH/CurrencyNames_it_CH.properties - src/jdk.localedata/share/classes/sun/util/resources/it/CalendarData_it.properties - src/jdk.localedata/share/classes/sun/util/resources/it/CurrencyNames_it.properties - src/jdk.localedata/share/classes/sun/util/resources/it/IT/CurrencyNames_it_IT.properties - src/jdk.localedata/share/classes/sun/util/resources/it/LocaleNames_it.properties - src/jdk.localedata/share/classes/sun/util/resources/it/TimeZoneNames_it.java - src/jdk.localedata/share/classes/sun/util/resources/iw/CalendarData_iw.properties - src/jdk.localedata/share/classes/sun/util/resources/iw/IL/CurrencyNames_iw_IL.properties - src/jdk.localedata/share/classes/sun/util/resources/iw/LocaleNames_iw.properties - src/jdk.localedata/share/classes/sun/util/resources/ja/CalendarData_ja.properties - src/jdk.localedata/share/classes/sun/util/resources/ja/CurrencyNames_ja.properties - src/jdk.localedata/share/classes/sun/util/resources/ja/JP/CurrencyNames_ja_JP.properties - src/jdk.localedata/share/classes/sun/util/resources/ja/LocaleNames_ja.properties - src/jdk.localedata/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java - src/jdk.localedata/share/classes/sun/util/resources/ko/CalendarData_ko.properties - src/jdk.localedata/share/classes/sun/util/resources/ko/CurrencyNames_ko.properties - src/jdk.localedata/share/classes/sun/util/resources/ko/KR/CurrencyNames_ko_KR.properties - src/jdk.localedata/share/classes/sun/util/resources/ko/LocaleNames_ko.properties - src/jdk.localedata/share/classes/sun/util/resources/ko/TimeZoneNames_ko.java - src/jdk.localedata/share/classes/sun/util/resources/lt/CalendarData_lt.properties - src/jdk.localedata/share/classes/sun/util/resources/lt/LT/CurrencyNames_lt_LT.properties - src/jdk.localedata/share/classes/sun/util/resources/lt/LocaleNames_lt.properties - src/jdk.localedata/share/classes/sun/util/resources/lv/CalendarData_lv.properties - src/jdk.localedata/share/classes/sun/util/resources/lv/LV/CurrencyNames_lv_LV.properties - src/jdk.localedata/share/classes/sun/util/resources/lv/LocaleNames_lv.properties - src/jdk.localedata/share/classes/sun/util/resources/mk/CalendarData_mk.properties - src/jdk.localedata/share/classes/sun/util/resources/mk/LocaleNames_mk.properties - src/jdk.localedata/share/classes/sun/util/resources/mk/MK/CurrencyNames_mk_MK.properties - src/jdk.localedata/share/classes/sun/util/resources/ms/LocaleNames_ms.properties - src/jdk.localedata/share/classes/sun/util/resources/ms/MY/CalendarData_ms_MY.properties - src/jdk.localedata/share/classes/sun/util/resources/ms/MY/CurrencyNames_ms_MY.properties - src/jdk.localedata/share/classes/sun/util/resources/mt/CalendarData_mt.properties - src/jdk.localedata/share/classes/sun/util/resources/mt/LocaleNames_mt.properties - src/jdk.localedata/share/classes/sun/util/resources/mt/MT/CalendarData_mt_MT.properties - src/jdk.localedata/share/classes/sun/util/resources/mt/MT/CurrencyNames_mt_MT.properties - src/jdk.localedata/share/classes/sun/util/resources/nl/BE/CurrencyNames_nl_BE.properties - src/jdk.localedata/share/classes/sun/util/resources/nl/CalendarData_nl.properties - src/jdk.localedata/share/classes/sun/util/resources/nl/LocaleNames_nl.properties - src/jdk.localedata/share/classes/sun/util/resources/nl/NL/CurrencyNames_nl_NL.properties - src/jdk.localedata/share/classes/sun/util/resources/no/CalendarData_no.properties - src/jdk.localedata/share/classes/sun/util/resources/no/LocaleNames_no.properties - src/jdk.localedata/share/classes/sun/util/resources/no/NO/CurrencyNames_no_NO.properties - src/jdk.localedata/share/classes/sun/util/resources/no/NO/LocaleNames_no_NO_NY.properties - src/jdk.localedata/share/classes/sun/util/resources/pl/CalendarData_pl.properties - src/jdk.localedata/share/classes/sun/util/resources/pl/LocaleNames_pl.properties - src/jdk.localedata/share/classes/sun/util/resources/pl/PL/CurrencyNames_pl_PL.properties - src/jdk.localedata/share/classes/sun/util/resources/pt/BR/CalendarData_pt_BR.properties - src/jdk.localedata/share/classes/sun/util/resources/pt/BR/CurrencyNames_pt_BR.properties - src/jdk.localedata/share/classes/sun/util/resources/pt/BR/LocaleNames_pt_BR.properties - src/jdk.localedata/share/classes/sun/util/resources/pt/BR/TimeZoneNames_pt_BR.java - src/jdk.localedata/share/classes/sun/util/resources/pt/CalendarData_pt.properties - src/jdk.localedata/share/classes/sun/util/resources/pt/CurrencyNames_pt.properties - src/jdk.localedata/share/classes/sun/util/resources/pt/LocaleNames_pt.properties - src/jdk.localedata/share/classes/sun/util/resources/pt/PT/CalendarData_pt_PT.properties - src/jdk.localedata/share/classes/sun/util/resources/pt/PT/CurrencyNames_pt_PT.properties - src/jdk.localedata/share/classes/sun/util/resources/pt/PT/LocaleNames_pt_PT.properties - src/jdk.localedata/share/classes/sun/util/resources/ro/CalendarData_ro.properties - src/jdk.localedata/share/classes/sun/util/resources/ro/LocaleNames_ro.properties - src/jdk.localedata/share/classes/sun/util/resources/ro/RO/CurrencyNames_ro_RO.properties - src/jdk.localedata/share/classes/sun/util/resources/ru/CalendarData_ru.properties - src/jdk.localedata/share/classes/sun/util/resources/ru/LocaleNames_ru.properties - src/jdk.localedata/share/classes/sun/util/resources/ru/RU/CurrencyNames_ru_RU.properties - src/jdk.localedata/share/classes/sun/util/resources/sk/CalendarData_sk.properties - src/jdk.localedata/share/classes/sun/util/resources/sk/LocaleNames_sk.properties - src/jdk.localedata/share/classes/sun/util/resources/sk/SK/CurrencyNames_sk_SK.properties - src/jdk.localedata/share/classes/sun/util/resources/sl/CalendarData_sl.properties - src/jdk.localedata/share/classes/sun/util/resources/sl/LocaleNames_sl.properties - src/jdk.localedata/share/classes/sun/util/resources/sl/SI/CurrencyNames_sl_SI.properties - src/jdk.localedata/share/classes/sun/util/resources/sq/AL/CurrencyNames_sq_AL.properties - src/jdk.localedata/share/classes/sun/util/resources/sq/CalendarData_sq.properties - src/jdk.localedata/share/classes/sun/util/resources/sq/LocaleNames_sq.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/BA/CalendarData_sr_Latn_BA.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/BA/CurrencyNames_sr_BA.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/BA/CurrencyNames_sr_Latn_BA.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/CS/CurrencyNames_sr_CS.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/CalendarData_sr.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/LocaleNames_sr.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/LocaleNames_sr_Latn.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/ME/CalendarData_sr_Latn_ME.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/ME/CurrencyNames_sr_Latn_ME.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/ME/CurrencyNames_sr_ME.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/RS/CalendarData_sr_Latn_RS.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/RS/CurrencyNames_sr_Latn_RS.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/RS/CurrencyNames_sr_RS.properties - src/jdk.localedata/share/classes/sun/util/resources/sv/CalendarData_sv.properties - src/jdk.localedata/share/classes/sun/util/resources/sv/CurrencyNames_sv.properties - src/jdk.localedata/share/classes/sun/util/resources/sv/LocaleNames_sv.properties - src/jdk.localedata/share/classes/sun/util/resources/sv/SE/CurrencyNames_sv_SE.properties - src/jdk.localedata/share/classes/sun/util/resources/sv/TimeZoneNames_sv.java - src/jdk.localedata/share/classes/sun/util/resources/th/CalendarData_th.properties - src/jdk.localedata/share/classes/sun/util/resources/th/LocaleNames_th.properties - src/jdk.localedata/share/classes/sun/util/resources/th/TH/CurrencyNames_th_TH.properties - src/jdk.localedata/share/classes/sun/util/resources/tr/CalendarData_tr.properties - src/jdk.localedata/share/classes/sun/util/resources/tr/LocaleNames_tr.properties - src/jdk.localedata/share/classes/sun/util/resources/tr/TR/CurrencyNames_tr_TR.properties - src/jdk.localedata/share/classes/sun/util/resources/uk/CalendarData_uk.properties - src/jdk.localedata/share/classes/sun/util/resources/uk/LocaleNames_uk.properties - src/jdk.localedata/share/classes/sun/util/resources/uk/UA/CurrencyNames_uk_UA.properties - src/jdk.localedata/share/classes/sun/util/resources/vi/CalendarData_vi.properties - src/jdk.localedata/share/classes/sun/util/resources/vi/LocaleNames_vi.properties - src/jdk.localedata/share/classes/sun/util/resources/vi/VN/CurrencyNames_vi_VN.properties - src/jdk.localedata/share/classes/sun/util/resources/zh/CN/CurrencyNames_zh_CN.properties - src/jdk.localedata/share/classes/sun/util/resources/zh/CN/TimeZoneNames_zh_CN.java - src/jdk.localedata/share/classes/sun/util/resources/zh/CalendarData_zh.properties - src/jdk.localedata/share/classes/sun/util/resources/zh/HK/CurrencyNames_zh_HK.java - src/jdk.localedata/share/classes/sun/util/resources/zh/HK/LocaleNames_zh_HK.java - src/jdk.localedata/share/classes/sun/util/resources/zh/HK/TimeZoneNames_zh_HK.java - src/jdk.localedata/share/classes/sun/util/resources/zh/LocaleNames_zh.properties - src/jdk.localedata/share/classes/sun/util/resources/zh/SG/CurrencyNames_zh_SG.java - src/jdk.localedata/share/classes/sun/util/resources/zh/SG/LocaleNames_zh_SG.properties - src/jdk.localedata/share/classes/sun/util/resources/zh/TW/CurrencyNames_zh_TW.properties - src/jdk.localedata/share/classes/sun/util/resources/zh/TW/LocaleNames_zh_TW.properties - src/jdk.localedata/share/classes/sun/util/resources/zh/TW/TimeZoneNames_zh_TW.java Changeset: 9893c05c9cef Author: thartmann Date: 2016-02-29 08:12 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9893c05c9cef Merge - make/src/classes/build/tools/generatebreakiteratordata/BreakIteratorRBControl.java - src/java.base/share/classes/sun/text/resources/en/FormatData_en.java - src/java.base/share/classes/sun/text/resources/en/JavaTimeSupplementary_en.java - src/java.base/share/classes/sun/text/resources/en/US/FormatData_en_US.java - src/java.base/share/classes/sun/util/resources/en/CalendarData_en.properties - src/java.base/share/classes/sun/util/resources/en/LocaleNames_en.properties - src/java.base/share/classes/sun/util/resources/en/TimeZoneNames_en.java - src/java.base/share/classes/sun/util/resources/en/US/CurrencyNames_en_US.properties - src/jdk.localedata/share/classes/sun/text/resources/ar/CollationData_ar.java - src/jdk.localedata/share/classes/sun/text/resources/ar/FormatData_ar.java - src/jdk.localedata/share/classes/sun/text/resources/ar/JO/FormatData_ar_JO.java - src/jdk.localedata/share/classes/sun/text/resources/ar/JO/JavaTimeSupplementary_ar_JO.java - src/jdk.localedata/share/classes/sun/text/resources/ar/JavaTimeSupplementary_ar.java - src/jdk.localedata/share/classes/sun/text/resources/ar/LB/FormatData_ar_LB.java - src/jdk.localedata/share/classes/sun/text/resources/ar/LB/JavaTimeSupplementary_ar_LB.java - src/jdk.localedata/share/classes/sun/text/resources/ar/SY/FormatData_ar_SY.java - src/jdk.localedata/share/classes/sun/text/resources/ar/SY/JavaTimeSupplementary_ar_SY.java - src/jdk.localedata/share/classes/sun/text/resources/be/BY/FormatData_be_BY.java - src/jdk.localedata/share/classes/sun/text/resources/be/CollationData_be.java - src/jdk.localedata/share/classes/sun/text/resources/be/FormatData_be.java - src/jdk.localedata/share/classes/sun/text/resources/be/JavaTimeSupplementary_be.java - src/jdk.localedata/share/classes/sun/text/resources/bg/BG/FormatData_bg_BG.java - src/jdk.localedata/share/classes/sun/text/resources/bg/CollationData_bg.java - src/jdk.localedata/share/classes/sun/text/resources/bg/FormatData_bg.java - src/jdk.localedata/share/classes/sun/text/resources/bg/JavaTimeSupplementary_bg.java - src/jdk.localedata/share/classes/sun/text/resources/ca/CollationData_ca.java - src/jdk.localedata/share/classes/sun/text/resources/ca/ES/FormatData_ca_ES.java - src/jdk.localedata/share/classes/sun/text/resources/ca/FormatData_ca.java - src/jdk.localedata/share/classes/sun/text/resources/ca/JavaTimeSupplementary_ca.java - src/jdk.localedata/share/classes/sun/text/resources/cs/CZ/FormatData_cs_CZ.java - src/jdk.localedata/share/classes/sun/text/resources/cs/CollationData_cs.java - src/jdk.localedata/share/classes/sun/text/resources/cs/FormatData_cs.java - src/jdk.localedata/share/classes/sun/text/resources/cs/JavaTimeSupplementary_cs.java - src/jdk.localedata/share/classes/sun/text/resources/da/CollationData_da.java - src/jdk.localedata/share/classes/sun/text/resources/da/DK/FormatData_da_DK.java - src/jdk.localedata/share/classes/sun/text/resources/da/FormatData_da.java - src/jdk.localedata/share/classes/sun/text/resources/da/JavaTimeSupplementary_da.java - src/jdk.localedata/share/classes/sun/text/resources/de/AT/FormatData_de_AT.java - src/jdk.localedata/share/classes/sun/text/resources/de/AT/JavaTimeSupplementary_de_AT.java - src/jdk.localedata/share/classes/sun/text/resources/de/CH/FormatData_de_CH.java - src/jdk.localedata/share/classes/sun/text/resources/de/DE/FormatData_de_DE.java - src/jdk.localedata/share/classes/sun/text/resources/de/FormatData_de.java - src/jdk.localedata/share/classes/sun/text/resources/de/JavaTimeSupplementary_de.java - src/jdk.localedata/share/classes/sun/text/resources/de/LU/FormatData_de_LU.java - src/jdk.localedata/share/classes/sun/text/resources/el/CY/FormatData_el_CY.java - src/jdk.localedata/share/classes/sun/text/resources/el/CollationData_el.java - src/jdk.localedata/share/classes/sun/text/resources/el/FormatData_el.java - src/jdk.localedata/share/classes/sun/text/resources/el/GR/FormatData_el_GR.java - src/jdk.localedata/share/classes/sun/text/resources/el/JavaTimeSupplementary_el.java - src/jdk.localedata/share/classes/sun/text/resources/en/AU/FormatData_en_AU.java - src/jdk.localedata/share/classes/sun/text/resources/en/AU/JavaTimeSupplementary_en_AU.java - src/jdk.localedata/share/classes/sun/text/resources/en/CA/FormatData_en_CA.java - src/jdk.localedata/share/classes/sun/text/resources/en/CA/JavaTimeSupplementary_en_CA.java - src/jdk.localedata/share/classes/sun/text/resources/en/GB/FormatData_en_GB.java - src/jdk.localedata/share/classes/sun/text/resources/en/GB/JavaTimeSupplementary_en_GB.java - src/jdk.localedata/share/classes/sun/text/resources/en/IE/FormatData_en_IE.java - src/jdk.localedata/share/classes/sun/text/resources/en/IE/JavaTimeSupplementary_en_IE.java - src/jdk.localedata/share/classes/sun/text/resources/en/IN/FormatData_en_IN.java - src/jdk.localedata/share/classes/sun/text/resources/en/IN/JavaTimeSupplementary_en_IN.java - src/jdk.localedata/share/classes/sun/text/resources/en/MT/FormatData_en_MT.java - src/jdk.localedata/share/classes/sun/text/resources/en/MT/JavaTimeSupplementary_en_MT.java - src/jdk.localedata/share/classes/sun/text/resources/en/NZ/FormatData_en_NZ.java - src/jdk.localedata/share/classes/sun/text/resources/en/NZ/JavaTimeSupplementary_en_NZ.java - src/jdk.localedata/share/classes/sun/text/resources/en/PH/FormatData_en_PH.java - src/jdk.localedata/share/classes/sun/text/resources/en/SG/FormatData_en_SG.java - src/jdk.localedata/share/classes/sun/text/resources/en/SG/JavaTimeSupplementary_en_SG.java - src/jdk.localedata/share/classes/sun/text/resources/en/ZA/FormatData_en_ZA.java - src/jdk.localedata/share/classes/sun/text/resources/en/ZA/JavaTimeSupplementary_en_ZA.java - src/jdk.localedata/share/classes/sun/text/resources/es/AR/FormatData_es_AR.java - src/jdk.localedata/share/classes/sun/text/resources/es/BO/FormatData_es_BO.java - src/jdk.localedata/share/classes/sun/text/resources/es/CL/FormatData_es_CL.java - src/jdk.localedata/share/classes/sun/text/resources/es/CL/JavaTimeSupplementary_es_CL.java - src/jdk.localedata/share/classes/sun/text/resources/es/CO/FormatData_es_CO.java - src/jdk.localedata/share/classes/sun/text/resources/es/CO/JavaTimeSupplementary_es_CO.java - src/jdk.localedata/share/classes/sun/text/resources/es/CR/FormatData_es_CR.java - src/jdk.localedata/share/classes/sun/text/resources/es/CollationData_es.java - src/jdk.localedata/share/classes/sun/text/resources/es/DO/FormatData_es_DO.java - src/jdk.localedata/share/classes/sun/text/resources/es/EC/FormatData_es_EC.java - src/jdk.localedata/share/classes/sun/text/resources/es/ES/FormatData_es_ES.java - src/jdk.localedata/share/classes/sun/text/resources/es/FormatData_es.java - src/jdk.localedata/share/classes/sun/text/resources/es/GT/FormatData_es_GT.java - src/jdk.localedata/share/classes/sun/text/resources/es/GT/JavaTimeSupplementary_es_GT.java - src/jdk.localedata/share/classes/sun/text/resources/es/HN/FormatData_es_HN.java - src/jdk.localedata/share/classes/sun/text/resources/es/HN/JavaTimeSupplementary_es_HN.java - src/jdk.localedata/share/classes/sun/text/resources/es/JavaTimeSupplementary_es.java - src/jdk.localedata/share/classes/sun/text/resources/es/MX/FormatData_es_MX.java - src/jdk.localedata/share/classes/sun/text/resources/es/MX/JavaTimeSupplementary_es_MX.java - src/jdk.localedata/share/classes/sun/text/resources/es/NI/FormatData_es_NI.java - src/jdk.localedata/share/classes/sun/text/resources/es/PA/FormatData_es_PA.java - src/jdk.localedata/share/classes/sun/text/resources/es/PA/JavaTimeSupplementary_es_PA.java - src/jdk.localedata/share/classes/sun/text/resources/es/PE/FormatData_es_PE.java - src/jdk.localedata/share/classes/sun/text/resources/es/PE/JavaTimeSupplementary_es_PE.java - src/jdk.localedata/share/classes/sun/text/resources/es/PR/FormatData_es_PR.java - src/jdk.localedata/share/classes/sun/text/resources/es/PR/JavaTimeSupplementary_es_PR.java - src/jdk.localedata/share/classes/sun/text/resources/es/PY/FormatData_es_PY.java - src/jdk.localedata/share/classes/sun/text/resources/es/SV/FormatData_es_SV.java - src/jdk.localedata/share/classes/sun/text/resources/es/US/FormatData_es_US.java - src/jdk.localedata/share/classes/sun/text/resources/es/UY/FormatData_es_UY.java - src/jdk.localedata/share/classes/sun/text/resources/es/UY/JavaTimeSupplementary_es_UY.java - src/jdk.localedata/share/classes/sun/text/resources/es/VE/FormatData_es_VE.java - src/jdk.localedata/share/classes/sun/text/resources/et/CollationData_et.java - src/jdk.localedata/share/classes/sun/text/resources/et/EE/FormatData_et_EE.java - src/jdk.localedata/share/classes/sun/text/resources/et/FormatData_et.java - src/jdk.localedata/share/classes/sun/text/resources/et/JavaTimeSupplementary_et.java - src/jdk.localedata/share/classes/sun/text/resources/fi/CollationData_fi.java - src/jdk.localedata/share/classes/sun/text/resources/fi/FI/FormatData_fi_FI.java - src/jdk.localedata/share/classes/sun/text/resources/fi/FormatData_fi.java - src/jdk.localedata/share/classes/sun/text/resources/fi/JavaTimeSupplementary_fi.java - src/jdk.localedata/share/classes/sun/text/resources/fr/BE/FormatData_fr_BE.java - src/jdk.localedata/share/classes/sun/text/resources/fr/BE/JavaTimeSupplementary_fr_BE.java - src/jdk.localedata/share/classes/sun/text/resources/fr/CA/FormatData_fr_CA.java - src/jdk.localedata/share/classes/sun/text/resources/fr/CA/JavaTimeSupplementary_fr_CA.java - src/jdk.localedata/share/classes/sun/text/resources/fr/CH/FormatData_fr_CH.java - src/jdk.localedata/share/classes/sun/text/resources/fr/CH/JavaTimeSupplementary_fr_CH.java - src/jdk.localedata/share/classes/sun/text/resources/fr/CollationData_fr.java - src/jdk.localedata/share/classes/sun/text/resources/fr/FR/FormatData_fr_FR.java - src/jdk.localedata/share/classes/sun/text/resources/fr/FormatData_fr.java - src/jdk.localedata/share/classes/sun/text/resources/fr/JavaTimeSupplementary_fr.java - src/jdk.localedata/share/classes/sun/text/resources/ga/FormatData_ga.java - src/jdk.localedata/share/classes/sun/text/resources/ga/IE/FormatData_ga_IE.java - src/jdk.localedata/share/classes/sun/text/resources/ga/JavaTimeSupplementary_ga.java - src/jdk.localedata/share/classes/sun/text/resources/hi/CollationData_hi.java - src/jdk.localedata/share/classes/sun/text/resources/hi/IN/FormatData_hi_IN.java - src/jdk.localedata/share/classes/sun/text/resources/hi/IN/JavaTimeSupplementary_hi_IN.java - src/jdk.localedata/share/classes/sun/text/resources/hr/CollationData_hr.java - src/jdk.localedata/share/classes/sun/text/resources/hr/FormatData_hr.java - src/jdk.localedata/share/classes/sun/text/resources/hr/HR/FormatData_hr_HR.java - src/jdk.localedata/share/classes/sun/text/resources/hr/JavaTimeSupplementary_hr.java - src/jdk.localedata/share/classes/sun/text/resources/hu/CollationData_hu.java - src/jdk.localedata/share/classes/sun/text/resources/hu/FormatData_hu.java - src/jdk.localedata/share/classes/sun/text/resources/hu/HU/FormatData_hu_HU.java - src/jdk.localedata/share/classes/sun/text/resources/hu/JavaTimeSupplementary_hu.java - src/jdk.localedata/share/classes/sun/text/resources/in/FormatData_in.java - src/jdk.localedata/share/classes/sun/text/resources/in/ID/FormatData_in_ID.java - src/jdk.localedata/share/classes/sun/text/resources/is/CollationData_is.java - src/jdk.localedata/share/classes/sun/text/resources/is/FormatData_is.java - src/jdk.localedata/share/classes/sun/text/resources/is/IS/FormatData_is_IS.java - src/jdk.localedata/share/classes/sun/text/resources/is/JavaTimeSupplementary_is.java - src/jdk.localedata/share/classes/sun/text/resources/it/CH/FormatData_it_CH.java - src/jdk.localedata/share/classes/sun/text/resources/it/CH/JavaTimeSupplementary_it_CH.java - src/jdk.localedata/share/classes/sun/text/resources/it/FormatData_it.java - src/jdk.localedata/share/classes/sun/text/resources/it/IT/FormatData_it_IT.java - src/jdk.localedata/share/classes/sun/text/resources/it/JavaTimeSupplementary_it.java - src/jdk.localedata/share/classes/sun/text/resources/iw/CollationData_iw.java - src/jdk.localedata/share/classes/sun/text/resources/iw/FormatData_iw.java - src/jdk.localedata/share/classes/sun/text/resources/iw/IL/FormatData_iw_IL.java - src/jdk.localedata/share/classes/sun/text/resources/iw/IL/JavaTimeSupplementary_iw_IL.java - src/jdk.localedata/share/classes/sun/text/resources/iw/JavaTimeSupplementary_iw.java - src/jdk.localedata/share/classes/sun/text/resources/ja/CollationData_ja.java - src/jdk.localedata/share/classes/sun/text/resources/ja/FormatData_ja.java - src/jdk.localedata/share/classes/sun/text/resources/ja/JP/FormatData_ja_JP.java - src/jdk.localedata/share/classes/sun/text/resources/ja/JavaTimeSupplementary_ja.java - src/jdk.localedata/share/classes/sun/text/resources/ko/CollationData_ko.java - src/jdk.localedata/share/classes/sun/text/resources/ko/FormatData_ko.java - src/jdk.localedata/share/classes/sun/text/resources/ko/JavaTimeSupplementary_ko.java - src/jdk.localedata/share/classes/sun/text/resources/ko/KR/FormatData_ko_KR.java - src/jdk.localedata/share/classes/sun/text/resources/lt/CollationData_lt.java - src/jdk.localedata/share/classes/sun/text/resources/lt/FormatData_lt.java - src/jdk.localedata/share/classes/sun/text/resources/lt/JavaTimeSupplementary_lt.java - src/jdk.localedata/share/classes/sun/text/resources/lt/LT/FormatData_lt_LT.java - src/jdk.localedata/share/classes/sun/text/resources/lv/CollationData_lv.java - src/jdk.localedata/share/classes/sun/text/resources/lv/FormatData_lv.java - src/jdk.localedata/share/classes/sun/text/resources/lv/JavaTimeSupplementary_lv.java - src/jdk.localedata/share/classes/sun/text/resources/lv/LV/FormatData_lv_LV.java - src/jdk.localedata/share/classes/sun/text/resources/mk/CollationData_mk.java - src/jdk.localedata/share/classes/sun/text/resources/mk/FormatData_mk.java - src/jdk.localedata/share/classes/sun/text/resources/mk/JavaTimeSupplementary_mk.java - src/jdk.localedata/share/classes/sun/text/resources/mk/MK/FormatData_mk_MK.java - src/jdk.localedata/share/classes/sun/text/resources/ms/FormatData_ms.java - src/jdk.localedata/share/classes/sun/text/resources/ms/JavaTimeSupplementary_ms.java - src/jdk.localedata/share/classes/sun/text/resources/ms/MY/FormatData_ms_MY.java - src/jdk.localedata/share/classes/sun/text/resources/mt/FormatData_mt.java - src/jdk.localedata/share/classes/sun/text/resources/mt/JavaTimeSupplementary_mt.java - src/jdk.localedata/share/classes/sun/text/resources/mt/MT/FormatData_mt_MT.java - src/jdk.localedata/share/classes/sun/text/resources/nl/BE/FormatData_nl_BE.java - src/jdk.localedata/share/classes/sun/text/resources/nl/BE/JavaTimeSupplementary_nl_BE.java - src/jdk.localedata/share/classes/sun/text/resources/nl/FormatData_nl.java - src/jdk.localedata/share/classes/sun/text/resources/nl/JavaTimeSupplementary_nl.java - src/jdk.localedata/share/classes/sun/text/resources/nl/NL/FormatData_nl_NL.java - src/jdk.localedata/share/classes/sun/text/resources/no/CollationData_no.java - src/jdk.localedata/share/classes/sun/text/resources/no/FormatData_no.java - src/jdk.localedata/share/classes/sun/text/resources/no/JavaTimeSupplementary_no.java - src/jdk.localedata/share/classes/sun/text/resources/no/NO/FormatData_no_NO.java - src/jdk.localedata/share/classes/sun/text/resources/no/NO/FormatData_no_NO_NY.java - src/jdk.localedata/share/classes/sun/text/resources/pl/CollationData_pl.java - src/jdk.localedata/share/classes/sun/text/resources/pl/FormatData_pl.java - src/jdk.localedata/share/classes/sun/text/resources/pl/JavaTimeSupplementary_pl.java - src/jdk.localedata/share/classes/sun/text/resources/pl/PL/FormatData_pl_PL.java - src/jdk.localedata/share/classes/sun/text/resources/pt/BR/FormatData_pt_BR.java - src/jdk.localedata/share/classes/sun/text/resources/pt/FormatData_pt.java - src/jdk.localedata/share/classes/sun/text/resources/pt/JavaTimeSupplementary_pt.java - src/jdk.localedata/share/classes/sun/text/resources/pt/PT/FormatData_pt_PT.java - src/jdk.localedata/share/classes/sun/text/resources/pt/PT/JavaTimeSupplementary_pt_PT.java - src/jdk.localedata/share/classes/sun/text/resources/ro/CollationData_ro.java - src/jdk.localedata/share/classes/sun/text/resources/ro/FormatData_ro.java - src/jdk.localedata/share/classes/sun/text/resources/ro/JavaTimeSupplementary_ro.java - src/jdk.localedata/share/classes/sun/text/resources/ro/RO/FormatData_ro_RO.java - src/jdk.localedata/share/classes/sun/text/resources/ru/CollationData_ru.java - src/jdk.localedata/share/classes/sun/text/resources/ru/FormatData_ru.java - src/jdk.localedata/share/classes/sun/text/resources/ru/JavaTimeSupplementary_ru.java - src/jdk.localedata/share/classes/sun/text/resources/ru/RU/FormatData_ru_RU.java - src/jdk.localedata/share/classes/sun/text/resources/sk/CollationData_sk.java - src/jdk.localedata/share/classes/sun/text/resources/sk/FormatData_sk.java - src/jdk.localedata/share/classes/sun/text/resources/sk/JavaTimeSupplementary_sk.java - src/jdk.localedata/share/classes/sun/text/resources/sk/SK/FormatData_sk_SK.java - src/jdk.localedata/share/classes/sun/text/resources/sl/CollationData_sl.java - src/jdk.localedata/share/classes/sun/text/resources/sl/FormatData_sl.java - src/jdk.localedata/share/classes/sun/text/resources/sl/JavaTimeSupplementary_sl.java - src/jdk.localedata/share/classes/sun/text/resources/sl/SI/FormatData_sl_SI.java - src/jdk.localedata/share/classes/sun/text/resources/sq/AL/FormatData_sq_AL.java - src/jdk.localedata/share/classes/sun/text/resources/sq/CollationData_sq.java - src/jdk.localedata/share/classes/sun/text/resources/sq/FormatData_sq.java - src/jdk.localedata/share/classes/sun/text/resources/sq/JavaTimeSupplementary_sq.java - src/jdk.localedata/share/classes/sun/text/resources/sr/BA/FormatData_sr_BA.java - src/jdk.localedata/share/classes/sun/text/resources/sr/CS/FormatData_sr_CS.java - src/jdk.localedata/share/classes/sun/text/resources/sr/CollationData_sr.java - src/jdk.localedata/share/classes/sun/text/resources/sr/CollationData_sr_Latn.java - src/jdk.localedata/share/classes/sun/text/resources/sr/FormatData_sr.java - src/jdk.localedata/share/classes/sun/text/resources/sr/FormatData_sr_Latn.java - src/jdk.localedata/share/classes/sun/text/resources/sr/JavaTimeSupplementary_sr.java - src/jdk.localedata/share/classes/sun/text/resources/sr/JavaTimeSupplementary_sr_Latn.java - src/jdk.localedata/share/classes/sun/text/resources/sr/ME/FormatData_sr_Latn_ME.java - src/jdk.localedata/share/classes/sun/text/resources/sr/ME/FormatData_sr_ME.java - src/jdk.localedata/share/classes/sun/text/resources/sr/RS/FormatData_sr_RS.java - src/jdk.localedata/share/classes/sun/text/resources/sv/CollationData_sv.java - src/jdk.localedata/share/classes/sun/text/resources/sv/FormatData_sv.java - src/jdk.localedata/share/classes/sun/text/resources/sv/JavaTimeSupplementary_sv.java - src/jdk.localedata/share/classes/sun/text/resources/sv/SE/FormatData_sv_SE.java - src/jdk.localedata/share/classes/sun/text/resources/th/BreakIteratorInfo_th.java - src/jdk.localedata/share/classes/sun/text/resources/th/BreakIteratorRules_th.java - src/jdk.localedata/share/classes/sun/text/resources/th/CollationData_th.java - src/jdk.localedata/share/classes/sun/text/resources/th/FormatData_th.java - src/jdk.localedata/share/classes/sun/text/resources/th/JavaTimeSupplementary_th.java - src/jdk.localedata/share/classes/sun/text/resources/th/TH/FormatData_th_TH.java - src/jdk.localedata/share/classes/sun/text/resources/th/thai_dict - src/jdk.localedata/share/classes/sun/text/resources/tr/CollationData_tr.java - src/jdk.localedata/share/classes/sun/text/resources/tr/FormatData_tr.java - src/jdk.localedata/share/classes/sun/text/resources/tr/JavaTimeSupplementary_tr.java - src/jdk.localedata/share/classes/sun/text/resources/tr/TR/FormatData_tr_TR.java - src/jdk.localedata/share/classes/sun/text/resources/uk/CollationData_uk.java - src/jdk.localedata/share/classes/sun/text/resources/uk/FormatData_uk.java - src/jdk.localedata/share/classes/sun/text/resources/uk/JavaTimeSupplementary_uk.java - src/jdk.localedata/share/classes/sun/text/resources/uk/UA/FormatData_uk_UA.java - src/jdk.localedata/share/classes/sun/text/resources/vi/CollationData_vi.java - src/jdk.localedata/share/classes/sun/text/resources/vi/FormatData_vi.java - src/jdk.localedata/share/classes/sun/text/resources/vi/JavaTimeSupplementary_vi.java - src/jdk.localedata/share/classes/sun/text/resources/vi/VN/FormatData_vi_VN.java - src/jdk.localedata/share/classes/sun/text/resources/zh/CN/FormatData_zh_CN.java - src/jdk.localedata/share/classes/sun/text/resources/zh/CollationData_zh.java - src/jdk.localedata/share/classes/sun/text/resources/zh/FormatData_zh.java - src/jdk.localedata/share/classes/sun/text/resources/zh/HK/CollationData_zh_HK.java - src/jdk.localedata/share/classes/sun/text/resources/zh/HK/FormatData_zh_HK.java - src/jdk.localedata/share/classes/sun/text/resources/zh/JavaTimeSupplementary_zh.java - src/jdk.localedata/share/classes/sun/text/resources/zh/SG/FormatData_zh_SG.java - src/jdk.localedata/share/classes/sun/text/resources/zh/TW/CollationData_zh_TW.java - src/jdk.localedata/share/classes/sun/text/resources/zh/TW/FormatData_zh_TW.java - src/jdk.localedata/share/classes/sun/text/resources/zh/TW/JavaTimeSupplementary_zh_TW.java - src/jdk.localedata/share/classes/sun/util/resources/ar/AE/CurrencyNames_ar_AE.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/BH/CurrencyNames_ar_BH.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/CalendarData_ar.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/DZ/CurrencyNames_ar_DZ.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/EG/CurrencyNames_ar_EG.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/IQ/CurrencyNames_ar_IQ.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/JO/CurrencyNames_ar_JO.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/KW/CurrencyNames_ar_KW.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/LB/CurrencyNames_ar_LB.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/LY/CurrencyNames_ar_LY.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/LocaleNames_ar.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/MA/CurrencyNames_ar_MA.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/OM/CurrencyNames_ar_OM.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/QA/CurrencyNames_ar_QA.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/SA/CurrencyNames_ar_SA.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/SD/CurrencyNames_ar_SD.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/SY/CurrencyNames_ar_SY.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/TN/CurrencyNames_ar_TN.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/YE/CurrencyNames_ar_YE.properties - src/jdk.localedata/share/classes/sun/util/resources/be/BY/CurrencyNames_be_BY.properties - src/jdk.localedata/share/classes/sun/util/resources/be/CalendarData_be.properties - src/jdk.localedata/share/classes/sun/util/resources/be/LocaleNames_be.properties - src/jdk.localedata/share/classes/sun/util/resources/bg/BG/CurrencyNames_bg_BG.properties - src/jdk.localedata/share/classes/sun/util/resources/bg/CalendarData_bg.properties - src/jdk.localedata/share/classes/sun/util/resources/bg/LocaleNames_bg.properties - src/jdk.localedata/share/classes/sun/util/resources/ca/CalendarData_ca.properties - src/jdk.localedata/share/classes/sun/util/resources/ca/ES/CurrencyNames_ca_ES.properties - src/jdk.localedata/share/classes/sun/util/resources/ca/LocaleNames_ca.properties - src/jdk.localedata/share/classes/sun/util/resources/cs/CZ/CurrencyNames_cs_CZ.properties - src/jdk.localedata/share/classes/sun/util/resources/cs/CalendarData_cs.properties - src/jdk.localedata/share/classes/sun/util/resources/cs/LocaleNames_cs.properties - src/jdk.localedata/share/classes/sun/util/resources/da/CalendarData_da.properties - src/jdk.localedata/share/classes/sun/util/resources/da/DK/CurrencyNames_da_DK.properties - src/jdk.localedata/share/classes/sun/util/resources/da/LocaleNames_da.properties - src/jdk.localedata/share/classes/sun/util/resources/de/AT/CurrencyNames_de_AT.properties - src/jdk.localedata/share/classes/sun/util/resources/de/CH/CurrencyNames_de_CH.properties - src/jdk.localedata/share/classes/sun/util/resources/de/CalendarData_de.properties - src/jdk.localedata/share/classes/sun/util/resources/de/CurrencyNames_de.properties - src/jdk.localedata/share/classes/sun/util/resources/de/DE/CurrencyNames_de_DE.properties - src/jdk.localedata/share/classes/sun/util/resources/de/GR/CurrencyNames_de_GR.properties - src/jdk.localedata/share/classes/sun/util/resources/de/LU/CurrencyNames_de_LU.properties - src/jdk.localedata/share/classes/sun/util/resources/de/LocaleNames_de.properties - src/jdk.localedata/share/classes/sun/util/resources/de/TimeZoneNames_de.java - src/jdk.localedata/share/classes/sun/util/resources/el/CY/CalendarData_el_CY.properties - src/jdk.localedata/share/classes/sun/util/resources/el/CY/CurrencyNames_el_CY.properties - src/jdk.localedata/share/classes/sun/util/resources/el/CY/LocaleNames_el_CY.properties - src/jdk.localedata/share/classes/sun/util/resources/el/CalendarData_el.properties - src/jdk.localedata/share/classes/sun/util/resources/el/GR/CurrencyNames_el_GR.properties - src/jdk.localedata/share/classes/sun/util/resources/el/LocaleNames_el.properties - src/jdk.localedata/share/classes/sun/util/resources/en/AU/CurrencyNames_en_AU.properties - src/jdk.localedata/share/classes/sun/util/resources/en/CA/CurrencyNames_en_CA.properties - src/jdk.localedata/share/classes/sun/util/resources/en/CA/TimeZoneNames_en_CA.java - src/jdk.localedata/share/classes/sun/util/resources/en/GB/CalendarData_en_GB.properties - src/jdk.localedata/share/classes/sun/util/resources/en/GB/CurrencyNames_en_GB.properties - src/jdk.localedata/share/classes/sun/util/resources/en/GB/TimeZoneNames_en_GB.java - src/jdk.localedata/share/classes/sun/util/resources/en/IE/CalendarData_en_IE.properties - src/jdk.localedata/share/classes/sun/util/resources/en/IE/CurrencyNames_en_IE.properties - src/jdk.localedata/share/classes/sun/util/resources/en/IE/TimeZoneNames_en_IE.java - src/jdk.localedata/share/classes/sun/util/resources/en/IN/CurrencyNames_en_IN.properties - src/jdk.localedata/share/classes/sun/util/resources/en/MT/CalendarData_en_MT.properties - src/jdk.localedata/share/classes/sun/util/resources/en/MT/CurrencyNames_en_MT.properties - src/jdk.localedata/share/classes/sun/util/resources/en/MT/LocaleNames_en_MT.properties - src/jdk.localedata/share/classes/sun/util/resources/en/NZ/CurrencyNames_en_NZ.properties - src/jdk.localedata/share/classes/sun/util/resources/en/PH/CurrencyNames_en_PH.properties - src/jdk.localedata/share/classes/sun/util/resources/en/PH/LocaleNames_en_PH.properties - src/jdk.localedata/share/classes/sun/util/resources/en/SG/CurrencyNames_en_SG.properties - src/jdk.localedata/share/classes/sun/util/resources/en/SG/LocaleNames_en_SG.properties - src/jdk.localedata/share/classes/sun/util/resources/en/ZA/CurrencyNames_en_ZA.properties - src/jdk.localedata/share/classes/sun/util/resources/es/AR/CurrencyNames_es_AR.properties - src/jdk.localedata/share/classes/sun/util/resources/es/BO/CurrencyNames_es_BO.properties - src/jdk.localedata/share/classes/sun/util/resources/es/CL/CurrencyNames_es_CL.properties - src/jdk.localedata/share/classes/sun/util/resources/es/CO/CurrencyNames_es_CO.properties - src/jdk.localedata/share/classes/sun/util/resources/es/CR/CurrencyNames_es_CR.properties - src/jdk.localedata/share/classes/sun/util/resources/es/CU/CurrencyNames_es_CU.properties - src/jdk.localedata/share/classes/sun/util/resources/es/CalendarData_es.properties - src/jdk.localedata/share/classes/sun/util/resources/es/CurrencyNames_es.properties - src/jdk.localedata/share/classes/sun/util/resources/es/DO/CurrencyNames_es_DO.properties - src/jdk.localedata/share/classes/sun/util/resources/es/EC/CurrencyNames_es_EC.properties - src/jdk.localedata/share/classes/sun/util/resources/es/ES/CalendarData_es_ES.properties - src/jdk.localedata/share/classes/sun/util/resources/es/ES/CurrencyNames_es_ES.properties - src/jdk.localedata/share/classes/sun/util/resources/es/GT/CurrencyNames_es_GT.properties - src/jdk.localedata/share/classes/sun/util/resources/es/HN/CurrencyNames_es_HN.properties - src/jdk.localedata/share/classes/sun/util/resources/es/LocaleNames_es.properties - src/jdk.localedata/share/classes/sun/util/resources/es/MX/CurrencyNames_es_MX.properties - src/jdk.localedata/share/classes/sun/util/resources/es/NI/CurrencyNames_es_NI.properties - src/jdk.localedata/share/classes/sun/util/resources/es/PA/CurrencyNames_es_PA.properties - src/jdk.localedata/share/classes/sun/util/resources/es/PE/CurrencyNames_es_PE.properties - src/jdk.localedata/share/classes/sun/util/resources/es/PR/CurrencyNames_es_PR.properties - src/jdk.localedata/share/classes/sun/util/resources/es/PY/CurrencyNames_es_PY.properties - src/jdk.localedata/share/classes/sun/util/resources/es/SV/CurrencyNames_es_SV.properties - src/jdk.localedata/share/classes/sun/util/resources/es/TimeZoneNames_es.java - src/jdk.localedata/share/classes/sun/util/resources/es/US/CalendarData_es_US.properties - src/jdk.localedata/share/classes/sun/util/resources/es/US/CurrencyNames_es_US.properties - src/jdk.localedata/share/classes/sun/util/resources/es/US/LocaleNames_es_US.properties - src/jdk.localedata/share/classes/sun/util/resources/es/UY/CurrencyNames_es_UY.properties - src/jdk.localedata/share/classes/sun/util/resources/es/VE/CurrencyNames_es_VE.properties - src/jdk.localedata/share/classes/sun/util/resources/et/CalendarData_et.properties - src/jdk.localedata/share/classes/sun/util/resources/et/EE/CurrencyNames_et_EE.properties - src/jdk.localedata/share/classes/sun/util/resources/et/LocaleNames_et.properties - src/jdk.localedata/share/classes/sun/util/resources/fi/CalendarData_fi.properties - src/jdk.localedata/share/classes/sun/util/resources/fi/FI/CurrencyNames_fi_FI.properties - src/jdk.localedata/share/classes/sun/util/resources/fi/LocaleNames_fi.properties - src/jdk.localedata/share/classes/sun/util/resources/fr/BE/CurrencyNames_fr_BE.properties - src/jdk.localedata/share/classes/sun/util/resources/fr/CA/CalendarData_fr_CA.properties - src/jdk.localedata/share/classes/sun/util/resources/fr/CA/CurrencyNames_fr_CA.properties - src/jdk.localedata/share/classes/sun/util/resources/fr/CH/CurrencyNames_fr_CH.properties - src/jdk.localedata/share/classes/sun/util/resources/fr/CalendarData_fr.properties - src/jdk.localedata/share/classes/sun/util/resources/fr/CurrencyNames_fr.properties - src/jdk.localedata/share/classes/sun/util/resources/fr/FR/CurrencyNames_fr_FR.properties - src/jdk.localedata/share/classes/sun/util/resources/fr/LU/CurrencyNames_fr_LU.properties - src/jdk.localedata/share/classes/sun/util/resources/fr/LocaleNames_fr.properties - src/jdk.localedata/share/classes/sun/util/resources/fr/TimeZoneNames_fr.java - src/jdk.localedata/share/classes/sun/util/resources/ga/IE/CurrencyNames_ga_IE.properties - src/jdk.localedata/share/classes/sun/util/resources/ga/LocaleNames_ga.properties - src/jdk.localedata/share/classes/sun/util/resources/hi/CalendarData_hi.properties - src/jdk.localedata/share/classes/sun/util/resources/hi/IN/CurrencyNames_hi_IN.properties - src/jdk.localedata/share/classes/sun/util/resources/hi/LocaleNames_hi.properties - src/jdk.localedata/share/classes/sun/util/resources/hi/TimeZoneNames_hi.java - src/jdk.localedata/share/classes/sun/util/resources/hr/CalendarData_hr.properties - src/jdk.localedata/share/classes/sun/util/resources/hr/HR/CurrencyNames_hr_HR.properties - src/jdk.localedata/share/classes/sun/util/resources/hr/LocaleNames_hr.properties - src/jdk.localedata/share/classes/sun/util/resources/hu/CalendarData_hu.properties - src/jdk.localedata/share/classes/sun/util/resources/hu/HU/CurrencyNames_hu_HU.properties - src/jdk.localedata/share/classes/sun/util/resources/hu/LocaleNames_hu.properties - src/jdk.localedata/share/classes/sun/util/resources/in/ID/CalendarData_in_ID.properties - src/jdk.localedata/share/classes/sun/util/resources/in/ID/CurrencyNames_in_ID.properties - src/jdk.localedata/share/classes/sun/util/resources/in/LocaleNames_in.properties - src/jdk.localedata/share/classes/sun/util/resources/is/CalendarData_is.properties - src/jdk.localedata/share/classes/sun/util/resources/is/IS/CurrencyNames_is_IS.properties - src/jdk.localedata/share/classes/sun/util/resources/is/LocaleNames_is.properties - src/jdk.localedata/share/classes/sun/util/resources/it/CH/CurrencyNames_it_CH.properties - src/jdk.localedata/share/classes/sun/util/resources/it/CalendarData_it.properties - src/jdk.localedata/share/classes/sun/util/resources/it/CurrencyNames_it.properties - src/jdk.localedata/share/classes/sun/util/resources/it/IT/CurrencyNames_it_IT.properties - src/jdk.localedata/share/classes/sun/util/resources/it/LocaleNames_it.properties - src/jdk.localedata/share/classes/sun/util/resources/it/TimeZoneNames_it.java - src/jdk.localedata/share/classes/sun/util/resources/iw/CalendarData_iw.properties - src/jdk.localedata/share/classes/sun/util/resources/iw/IL/CurrencyNames_iw_IL.properties - src/jdk.localedata/share/classes/sun/util/resources/iw/LocaleNames_iw.properties - src/jdk.localedata/share/classes/sun/util/resources/ja/CalendarData_ja.properties - src/jdk.localedata/share/classes/sun/util/resources/ja/CurrencyNames_ja.properties - src/jdk.localedata/share/classes/sun/util/resources/ja/JP/CurrencyNames_ja_JP.properties - src/jdk.localedata/share/classes/sun/util/resources/ja/LocaleNames_ja.properties - src/jdk.localedata/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java - src/jdk.localedata/share/classes/sun/util/resources/ko/CalendarData_ko.properties - src/jdk.localedata/share/classes/sun/util/resources/ko/CurrencyNames_ko.properties - src/jdk.localedata/share/classes/sun/util/resources/ko/KR/CurrencyNames_ko_KR.properties - src/jdk.localedata/share/classes/sun/util/resources/ko/LocaleNames_ko.properties - src/jdk.localedata/share/classes/sun/util/resources/ko/TimeZoneNames_ko.java - src/jdk.localedata/share/classes/sun/util/resources/lt/CalendarData_lt.properties - src/jdk.localedata/share/classes/sun/util/resources/lt/LT/CurrencyNames_lt_LT.properties - src/jdk.localedata/share/classes/sun/util/resources/lt/LocaleNames_lt.properties - src/jdk.localedata/share/classes/sun/util/resources/lv/CalendarData_lv.properties - src/jdk.localedata/share/classes/sun/util/resources/lv/LV/CurrencyNames_lv_LV.properties - src/jdk.localedata/share/classes/sun/util/resources/lv/LocaleNames_lv.properties - src/jdk.localedata/share/classes/sun/util/resources/mk/CalendarData_mk.properties - src/jdk.localedata/share/classes/sun/util/resources/mk/LocaleNames_mk.properties - src/jdk.localedata/share/classes/sun/util/resources/mk/MK/CurrencyNames_mk_MK.properties - src/jdk.localedata/share/classes/sun/util/resources/ms/LocaleNames_ms.properties - src/jdk.localedata/share/classes/sun/util/resources/ms/MY/CalendarData_ms_MY.properties - src/jdk.localedata/share/classes/sun/util/resources/ms/MY/CurrencyNames_ms_MY.properties - src/jdk.localedata/share/classes/sun/util/resources/mt/CalendarData_mt.properties - src/jdk.localedata/share/classes/sun/util/resources/mt/LocaleNames_mt.properties - src/jdk.localedata/share/classes/sun/util/resources/mt/MT/CalendarData_mt_MT.properties - src/jdk.localedata/share/classes/sun/util/resources/mt/MT/CurrencyNames_mt_MT.properties - src/jdk.localedata/share/classes/sun/util/resources/nl/BE/CurrencyNames_nl_BE.properties - src/jdk.localedata/share/classes/sun/util/resources/nl/CalendarData_nl.properties - src/jdk.localedata/share/classes/sun/util/resources/nl/LocaleNames_nl.properties - src/jdk.localedata/share/classes/sun/util/resources/nl/NL/CurrencyNames_nl_NL.properties - src/jdk.localedata/share/classes/sun/util/resources/no/CalendarData_no.properties - src/jdk.localedata/share/classes/sun/util/resources/no/LocaleNames_no.properties - src/jdk.localedata/share/classes/sun/util/resources/no/NO/CurrencyNames_no_NO.properties - src/jdk.localedata/share/classes/sun/util/resources/no/NO/LocaleNames_no_NO_NY.properties - src/jdk.localedata/share/classes/sun/util/resources/pl/CalendarData_pl.properties - src/jdk.localedata/share/classes/sun/util/resources/pl/LocaleNames_pl.properties - src/jdk.localedata/share/classes/sun/util/resources/pl/PL/CurrencyNames_pl_PL.properties - src/jdk.localedata/share/classes/sun/util/resources/pt/BR/CalendarData_pt_BR.properties - src/jdk.localedata/share/classes/sun/util/resources/pt/BR/CurrencyNames_pt_BR.properties - src/jdk.localedata/share/classes/sun/util/resources/pt/BR/LocaleNames_pt_BR.properties - src/jdk.localedata/share/classes/sun/util/resources/pt/BR/TimeZoneNames_pt_BR.java - src/jdk.localedata/share/classes/sun/util/resources/pt/CalendarData_pt.properties - src/jdk.localedata/share/classes/sun/util/resources/pt/CurrencyNames_pt.properties - src/jdk.localedata/share/classes/sun/util/resources/pt/LocaleNames_pt.properties - src/jdk.localedata/share/classes/sun/util/resources/pt/PT/CalendarData_pt_PT.properties - src/jdk.localedata/share/classes/sun/util/resources/pt/PT/CurrencyNames_pt_PT.properties - src/jdk.localedata/share/classes/sun/util/resources/pt/PT/LocaleNames_pt_PT.properties - src/jdk.localedata/share/classes/sun/util/resources/ro/CalendarData_ro.properties - src/jdk.localedata/share/classes/sun/util/resources/ro/LocaleNames_ro.properties - src/jdk.localedata/share/classes/sun/util/resources/ro/RO/CurrencyNames_ro_RO.properties - src/jdk.localedata/share/classes/sun/util/resources/ru/CalendarData_ru.properties - src/jdk.localedata/share/classes/sun/util/resources/ru/LocaleNames_ru.properties - src/jdk.localedata/share/classes/sun/util/resources/ru/RU/CurrencyNames_ru_RU.properties - src/jdk.localedata/share/classes/sun/util/resources/sk/CalendarData_sk.properties - src/jdk.localedata/share/classes/sun/util/resources/sk/LocaleNames_sk.properties - src/jdk.localedata/share/classes/sun/util/resources/sk/SK/CurrencyNames_sk_SK.properties - src/jdk.localedata/share/classes/sun/util/resources/sl/CalendarData_sl.properties - src/jdk.localedata/share/classes/sun/util/resources/sl/LocaleNames_sl.properties - src/jdk.localedata/share/classes/sun/util/resources/sl/SI/CurrencyNames_sl_SI.properties - src/jdk.localedata/share/classes/sun/util/resources/sq/AL/CurrencyNames_sq_AL.properties - src/jdk.localedata/share/classes/sun/util/resources/sq/CalendarData_sq.properties - src/jdk.localedata/share/classes/sun/util/resources/sq/LocaleNames_sq.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/BA/CalendarData_sr_Latn_BA.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/BA/CurrencyNames_sr_BA.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/BA/CurrencyNames_sr_Latn_BA.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/CS/CurrencyNames_sr_CS.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/CalendarData_sr.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/LocaleNames_sr.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/LocaleNames_sr_Latn.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/ME/CalendarData_sr_Latn_ME.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/ME/CurrencyNames_sr_Latn_ME.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/ME/CurrencyNames_sr_ME.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/RS/CalendarData_sr_Latn_RS.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/RS/CurrencyNames_sr_Latn_RS.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/RS/CurrencyNames_sr_RS.properties - src/jdk.localedata/share/classes/sun/util/resources/sv/CalendarData_sv.properties - src/jdk.localedata/share/classes/sun/util/resources/sv/CurrencyNames_sv.properties - src/jdk.localedata/share/classes/sun/util/resources/sv/LocaleNames_sv.properties - src/jdk.localedata/share/classes/sun/util/resources/sv/SE/CurrencyNames_sv_SE.properties - src/jdk.localedata/share/classes/sun/util/resources/sv/TimeZoneNames_sv.java - src/jdk.localedata/share/classes/sun/util/resources/th/CalendarData_th.properties - src/jdk.localedata/share/classes/sun/util/resources/th/LocaleNames_th.properties - src/jdk.localedata/share/classes/sun/util/resources/th/TH/CurrencyNames_th_TH.properties - src/jdk.localedata/share/classes/sun/util/resources/tr/CalendarData_tr.properties - src/jdk.localedata/share/classes/sun/util/resources/tr/LocaleNames_tr.properties - src/jdk.localedata/share/classes/sun/util/resources/tr/TR/CurrencyNames_tr_TR.properties - src/jdk.localedata/share/classes/sun/util/resources/uk/CalendarData_uk.properties - src/jdk.localedata/share/classes/sun/util/resources/uk/LocaleNames_uk.properties - src/jdk.localedata/share/classes/sun/util/resources/uk/UA/CurrencyNames_uk_UA.properties - src/jdk.localedata/share/classes/sun/util/resources/vi/CalendarData_vi.properties - src/jdk.localedata/share/classes/sun/util/resources/vi/LocaleNames_vi.properties - src/jdk.localedata/share/classes/sun/util/resources/vi/VN/CurrencyNames_vi_VN.properties - src/jdk.localedata/share/classes/sun/util/resources/zh/CN/CurrencyNames_zh_CN.properties - src/jdk.localedata/share/classes/sun/util/resources/zh/CN/TimeZoneNames_zh_CN.java - src/jdk.localedata/share/classes/sun/util/resources/zh/CalendarData_zh.properties - src/jdk.localedata/share/classes/sun/util/resources/zh/HK/CurrencyNames_zh_HK.java - src/jdk.localedata/share/classes/sun/util/resources/zh/HK/LocaleNames_zh_HK.java - src/jdk.localedata/share/classes/sun/util/resources/zh/HK/TimeZoneNames_zh_HK.java - src/jdk.localedata/share/classes/sun/util/resources/zh/LocaleNames_zh.properties - src/jdk.localedata/share/classes/sun/util/resources/zh/SG/CurrencyNames_zh_SG.java - src/jdk.localedata/share/classes/sun/util/resources/zh/SG/LocaleNames_zh_SG.properties - src/jdk.localedata/share/classes/sun/util/resources/zh/TW/CurrencyNames_zh_TW.properties - src/jdk.localedata/share/classes/sun/util/resources/zh/TW/LocaleNames_zh_TW.properties - src/jdk.localedata/share/classes/sun/util/resources/zh/TW/TimeZoneNames_zh_TW.java Changeset: 531aa83f6017 Author: thartmann Date: 2016-03-03 08:58 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/531aa83f6017 8151024: Remove TCKJapaneseChronology.java from the problem list Summary: Remove TCKJapaneseChronology.java from the problem list after JDK-8134979 was fixed. Reviewed-by: vlivanov ! test/ProblemList.txt Changeset: 6e19808c749b Author: aeriksso Date: 2016-02-18 16:15 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6e19808c749b 8149743: JVM crash after debugger hotswap with lambdas Reviewed-by: sspitsyn, coleenp, dcubed + test/com/sun/jdi/RedefineAddPrivateMethod.sh Changeset: 76821da52279 Author: ctornqvi Date: 2016-02-24 16:33 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/76821da52279 8150490: Update OS detection code to recognize Windows Server 2016 Reviewed-by: mgronlun, alanb, dholmes ! src/java.base/windows/native/libjava/java_props_md.c Changeset: 460323d4a285 Author: csahu Date: 2016-02-26 16:19 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/460323d4a285 8130425: libjvm crash due to stack overflow in executables with 32k tbss/tdata Reviewed-by: kevinw, dholmes Contributed-by: cheleswer.sahu at oracle.com ! src/java.base/share/classes/java/lang/ProcessHandleImpl.java Changeset: 924046b4db80 Author: jwilhelm Date: 2016-02-29 15:24 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/924046b4db80 Merge Changeset: 372799a54371 Author: mgronlun Date: 2016-03-01 23:54 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/372799a54371 8143235: Remove libjfr mapfile Reviewed-by: jbachorik, egahlin - make/mapfiles/libjfr/mapfile-vers ! make/src/classes/build/tools/module/boot.modules Changeset: 9c3238e7fd20 Author: mgronlun Date: 2016-03-02 21:39 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9c3238e7fd20 8151053: com/sun/jdi/StepTest.java fails in 2016-03-01 JDK9-hs-rt nightly Reviewed-by: dcubed, egahlin ! test/com/sun/jdi/TestScaffold.java Changeset: d4df4a7f910a Author: rprotacio Date: 2016-03-02 14:52 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d4df4a7f910a 8145098: JNI GetVersion should return JNI_VERSION_9 Summary: Updated JNI_VERSION for current version to be JNI_VERSION_9 Reviewed-by: hseigel, gtriantafill, dholmes, alanb ! src/java.base/share/native/include/jni.h Changeset: 3a76a8462486 Author: hseigel Date: 2016-03-02 23:48 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3a76a8462486 Merge Changeset: 104544ae1e2f Author: mgronlun Date: 2016-03-03 12:34 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/104544ae1e2f 8151100: Test java/lang/instrument/NativeMethodPrefixAgent.java can't attempt to do CheckIntrinsics Reviewed-by: sspitsyn, ddmitriev, egahlin ! test/java/lang/instrument/NativeMethodPrefixAgent.java Changeset: 7e330efd38d6 Author: aeriksso Date: 2016-03-03 18:05 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7e330efd38d6 8151064: com/sun/jdi/RedefineAddPrivateMethod.sh fails intermittently Reviewed-by: dsamersoff, sspitsyn ! test/com/sun/jdi/RedefineAddPrivateMethod.sh Changeset: 08f06281085f Author: jwilhelm Date: 2016-03-05 10:10 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/08f06281085f Merge - make/mapfiles/libjfr/mapfile-vers Changeset: fc0cc9b79b16 Author: amurillo Date: 2016-03-05 20:46 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fc0cc9b79b16 Merge - make/mapfiles/libjfr/mapfile-vers Changeset: 24661132af5c Author: amurillo Date: 2016-03-08 19:03 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/24661132af5c Merge - make/mapfiles/libjfr/mapfile-vers ! make/src/classes/build/tools/module/boot.modules ! src/java.base/share/classes/java/lang/String.java Changeset: 55a1107a6092 Author: amlu Date: 2016-03-09 11:35 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/55a1107a6092 8151260: Mark URLPermission/URLTest.java and ipv6tests/TcpTest.java as intermittently failing Reviewed-by: chegar ! test/java/net/URLPermission/URLTest.java ! test/java/net/ipv6tests/TcpTest.java Changeset: 4939aa2441b6 Author: michaelm Date: 2016-03-09 12:11 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4939aa2441b6 8151441: Completion result in httpclient Exchange.java lost Reviewed-by: chegar ! src/java.httpclient/share/classes/java/net/http/Exchange.java + test/java/net/httpclient/ShortRequestBody.java Changeset: 371fba6ca8d1 Author: michaelm Date: 2016-03-09 13:37 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/371fba6ca8d1 8151299: Http client SelectorManager overwriting read and write events Reviewed-by: chegar ! src/java.httpclient/share/classes/java/net/http/HttpClientImpl.java + test/java/net/httpclient/whitebox/TEST.properties + test/java/net/httpclient/whitebox/java/net/http/SelectorTest.java Changeset: ae9d55a7618d Author: plevart Date: 2016-03-09 21:17 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ae9d55a7618d 8149925: We don't need jdk.internal.ref.Cleaner any more - part1 Summary: 1st part of removing legacy jdk.internal.ref.Cleaner Reviewed-by: chegar, mchung ! src/java.base/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/java.base/share/classes/java/lang/ref/Cleaner.java ! src/java.base/share/classes/jdk/internal/misc/InnocuousThread.java ! src/java.base/share/classes/jdk/internal/ref/CleanerImpl.java ! src/java.base/share/classes/sun/nio/ch/IOVecWrapper.java ! src/java.base/share/classes/sun/nio/ch/Util.java ! src/java.base/share/classes/sun/nio/fs/NativeBuffer.java ! src/java.base/share/classes/sun/nio/fs/NativeBuffers.java ! src/java.base/windows/classes/sun/nio/fs/WindowsWatchService.java Changeset: efc28eabde10 Author: rriggs Date: 2016-03-10 09:35 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/efc28eabde10 8043329: Wrong variable used in java.util.Collections javadoc code Reviewed-by: lancea, rriggs Contributed-by: merkel05 at gmail.com ! src/java.base/share/classes/java/util/Collections.java Changeset: 00fe741f4eff Author: lana Date: 2016-03-10 09:50 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/00fe741f4eff Merge - make/lib/Lib-jdk.deploy.osx.gmk - make/mapfiles/libjfr/mapfile-vers - src/java.base/share/classes/sun/misc/ASCIICaseInsensitiveComparator.java - src/jdk.deploy.osx/macosx/classes/com/apple/concurrent/Dispatch.java - src/jdk.deploy.osx/macosx/classes/com/apple/concurrent/LibDispatchConcurrentQueue.java - src/jdk.deploy.osx/macosx/classes/com/apple/concurrent/LibDispatchMainQueue.java - src/jdk.deploy.osx/macosx/classes/com/apple/concurrent/LibDispatchNative.java - src/jdk.deploy.osx/macosx/classes/com/apple/concurrent/LibDispatchQueue.java - src/jdk.deploy.osx/macosx/classes/com/apple/concurrent/LibDispatchRetainedResource.java - src/jdk.deploy.osx/macosx/classes/com/apple/concurrent/LibDispatchSerialQueue.java - src/jdk.deploy.osx/macosx/classes/com/apple/concurrent/package.html - src/jdk.deploy.osx/macosx/native/libosx/CFileManager.m - src/jdk.deploy.osx/macosx/native/libosx/Dispatch.m Changeset: 13be3e542a07 Author: mchung Date: 2016-03-10 11:52 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/13be3e542a07 8151660: Revert NativeBuffer.java to use jdk.internal.ref.Cleaner Reviewed-by: rriggs ! src/java.base/share/classes/sun/nio/fs/NativeBuffer.java Changeset: 90594aa72401 Author: prappo Date: 2016-03-11 18:35 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/90594aa72401 8151065: Typo in javax.naming.CompoundName Reviewed-by: vinnie, prappo Contributed-by: Abhijit Roy ! src/java.naming/share/classes/javax/naming/CompoundName.java Changeset: 0a1b582d18b3 Author: darcy Date: 2016-03-11 10:06 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0a1b582d18b3 8151679: Mark SignatureOffsets.java as intermittently failing Reviewed-by: xuelei ! test/sun/security/mscapi/SignatureOffsets.java Changeset: 897369f4e422 Author: rriggs Date: 2016-03-11 12:53 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/897369f4e422 8151063: Typo in java.lang.invoke.StringConcatFactory javadoc Reviewed-by: prappo, rriggs Contributed-by: Abhijit Roy ! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java Changeset: 63c286f2751b Author: jnimeh Date: 2016-03-11 10:54 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/63c286f2751b 8132942: ServerHandshaker should not throw SSLHandshakeException when CertificateStatus constructor is called with invalid arguments Summary: Performs argument checking on inputs to the CertificateStatus constructor in order to eliminate the need for exception processing. Also pulls stapling processing logic out to its own method. Reviewed-by: xuelei ! src/java.base/share/classes/sun/security/ssl/HandshakeMessage.java ! src/java.base/share/classes/sun/security/ssl/ServerHandshaker.java Changeset: 5f158e96926a Author: bpb Date: 2016-02-01 15:00 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5f158e96926a 8148628: TIFFDirectory(getAsMetaData) created with one TIFFField having a IFD pointer tag throws ClassCastException & other naming differences (JEP 262) Summary: Clean up some handling of TIFFDirectory instances contained in TIFFFields and make a couple of minor changes to Exif and GeoTIFF tag names. Reviewed-by: prr ! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFFieldNode.java ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/ExifTIFFTagSet.java ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/GeoTIFFTagSet.java ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/TIFFDirectory.java Changeset: 61db74fa733f Author: alexsch Date: 2016-02-11 00:19 +0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/61db74fa733f 8139508: Debug option does not work in appletviewer Reviewed-by: prr, ssadetsky ! src/java.desktop/share/classes/sun/applet/Main.java ! src/java.desktop/share/classes/sun/applet/resources/MsgAppletViewer.java Changeset: bf20dd25a7ac Author: bpb Date: 2016-02-10 13:49 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/bf20dd25a7ac 8149120: TIFFField constructor throws ArrayIndexOutOfBoundsException and IllegalArgumentException for scenarios explained in description Summary: Clean up parameter checking in TIFFField. Reviewed-by: prr ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/TIFFField.java Changeset: 3eda6cd3f504 Author: lbourges Date: 2016-02-11 09:08 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3eda6cd3f504 8149338: JVM Crash caused by Marlin renderer not handling NaN coordinates Summary: use first / last Y crossings to compute edge min/max Y and ensure consistency with edgeBuckets / edgeBucketCounts arrays Reviewed-by: flar, prr ! src/java.desktop/share/classes/sun/java2d/marlin/Renderer.java + test/sun/java2d/marlin/CrashNaNTest.java ! test/sun/java2d/marlin/TextClipErrorTest.java Changeset: ec073cb4b02d Author: kshefov Date: 2016-02-11 12:24 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ec073cb4b02d 8131751: [TEST_BUG] Test javax/swing/plaf/gtk/crash/RenderBadPictureCrash.java fails UnsupportedOperationException Reviewed-by: alexsch, ssadetsky Contributed-by: Vikrant Agarwal ! test/javax/swing/plaf/gtk/crash/RenderBadPictureCrash.java Changeset: b48e7e3d4732 Author: bpb Date: 2016-02-11 13:42 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b48e7e3d4732 8149593: Change foo to {@code foo} in TIFF plugin classes Summary: Change foo to {@code foo} in TIFF plugin classes and 2015 to 2016 where needed. Reviewed-by: prr, darcy ! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFBaseJPEGCompressor.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFColorConverter.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFCompressor.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFDecompressor.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFExifJPEGCompressor.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFFaxCompressor.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFFieldNode.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFIFD.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFImageMetadata.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFImageReader.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFImageWriteParam.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFImageWriter.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFJPEGCompressor.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFLZWDecompressor.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFLZWUtil.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFNullDecompressor.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFOldJPEGDecompressor.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFRLECompressor.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFRenderedImage.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFT4Compressor.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFT6Compressor.java ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/BaselineTIFFTagSet.java ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/ExifGPSTagSet.java ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/ExifInteroperabilityTagSet.java ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/ExifParentTIFFTagSet.java ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/ExifTIFFTagSet.java ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/FaxTIFFTagSet.java ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/GeoTIFFTagSet.java ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/TIFFDirectory.java ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/TIFFField.java ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/TIFFImageReadParam.java ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/TIFFTag.java ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/TIFFTagSet.java Changeset: e2bd42eace1b Author: arapte Date: 2016-02-15 14:36 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e2bd42eace1b 8025001: setFocusTraversalPolicy() to ContainerOrderFocusTraversalPolicy results in an infinite loop Reviewed-by: ssadetsky, psadhukhan ! src/java.desktop/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java + test/java/awt/Focus/FocusTraversalPolicy/ContainerOrderFTPTest.java Changeset: 95c8ba53bdbf Author: serb Date: 2016-02-12 16:08 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/95c8ba53bdbf 8130061: java.beans.EventHandler.create does not specify how it fails when an EventHandler cannot be created Reviewed-by: alanb ! src/java.desktop/share/classes/java/beans/EventHandler.java Changeset: ac2935ce7138 Author: serb Date: 2016-02-12 16:09 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ac2935ce7138 8136382: SimpleBeanInfo.loadImage succeeds when running with a security manager Reviewed-by: alanb ! src/java.desktop/share/classes/java/beans/SimpleBeanInfo.java Changeset: e9841bab4f75 Author: ptbrunet Date: 2016-02-16 19:38 -0600 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e9841bab4f75 8149161: CSM call Class.forName in com.sun.java.accessibility.util.Translator Summary: add call to checkPackageAccess Reviewed-by: serb, prr Contributed-by: peter.brunet at oracle.com ! src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/Translator.java Changeset: 0d4ce255e581 Author: aniyogi Date: 2016-02-17 11:44 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0d4ce255e581 8146321: [macosx] JInternalFrame frame icon in wrong position on Mac L&F if icon is not ImageIcon Reviewed-by: serb, alexsch, rchamyal ! src/java.desktop/macosx/classes/com/apple/laf/AquaInternalFrameBorder.java + test/javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java Changeset: d8def65c6c00 Author: serb Date: 2016-02-18 22:11 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d8def65c6c00 8038139: AudioInputStream.getFrameLength() returns wrong value for floating-point WAV Reviewed-by: prr, amenkov ! src/java.desktop/share/classes/com/sun/media/sound/AiffFileReader.java ! src/java.desktop/share/classes/com/sun/media/sound/AiffFileWriter.java ! src/java.desktop/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java ! src/java.desktop/share/classes/com/sun/media/sound/WaveFloatFileReader.java + test/javax/sound/sampled/AudioInputStream/FrameLengthAfterConversion.java Changeset: 2af26cf24f71 Author: psadhukhan Date: 2016-02-23 10:22 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2af26cf24f71 8150233: Missing copyright headers in XSurfaceData/ExtendedKeyCodes Reviewed-by: prr ! src/java.desktop/share/classes/sun/awt/ExtendedKeyCodes.java ! src/java.desktop/unix/classes/sun/java2d/x11/XSurfaceData.java Changeset: b46fd4df8576 Author: mhalder Date: 2016-02-23 10:24 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b46fd4df8576 8147834: [macosx] KeyEvents for function keys F17, F18, F19 return keyCode 0 Reviewed-by: serb, aniyogi ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTEvent.m Changeset: 853b0a3baa6f Author: ddehaven Date: 2016-02-23 09:11 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/853b0a3baa6f Merge - make/src/classes/build/tools/buildmetaindex/BuildMetaIndex.java - make/src/classes/build/tools/generatebreakiteratordata/BreakIteratorRBControl.java - src/java.base/share/classes/sun/misc/InnocuousThread.java - src/java.base/share/classes/sun/misc/LRUCache.java - src/java.base/share/classes/sun/misc/MetaIndex.java - src/java.base/share/classes/sun/misc/NativeSignalHandler.java - src/java.base/share/classes/sun/text/resources/en/FormatData_en.java - src/java.base/share/classes/sun/text/resources/en/JavaTimeSupplementary_en.java - src/java.base/share/classes/sun/text/resources/en/US/FormatData_en_US.java - src/java.base/share/classes/sun/util/resources/en/CalendarData_en.properties - src/java.base/share/classes/sun/util/resources/en/LocaleNames_en.properties - src/java.base/share/classes/sun/util/resources/en/TimeZoneNames_en.java - src/java.base/share/classes/sun/util/resources/en/US/CurrencyNames_en_US.properties - src/java.base/share/native/libjava/NativeSignalHandler.c ! src/java.desktop/share/classes/sun/java2d/marlin/Renderer.java - src/jdk.localedata/share/classes/sun/text/resources/ar/CollationData_ar.java - src/jdk.localedata/share/classes/sun/text/resources/ar/FormatData_ar.java - src/jdk.localedata/share/classes/sun/text/resources/ar/JO/FormatData_ar_JO.java - src/jdk.localedata/share/classes/sun/text/resources/ar/JO/JavaTimeSupplementary_ar_JO.java - src/jdk.localedata/share/classes/sun/text/resources/ar/JavaTimeSupplementary_ar.java - src/jdk.localedata/share/classes/sun/text/resources/ar/LB/FormatData_ar_LB.java - src/jdk.localedata/share/classes/sun/text/resources/ar/LB/JavaTimeSupplementary_ar_LB.java - src/jdk.localedata/share/classes/sun/text/resources/ar/SY/FormatData_ar_SY.java - src/jdk.localedata/share/classes/sun/text/resources/ar/SY/JavaTimeSupplementary_ar_SY.java - src/jdk.localedata/share/classes/sun/text/resources/be/BY/FormatData_be_BY.java - src/jdk.localedata/share/classes/sun/text/resources/be/CollationData_be.java - src/jdk.localedata/share/classes/sun/text/resources/be/FormatData_be.java - src/jdk.localedata/share/classes/sun/text/resources/be/JavaTimeSupplementary_be.java - src/jdk.localedata/share/classes/sun/text/resources/bg/BG/FormatData_bg_BG.java - src/jdk.localedata/share/classes/sun/text/resources/bg/CollationData_bg.java - src/jdk.localedata/share/classes/sun/text/resources/bg/FormatData_bg.java - src/jdk.localedata/share/classes/sun/text/resources/bg/JavaTimeSupplementary_bg.java - src/jdk.localedata/share/classes/sun/text/resources/ca/CollationData_ca.java - src/jdk.localedata/share/classes/sun/text/resources/ca/ES/FormatData_ca_ES.java - src/jdk.localedata/share/classes/sun/text/resources/ca/FormatData_ca.java - src/jdk.localedata/share/classes/sun/text/resources/ca/JavaTimeSupplementary_ca.java - src/jdk.localedata/share/classes/sun/text/resources/cs/CZ/FormatData_cs_CZ.java - src/jdk.localedata/share/classes/sun/text/resources/cs/CollationData_cs.java - src/jdk.localedata/share/classes/sun/text/resources/cs/FormatData_cs.java - src/jdk.localedata/share/classes/sun/text/resources/cs/JavaTimeSupplementary_cs.java - src/jdk.localedata/share/classes/sun/text/resources/da/CollationData_da.java - src/jdk.localedata/share/classes/sun/text/resources/da/DK/FormatData_da_DK.java - src/jdk.localedata/share/classes/sun/text/resources/da/FormatData_da.java - src/jdk.localedata/share/classes/sun/text/resources/da/JavaTimeSupplementary_da.java - src/jdk.localedata/share/classes/sun/text/resources/de/AT/FormatData_de_AT.java - src/jdk.localedata/share/classes/sun/text/resources/de/AT/JavaTimeSupplementary_de_AT.java - src/jdk.localedata/share/classes/sun/text/resources/de/CH/FormatData_de_CH.java - src/jdk.localedata/share/classes/sun/text/resources/de/DE/FormatData_de_DE.java - src/jdk.localedata/share/classes/sun/text/resources/de/FormatData_de.java - src/jdk.localedata/share/classes/sun/text/resources/de/JavaTimeSupplementary_de.java - src/jdk.localedata/share/classes/sun/text/resources/de/LU/FormatData_de_LU.java - src/jdk.localedata/share/classes/sun/text/resources/el/CY/FormatData_el_CY.java - src/jdk.localedata/share/classes/sun/text/resources/el/CollationData_el.java - src/jdk.localedata/share/classes/sun/text/resources/el/FormatData_el.java - src/jdk.localedata/share/classes/sun/text/resources/el/GR/FormatData_el_GR.java - src/jdk.localedata/share/classes/sun/text/resources/el/JavaTimeSupplementary_el.java - src/jdk.localedata/share/classes/sun/text/resources/en/AU/FormatData_en_AU.java - src/jdk.localedata/share/classes/sun/text/resources/en/AU/JavaTimeSupplementary_en_AU.java - src/jdk.localedata/share/classes/sun/text/resources/en/CA/FormatData_en_CA.java - src/jdk.localedata/share/classes/sun/text/resources/en/CA/JavaTimeSupplementary_en_CA.java - src/jdk.localedata/share/classes/sun/text/resources/en/GB/FormatData_en_GB.java - src/jdk.localedata/share/classes/sun/text/resources/en/GB/JavaTimeSupplementary_en_GB.java - src/jdk.localedata/share/classes/sun/text/resources/en/IE/FormatData_en_IE.java - src/jdk.localedata/share/classes/sun/text/resources/en/IE/JavaTimeSupplementary_en_IE.java - src/jdk.localedata/share/classes/sun/text/resources/en/IN/FormatData_en_IN.java - src/jdk.localedata/share/classes/sun/text/resources/en/IN/JavaTimeSupplementary_en_IN.java - src/jdk.localedata/share/classes/sun/text/resources/en/MT/FormatData_en_MT.java - src/jdk.localedata/share/classes/sun/text/resources/en/MT/JavaTimeSupplementary_en_MT.java - src/jdk.localedata/share/classes/sun/text/resources/en/NZ/FormatData_en_NZ.java - src/jdk.localedata/share/classes/sun/text/resources/en/NZ/JavaTimeSupplementary_en_NZ.java - src/jdk.localedata/share/classes/sun/text/resources/en/PH/FormatData_en_PH.java - src/jdk.localedata/share/classes/sun/text/resources/en/SG/FormatData_en_SG.java - src/jdk.localedata/share/classes/sun/text/resources/en/SG/JavaTimeSupplementary_en_SG.java - src/jdk.localedata/share/classes/sun/text/resources/en/ZA/FormatData_en_ZA.java - src/jdk.localedata/share/classes/sun/text/resources/en/ZA/JavaTimeSupplementary_en_ZA.java - src/jdk.localedata/share/classes/sun/text/resources/es/AR/FormatData_es_AR.java - src/jdk.localedata/share/classes/sun/text/resources/es/BO/FormatData_es_BO.java - src/jdk.localedata/share/classes/sun/text/resources/es/CL/FormatData_es_CL.java - src/jdk.localedata/share/classes/sun/text/resources/es/CL/JavaTimeSupplementary_es_CL.java - src/jdk.localedata/share/classes/sun/text/resources/es/CO/FormatData_es_CO.java - src/jdk.localedata/share/classes/sun/text/resources/es/CO/JavaTimeSupplementary_es_CO.java - src/jdk.localedata/share/classes/sun/text/resources/es/CR/FormatData_es_CR.java - src/jdk.localedata/share/classes/sun/text/resources/es/CollationData_es.java - src/jdk.localedata/share/classes/sun/text/resources/es/DO/FormatData_es_DO.java - src/jdk.localedata/share/classes/sun/text/resources/es/EC/FormatData_es_EC.java - src/jdk.localedata/share/classes/sun/text/resources/es/ES/FormatData_es_ES.java - src/jdk.localedata/share/classes/sun/text/resources/es/FormatData_es.java - src/jdk.localedata/share/classes/sun/text/resources/es/GT/FormatData_es_GT.java - src/jdk.localedata/share/classes/sun/text/resources/es/GT/JavaTimeSupplementary_es_GT.java - src/jdk.localedata/share/classes/sun/text/resources/es/HN/FormatData_es_HN.java - src/jdk.localedata/share/classes/sun/text/resources/es/HN/JavaTimeSupplementary_es_HN.java - src/jdk.localedata/share/classes/sun/text/resources/es/JavaTimeSupplementary_es.java - src/jdk.localedata/share/classes/sun/text/resources/es/MX/FormatData_es_MX.java - src/jdk.localedata/share/classes/sun/text/resources/es/MX/JavaTimeSupplementary_es_MX.java - src/jdk.localedata/share/classes/sun/text/resources/es/NI/FormatData_es_NI.java - src/jdk.localedata/share/classes/sun/text/resources/es/PA/FormatData_es_PA.java - src/jdk.localedata/share/classes/sun/text/resources/es/PA/JavaTimeSupplementary_es_PA.java - src/jdk.localedata/share/classes/sun/text/resources/es/PE/FormatData_es_PE.java - src/jdk.localedata/share/classes/sun/text/resources/es/PE/JavaTimeSupplementary_es_PE.java - src/jdk.localedata/share/classes/sun/text/resources/es/PR/FormatData_es_PR.java - src/jdk.localedata/share/classes/sun/text/resources/es/PR/JavaTimeSupplementary_es_PR.java - src/jdk.localedata/share/classes/sun/text/resources/es/PY/FormatData_es_PY.java - src/jdk.localedata/share/classes/sun/text/resources/es/SV/FormatData_es_SV.java - src/jdk.localedata/share/classes/sun/text/resources/es/US/FormatData_es_US.java - src/jdk.localedata/share/classes/sun/text/resources/es/UY/FormatData_es_UY.java - src/jdk.localedata/share/classes/sun/text/resources/es/UY/JavaTimeSupplementary_es_UY.java - src/jdk.localedata/share/classes/sun/text/resources/es/VE/FormatData_es_VE.java - src/jdk.localedata/share/classes/sun/text/resources/et/CollationData_et.java - src/jdk.localedata/share/classes/sun/text/resources/et/EE/FormatData_et_EE.java - src/jdk.localedata/share/classes/sun/text/resources/et/FormatData_et.java - src/jdk.localedata/share/classes/sun/text/resources/et/JavaTimeSupplementary_et.java - src/jdk.localedata/share/classes/sun/text/resources/fi/CollationData_fi.java - src/jdk.localedata/share/classes/sun/text/resources/fi/FI/FormatData_fi_FI.java - src/jdk.localedata/share/classes/sun/text/resources/fi/FormatData_fi.java - src/jdk.localedata/share/classes/sun/text/resources/fi/JavaTimeSupplementary_fi.java - src/jdk.localedata/share/classes/sun/text/resources/fr/BE/FormatData_fr_BE.java - src/jdk.localedata/share/classes/sun/text/resources/fr/BE/JavaTimeSupplementary_fr_BE.java - src/jdk.localedata/share/classes/sun/text/resources/fr/CA/FormatData_fr_CA.java - src/jdk.localedata/share/classes/sun/text/resources/fr/CA/JavaTimeSupplementary_fr_CA.java - src/jdk.localedata/share/classes/sun/text/resources/fr/CH/FormatData_fr_CH.java - src/jdk.localedata/share/classes/sun/text/resources/fr/CH/JavaTimeSupplementary_fr_CH.java - src/jdk.localedata/share/classes/sun/text/resources/fr/CollationData_fr.java - src/jdk.localedata/share/classes/sun/text/resources/fr/FR/FormatData_fr_FR.java - src/jdk.localedata/share/classes/sun/text/resources/fr/FormatData_fr.java - src/jdk.localedata/share/classes/sun/text/resources/fr/JavaTimeSupplementary_fr.java - src/jdk.localedata/share/classes/sun/text/resources/ga/FormatData_ga.java - src/jdk.localedata/share/classes/sun/text/resources/ga/IE/FormatData_ga_IE.java - src/jdk.localedata/share/classes/sun/text/resources/ga/JavaTimeSupplementary_ga.java - src/jdk.localedata/share/classes/sun/text/resources/hi/CollationData_hi.java - src/jdk.localedata/share/classes/sun/text/resources/hi/IN/FormatData_hi_IN.java - src/jdk.localedata/share/classes/sun/text/resources/hi/IN/JavaTimeSupplementary_hi_IN.java - src/jdk.localedata/share/classes/sun/text/resources/hr/CollationData_hr.java - src/jdk.localedata/share/classes/sun/text/resources/hr/FormatData_hr.java - src/jdk.localedata/share/classes/sun/text/resources/hr/HR/FormatData_hr_HR.java - src/jdk.localedata/share/classes/sun/text/resources/hr/JavaTimeSupplementary_hr.java - src/jdk.localedata/share/classes/sun/text/resources/hu/CollationData_hu.java - src/jdk.localedata/share/classes/sun/text/resources/hu/FormatData_hu.java - src/jdk.localedata/share/classes/sun/text/resources/hu/HU/FormatData_hu_HU.java - src/jdk.localedata/share/classes/sun/text/resources/hu/JavaTimeSupplementary_hu.java - src/jdk.localedata/share/classes/sun/text/resources/in/FormatData_in.java - src/jdk.localedata/share/classes/sun/text/resources/in/ID/FormatData_in_ID.java - src/jdk.localedata/share/classes/sun/text/resources/is/CollationData_is.java - src/jdk.localedata/share/classes/sun/text/resources/is/FormatData_is.java - src/jdk.localedata/share/classes/sun/text/resources/is/IS/FormatData_is_IS.java - src/jdk.localedata/share/classes/sun/text/resources/is/JavaTimeSupplementary_is.java - src/jdk.localedata/share/classes/sun/text/resources/it/CH/FormatData_it_CH.java - src/jdk.localedata/share/classes/sun/text/resources/it/CH/JavaTimeSupplementary_it_CH.java - src/jdk.localedata/share/classes/sun/text/resources/it/FormatData_it.java - src/jdk.localedata/share/classes/sun/text/resources/it/IT/FormatData_it_IT.java - src/jdk.localedata/share/classes/sun/text/resources/it/JavaTimeSupplementary_it.java - src/jdk.localedata/share/classes/sun/text/resources/iw/CollationData_iw.java - src/jdk.localedata/share/classes/sun/text/resources/iw/FormatData_iw.java - src/jdk.localedata/share/classes/sun/text/resources/iw/IL/FormatData_iw_IL.java - src/jdk.localedata/share/classes/sun/text/resources/iw/IL/JavaTimeSupplementary_iw_IL.java - src/jdk.localedata/share/classes/sun/text/resources/iw/JavaTimeSupplementary_iw.java - src/jdk.localedata/share/classes/sun/text/resources/ja/CollationData_ja.java - src/jdk.localedata/share/classes/sun/text/resources/ja/FormatData_ja.java - src/jdk.localedata/share/classes/sun/text/resources/ja/JP/FormatData_ja_JP.java - src/jdk.localedata/share/classes/sun/text/resources/ja/JavaTimeSupplementary_ja.java - src/jdk.localedata/share/classes/sun/text/resources/ko/CollationData_ko.java - src/jdk.localedata/share/classes/sun/text/resources/ko/FormatData_ko.java - src/jdk.localedata/share/classes/sun/text/resources/ko/JavaTimeSupplementary_ko.java - src/jdk.localedata/share/classes/sun/text/resources/ko/KR/FormatData_ko_KR.java - src/jdk.localedata/share/classes/sun/text/resources/lt/CollationData_lt.java - src/jdk.localedata/share/classes/sun/text/resources/lt/FormatData_lt.java - src/jdk.localedata/share/classes/sun/text/resources/lt/JavaTimeSupplementary_lt.java - src/jdk.localedata/share/classes/sun/text/resources/lt/LT/FormatData_lt_LT.java - src/jdk.localedata/share/classes/sun/text/resources/lv/CollationData_lv.java - src/jdk.localedata/share/classes/sun/text/resources/lv/FormatData_lv.java - src/jdk.localedata/share/classes/sun/text/resources/lv/JavaTimeSupplementary_lv.java - src/jdk.localedata/share/classes/sun/text/resources/lv/LV/FormatData_lv_LV.java - src/jdk.localedata/share/classes/sun/text/resources/mk/CollationData_mk.java - src/jdk.localedata/share/classes/sun/text/resources/mk/FormatData_mk.java - src/jdk.localedata/share/classes/sun/text/resources/mk/JavaTimeSupplementary_mk.java - src/jdk.localedata/share/classes/sun/text/resources/mk/MK/FormatData_mk_MK.java - src/jdk.localedata/share/classes/sun/text/resources/ms/FormatData_ms.java - src/jdk.localedata/share/classes/sun/text/resources/ms/JavaTimeSupplementary_ms.java - src/jdk.localedata/share/classes/sun/text/resources/ms/MY/FormatData_ms_MY.java - src/jdk.localedata/share/classes/sun/text/resources/mt/FormatData_mt.java - src/jdk.localedata/share/classes/sun/text/resources/mt/JavaTimeSupplementary_mt.java - src/jdk.localedata/share/classes/sun/text/resources/mt/MT/FormatData_mt_MT.java - src/jdk.localedata/share/classes/sun/text/resources/nl/BE/FormatData_nl_BE.java - src/jdk.localedata/share/classes/sun/text/resources/nl/BE/JavaTimeSupplementary_nl_BE.java - src/jdk.localedata/share/classes/sun/text/resources/nl/FormatData_nl.java - src/jdk.localedata/share/classes/sun/text/resources/nl/JavaTimeSupplementary_nl.java - src/jdk.localedata/share/classes/sun/text/resources/nl/NL/FormatData_nl_NL.java - src/jdk.localedata/share/classes/sun/text/resources/no/CollationData_no.java - src/jdk.localedata/share/classes/sun/text/resources/no/FormatData_no.java - src/jdk.localedata/share/classes/sun/text/resources/no/JavaTimeSupplementary_no.java - src/jdk.localedata/share/classes/sun/text/resources/no/NO/FormatData_no_NO.java - src/jdk.localedata/share/classes/sun/text/resources/no/NO/FormatData_no_NO_NY.java - src/jdk.localedata/share/classes/sun/text/resources/pl/CollationData_pl.java - src/jdk.localedata/share/classes/sun/text/resources/pl/FormatData_pl.java - src/jdk.localedata/share/classes/sun/text/resources/pl/JavaTimeSupplementary_pl.java - src/jdk.localedata/share/classes/sun/text/resources/pl/PL/FormatData_pl_PL.java - src/jdk.localedata/share/classes/sun/text/resources/pt/BR/FormatData_pt_BR.java - src/jdk.localedata/share/classes/sun/text/resources/pt/FormatData_pt.java - src/jdk.localedata/share/classes/sun/text/resources/pt/JavaTimeSupplementary_pt.java - src/jdk.localedata/share/classes/sun/text/resources/pt/PT/FormatData_pt_PT.java - src/jdk.localedata/share/classes/sun/text/resources/pt/PT/JavaTimeSupplementary_pt_PT.java - src/jdk.localedata/share/classes/sun/text/resources/ro/CollationData_ro.java - src/jdk.localedata/share/classes/sun/text/resources/ro/FormatData_ro.java - src/jdk.localedata/share/classes/sun/text/resources/ro/JavaTimeSupplementary_ro.java - src/jdk.localedata/share/classes/sun/text/resources/ro/RO/FormatData_ro_RO.java - src/jdk.localedata/share/classes/sun/text/resources/ru/CollationData_ru.java - src/jdk.localedata/share/classes/sun/text/resources/ru/FormatData_ru.java - src/jdk.localedata/share/classes/sun/text/resources/ru/JavaTimeSupplementary_ru.java - src/jdk.localedata/share/classes/sun/text/resources/ru/RU/FormatData_ru_RU.java - src/jdk.localedata/share/classes/sun/text/resources/sk/CollationData_sk.java - src/jdk.localedata/share/classes/sun/text/resources/sk/FormatData_sk.java - src/jdk.localedata/share/classes/sun/text/resources/sk/JavaTimeSupplementary_sk.java - src/jdk.localedata/share/classes/sun/text/resources/sk/SK/FormatData_sk_SK.java - src/jdk.localedata/share/classes/sun/text/resources/sl/CollationData_sl.java - src/jdk.localedata/share/classes/sun/text/resources/sl/FormatData_sl.java - src/jdk.localedata/share/classes/sun/text/resources/sl/JavaTimeSupplementary_sl.java - src/jdk.localedata/share/classes/sun/text/resources/sl/SI/FormatData_sl_SI.java - src/jdk.localedata/share/classes/sun/text/resources/sq/AL/FormatData_sq_AL.java - src/jdk.localedata/share/classes/sun/text/resources/sq/CollationData_sq.java - src/jdk.localedata/share/classes/sun/text/resources/sq/FormatData_sq.java - src/jdk.localedata/share/classes/sun/text/resources/sq/JavaTimeSupplementary_sq.java - src/jdk.localedata/share/classes/sun/text/resources/sr/BA/FormatData_sr_BA.java - src/jdk.localedata/share/classes/sun/text/resources/sr/CS/FormatData_sr_CS.java - src/jdk.localedata/share/classes/sun/text/resources/sr/CollationData_sr.java - src/jdk.localedata/share/classes/sun/text/resources/sr/CollationData_sr_Latn.java - src/jdk.localedata/share/classes/sun/text/resources/sr/FormatData_sr.java - src/jdk.localedata/share/classes/sun/text/resources/sr/FormatData_sr_Latn.java - src/jdk.localedata/share/classes/sun/text/resources/sr/JavaTimeSupplementary_sr.java - src/jdk.localedata/share/classes/sun/text/resources/sr/JavaTimeSupplementary_sr_Latn.java - src/jdk.localedata/share/classes/sun/text/resources/sr/ME/FormatData_sr_Latn_ME.java - src/jdk.localedata/share/classes/sun/text/resources/sr/ME/FormatData_sr_ME.java - src/jdk.localedata/share/classes/sun/text/resources/sr/RS/FormatData_sr_RS.java - src/jdk.localedata/share/classes/sun/text/resources/sv/CollationData_sv.java - src/jdk.localedata/share/classes/sun/text/resources/sv/FormatData_sv.java - src/jdk.localedata/share/classes/sun/text/resources/sv/JavaTimeSupplementary_sv.java - src/jdk.localedata/share/classes/sun/text/resources/sv/SE/FormatData_sv_SE.java - src/jdk.localedata/share/classes/sun/text/resources/th/BreakIteratorInfo_th.java - src/jdk.localedata/share/classes/sun/text/resources/th/BreakIteratorRules_th.java - src/jdk.localedata/share/classes/sun/text/resources/th/CollationData_th.java - src/jdk.localedata/share/classes/sun/text/resources/th/FormatData_th.java - src/jdk.localedata/share/classes/sun/text/resources/th/JavaTimeSupplementary_th.java - src/jdk.localedata/share/classes/sun/text/resources/th/TH/FormatData_th_TH.java - src/jdk.localedata/share/classes/sun/text/resources/th/thai_dict - src/jdk.localedata/share/classes/sun/text/resources/tr/CollationData_tr.java - src/jdk.localedata/share/classes/sun/text/resources/tr/FormatData_tr.java - src/jdk.localedata/share/classes/sun/text/resources/tr/JavaTimeSupplementary_tr.java - src/jdk.localedata/share/classes/sun/text/resources/tr/TR/FormatData_tr_TR.java - src/jdk.localedata/share/classes/sun/text/resources/uk/CollationData_uk.java - src/jdk.localedata/share/classes/sun/text/resources/uk/FormatData_uk.java - src/jdk.localedata/share/classes/sun/text/resources/uk/JavaTimeSupplementary_uk.java - src/jdk.localedata/share/classes/sun/text/resources/uk/UA/FormatData_uk_UA.java - src/jdk.localedata/share/classes/sun/text/resources/vi/CollationData_vi.java - src/jdk.localedata/share/classes/sun/text/resources/vi/FormatData_vi.java - src/jdk.localedata/share/classes/sun/text/resources/vi/JavaTimeSupplementary_vi.java - src/jdk.localedata/share/classes/sun/text/resources/vi/VN/FormatData_vi_VN.java - src/jdk.localedata/share/classes/sun/text/resources/zh/CN/FormatData_zh_CN.java - src/jdk.localedata/share/classes/sun/text/resources/zh/CollationData_zh.java - src/jdk.localedata/share/classes/sun/text/resources/zh/FormatData_zh.java - src/jdk.localedata/share/classes/sun/text/resources/zh/HK/CollationData_zh_HK.java - src/jdk.localedata/share/classes/sun/text/resources/zh/HK/FormatData_zh_HK.java - src/jdk.localedata/share/classes/sun/text/resources/zh/JavaTimeSupplementary_zh.java - src/jdk.localedata/share/classes/sun/text/resources/zh/SG/FormatData_zh_SG.java - src/jdk.localedata/share/classes/sun/text/resources/zh/TW/CollationData_zh_TW.java - src/jdk.localedata/share/classes/sun/text/resources/zh/TW/FormatData_zh_TW.java - src/jdk.localedata/share/classes/sun/text/resources/zh/TW/JavaTimeSupplementary_zh_TW.java - src/jdk.localedata/share/classes/sun/util/resources/ar/AE/CurrencyNames_ar_AE.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/BH/CurrencyNames_ar_BH.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/CalendarData_ar.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/DZ/CurrencyNames_ar_DZ.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/EG/CurrencyNames_ar_EG.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/IQ/CurrencyNames_ar_IQ.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/JO/CurrencyNames_ar_JO.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/KW/CurrencyNames_ar_KW.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/LB/CurrencyNames_ar_LB.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/LY/CurrencyNames_ar_LY.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/LocaleNames_ar.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/MA/CurrencyNames_ar_MA.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/OM/CurrencyNames_ar_OM.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/QA/CurrencyNames_ar_QA.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/SA/CurrencyNames_ar_SA.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/SD/CurrencyNames_ar_SD.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/SY/CurrencyNames_ar_SY.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/TN/CurrencyNames_ar_TN.properties - src/jdk.localedata/share/classes/sun/util/resources/ar/YE/CurrencyNames_ar_YE.properties - src/jdk.localedata/share/classes/sun/util/resources/be/BY/CurrencyNames_be_BY.properties - src/jdk.localedata/share/classes/sun/util/resources/be/CalendarData_be.properties - src/jdk.localedata/share/classes/sun/util/resources/be/LocaleNames_be.properties - src/jdk.localedata/share/classes/sun/util/resources/bg/BG/CurrencyNames_bg_BG.properties - src/jdk.localedata/share/classes/sun/util/resources/bg/CalendarData_bg.properties - src/jdk.localedata/share/classes/sun/util/resources/bg/LocaleNames_bg.properties - src/jdk.localedata/share/classes/sun/util/resources/ca/CalendarData_ca.properties - src/jdk.localedata/share/classes/sun/util/resources/ca/ES/CurrencyNames_ca_ES.properties - src/jdk.localedata/share/classes/sun/util/resources/ca/LocaleNames_ca.properties - src/jdk.localedata/share/classes/sun/util/resources/cs/CZ/CurrencyNames_cs_CZ.properties - src/jdk.localedata/share/classes/sun/util/resources/cs/CalendarData_cs.properties - src/jdk.localedata/share/classes/sun/util/resources/cs/LocaleNames_cs.properties - src/jdk.localedata/share/classes/sun/util/resources/da/CalendarData_da.properties - src/jdk.localedata/share/classes/sun/util/resources/da/DK/CurrencyNames_da_DK.properties - src/jdk.localedata/share/classes/sun/util/resources/da/LocaleNames_da.properties - src/jdk.localedata/share/classes/sun/util/resources/de/AT/CurrencyNames_de_AT.properties - src/jdk.localedata/share/classes/sun/util/resources/de/CH/CurrencyNames_de_CH.properties - src/jdk.localedata/share/classes/sun/util/resources/de/CalendarData_de.properties - src/jdk.localedata/share/classes/sun/util/resources/de/CurrencyNames_de.properties - src/jdk.localedata/share/classes/sun/util/resources/de/DE/CurrencyNames_de_DE.properties - src/jdk.localedata/share/classes/sun/util/resources/de/GR/CurrencyNames_de_GR.properties - src/jdk.localedata/share/classes/sun/util/resources/de/LU/CurrencyNames_de_LU.properties - src/jdk.localedata/share/classes/sun/util/resources/de/LocaleNames_de.properties - src/jdk.localedata/share/classes/sun/util/resources/de/TimeZoneNames_de.java - src/jdk.localedata/share/classes/sun/util/resources/el/CY/CalendarData_el_CY.properties - src/jdk.localedata/share/classes/sun/util/resources/el/CY/CurrencyNames_el_CY.properties - src/jdk.localedata/share/classes/sun/util/resources/el/CY/LocaleNames_el_CY.properties - src/jdk.localedata/share/classes/sun/util/resources/el/CalendarData_el.properties - src/jdk.localedata/share/classes/sun/util/resources/el/GR/CurrencyNames_el_GR.properties - src/jdk.localedata/share/classes/sun/util/resources/el/LocaleNames_el.properties - src/jdk.localedata/share/classes/sun/util/resources/en/AU/CurrencyNames_en_AU.properties - src/jdk.localedata/share/classes/sun/util/resources/en/CA/CurrencyNames_en_CA.properties - src/jdk.localedata/share/classes/sun/util/resources/en/CA/TimeZoneNames_en_CA.java - src/jdk.localedata/share/classes/sun/util/resources/en/GB/CalendarData_en_GB.properties - src/jdk.localedata/share/classes/sun/util/resources/en/GB/CurrencyNames_en_GB.properties - src/jdk.localedata/share/classes/sun/util/resources/en/GB/TimeZoneNames_en_GB.java - src/jdk.localedata/share/classes/sun/util/resources/en/IE/CalendarData_en_IE.properties - src/jdk.localedata/share/classes/sun/util/resources/en/IE/CurrencyNames_en_IE.properties - src/jdk.localedata/share/classes/sun/util/resources/en/IE/TimeZoneNames_en_IE.java - src/jdk.localedata/share/classes/sun/util/resources/en/IN/CurrencyNames_en_IN.properties - src/jdk.localedata/share/classes/sun/util/resources/en/MT/CalendarData_en_MT.properties - src/jdk.localedata/share/classes/sun/util/resources/en/MT/CurrencyNames_en_MT.properties - src/jdk.localedata/share/classes/sun/util/resources/en/MT/LocaleNames_en_MT.properties - src/jdk.localedata/share/classes/sun/util/resources/en/NZ/CurrencyNames_en_NZ.properties - src/jdk.localedata/share/classes/sun/util/resources/en/PH/CurrencyNames_en_PH.properties - src/jdk.localedata/share/classes/sun/util/resources/en/PH/LocaleNames_en_PH.properties - src/jdk.localedata/share/classes/sun/util/resources/en/SG/CurrencyNames_en_SG.properties - src/jdk.localedata/share/classes/sun/util/resources/en/SG/LocaleNames_en_SG.properties - src/jdk.localedata/share/classes/sun/util/resources/en/ZA/CurrencyNames_en_ZA.properties - src/jdk.localedata/share/classes/sun/util/resources/es/AR/CurrencyNames_es_AR.properties - src/jdk.localedata/share/classes/sun/util/resources/es/BO/CurrencyNames_es_BO.properties - src/jdk.localedata/share/classes/sun/util/resources/es/CL/CurrencyNames_es_CL.properties - src/jdk.localedata/share/classes/sun/util/resources/es/CO/CurrencyNames_es_CO.properties - src/jdk.localedata/share/classes/sun/util/resources/es/CR/CurrencyNames_es_CR.properties - src/jdk.localedata/share/classes/sun/util/resources/es/CU/CurrencyNames_es_CU.properties - src/jdk.localedata/share/classes/sun/util/resources/es/CalendarData_es.properties - src/jdk.localedata/share/classes/sun/util/resources/es/CurrencyNames_es.properties - src/jdk.localedata/share/classes/sun/util/resources/es/DO/CurrencyNames_es_DO.properties - src/jdk.localedata/share/classes/sun/util/resources/es/EC/CurrencyNames_es_EC.properties - src/jdk.localedata/share/classes/sun/util/resources/es/ES/CalendarData_es_ES.properties - src/jdk.localedata/share/classes/sun/util/resources/es/ES/CurrencyNames_es_ES.properties - src/jdk.localedata/share/classes/sun/util/resources/es/GT/CurrencyNames_es_GT.properties - src/jdk.localedata/share/classes/sun/util/resources/es/HN/CurrencyNames_es_HN.properties - src/jdk.localedata/share/classes/sun/util/resources/es/LocaleNames_es.properties - src/jdk.localedata/share/classes/sun/util/resources/es/MX/CurrencyNames_es_MX.properties - src/jdk.localedata/share/classes/sun/util/resources/es/NI/CurrencyNames_es_NI.properties - src/jdk.localedata/share/classes/sun/util/resources/es/PA/CurrencyNames_es_PA.properties - src/jdk.localedata/share/classes/sun/util/resources/es/PE/CurrencyNames_es_PE.properties - src/jdk.localedata/share/classes/sun/util/resources/es/PR/CurrencyNames_es_PR.properties - src/jdk.localedata/share/classes/sun/util/resources/es/PY/CurrencyNames_es_PY.properties - src/jdk.localedata/share/classes/sun/util/resources/es/SV/CurrencyNames_es_SV.properties - src/jdk.localedata/share/classes/sun/util/resources/es/TimeZoneNames_es.java - src/jdk.localedata/share/classes/sun/util/resources/es/US/CalendarData_es_US.properties - src/jdk.localedata/share/classes/sun/util/resources/es/US/CurrencyNames_es_US.properties - src/jdk.localedata/share/classes/sun/util/resources/es/US/LocaleNames_es_US.properties - src/jdk.localedata/share/classes/sun/util/resources/es/UY/CurrencyNames_es_UY.properties - src/jdk.localedata/share/classes/sun/util/resources/es/VE/CurrencyNames_es_VE.properties - src/jdk.localedata/share/classes/sun/util/resources/et/CalendarData_et.properties - src/jdk.localedata/share/classes/sun/util/resources/et/EE/CurrencyNames_et_EE.properties - src/jdk.localedata/share/classes/sun/util/resources/et/LocaleNames_et.properties - src/jdk.localedata/share/classes/sun/util/resources/fi/CalendarData_fi.properties - src/jdk.localedata/share/classes/sun/util/resources/fi/FI/CurrencyNames_fi_FI.properties - src/jdk.localedata/share/classes/sun/util/resources/fi/LocaleNames_fi.properties - src/jdk.localedata/share/classes/sun/util/resources/fr/BE/CurrencyNames_fr_BE.properties - src/jdk.localedata/share/classes/sun/util/resources/fr/CA/CalendarData_fr_CA.properties - src/jdk.localedata/share/classes/sun/util/resources/fr/CA/CurrencyNames_fr_CA.properties - src/jdk.localedata/share/classes/sun/util/resources/fr/CH/CurrencyNames_fr_CH.properties - src/jdk.localedata/share/classes/sun/util/resources/fr/CalendarData_fr.properties - src/jdk.localedata/share/classes/sun/util/resources/fr/CurrencyNames_fr.properties - src/jdk.localedata/share/classes/sun/util/resources/fr/FR/CurrencyNames_fr_FR.properties - src/jdk.localedata/share/classes/sun/util/resources/fr/LU/CurrencyNames_fr_LU.properties - src/jdk.localedata/share/classes/sun/util/resources/fr/LocaleNames_fr.properties - src/jdk.localedata/share/classes/sun/util/resources/fr/TimeZoneNames_fr.java - src/jdk.localedata/share/classes/sun/util/resources/ga/IE/CurrencyNames_ga_IE.properties - src/jdk.localedata/share/classes/sun/util/resources/ga/LocaleNames_ga.properties - src/jdk.localedata/share/classes/sun/util/resources/hi/CalendarData_hi.properties - src/jdk.localedata/share/classes/sun/util/resources/hi/IN/CurrencyNames_hi_IN.properties - src/jdk.localedata/share/classes/sun/util/resources/hi/LocaleNames_hi.properties - src/jdk.localedata/share/classes/sun/util/resources/hi/TimeZoneNames_hi.java - src/jdk.localedata/share/classes/sun/util/resources/hr/CalendarData_hr.properties - src/jdk.localedata/share/classes/sun/util/resources/hr/HR/CurrencyNames_hr_HR.properties - src/jdk.localedata/share/classes/sun/util/resources/hr/LocaleNames_hr.properties - src/jdk.localedata/share/classes/sun/util/resources/hu/CalendarData_hu.properties - src/jdk.localedata/share/classes/sun/util/resources/hu/HU/CurrencyNames_hu_HU.properties - src/jdk.localedata/share/classes/sun/util/resources/hu/LocaleNames_hu.properties - src/jdk.localedata/share/classes/sun/util/resources/in/ID/CalendarData_in_ID.properties - src/jdk.localedata/share/classes/sun/util/resources/in/ID/CurrencyNames_in_ID.properties - src/jdk.localedata/share/classes/sun/util/resources/in/LocaleNames_in.properties - src/jdk.localedata/share/classes/sun/util/resources/is/CalendarData_is.properties - src/jdk.localedata/share/classes/sun/util/resources/is/IS/CurrencyNames_is_IS.properties - src/jdk.localedata/share/classes/sun/util/resources/is/LocaleNames_is.properties - src/jdk.localedata/share/classes/sun/util/resources/it/CH/CurrencyNames_it_CH.properties - src/jdk.localedata/share/classes/sun/util/resources/it/CalendarData_it.properties - src/jdk.localedata/share/classes/sun/util/resources/it/CurrencyNames_it.properties - src/jdk.localedata/share/classes/sun/util/resources/it/IT/CurrencyNames_it_IT.properties - src/jdk.localedata/share/classes/sun/util/resources/it/LocaleNames_it.properties - src/jdk.localedata/share/classes/sun/util/resources/it/TimeZoneNames_it.java - src/jdk.localedata/share/classes/sun/util/resources/iw/CalendarData_iw.properties - src/jdk.localedata/share/classes/sun/util/resources/iw/IL/CurrencyNames_iw_IL.properties - src/jdk.localedata/share/classes/sun/util/resources/iw/LocaleNames_iw.properties - src/jdk.localedata/share/classes/sun/util/resources/ja/CalendarData_ja.properties - src/jdk.localedata/share/classes/sun/util/resources/ja/CurrencyNames_ja.properties - src/jdk.localedata/share/classes/sun/util/resources/ja/JP/CurrencyNames_ja_JP.properties - src/jdk.localedata/share/classes/sun/util/resources/ja/LocaleNames_ja.properties - src/jdk.localedata/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java - src/jdk.localedata/share/classes/sun/util/resources/ko/CalendarData_ko.properties - src/jdk.localedata/share/classes/sun/util/resources/ko/CurrencyNames_ko.properties - src/jdk.localedata/share/classes/sun/util/resources/ko/KR/CurrencyNames_ko_KR.properties - src/jdk.localedata/share/classes/sun/util/resources/ko/LocaleNames_ko.properties - src/jdk.localedata/share/classes/sun/util/resources/ko/TimeZoneNames_ko.java - src/jdk.localedata/share/classes/sun/util/resources/lt/CalendarData_lt.properties - src/jdk.localedata/share/classes/sun/util/resources/lt/LT/CurrencyNames_lt_LT.properties - src/jdk.localedata/share/classes/sun/util/resources/lt/LocaleNames_lt.properties - src/jdk.localedata/share/classes/sun/util/resources/lv/CalendarData_lv.properties - src/jdk.localedata/share/classes/sun/util/resources/lv/LV/CurrencyNames_lv_LV.properties - src/jdk.localedata/share/classes/sun/util/resources/lv/LocaleNames_lv.properties - src/jdk.localedata/share/classes/sun/util/resources/mk/CalendarData_mk.properties - src/jdk.localedata/share/classes/sun/util/resources/mk/LocaleNames_mk.properties - src/jdk.localedata/share/classes/sun/util/resources/mk/MK/CurrencyNames_mk_MK.properties - src/jdk.localedata/share/classes/sun/util/resources/ms/LocaleNames_ms.properties - src/jdk.localedata/share/classes/sun/util/resources/ms/MY/CalendarData_ms_MY.properties - src/jdk.localedata/share/classes/sun/util/resources/ms/MY/CurrencyNames_ms_MY.properties - src/jdk.localedata/share/classes/sun/util/resources/mt/CalendarData_mt.properties - src/jdk.localedata/share/classes/sun/util/resources/mt/LocaleNames_mt.properties - src/jdk.localedata/share/classes/sun/util/resources/mt/MT/CalendarData_mt_MT.properties - src/jdk.localedata/share/classes/sun/util/resources/mt/MT/CurrencyNames_mt_MT.properties - src/jdk.localedata/share/classes/sun/util/resources/nl/BE/CurrencyNames_nl_BE.properties - src/jdk.localedata/share/classes/sun/util/resources/nl/CalendarData_nl.properties - src/jdk.localedata/share/classes/sun/util/resources/nl/LocaleNames_nl.properties - src/jdk.localedata/share/classes/sun/util/resources/nl/NL/CurrencyNames_nl_NL.properties - src/jdk.localedata/share/classes/sun/util/resources/no/CalendarData_no.properties - src/jdk.localedata/share/classes/sun/util/resources/no/LocaleNames_no.properties - src/jdk.localedata/share/classes/sun/util/resources/no/NO/CurrencyNames_no_NO.properties - src/jdk.localedata/share/classes/sun/util/resources/no/NO/LocaleNames_no_NO_NY.properties - src/jdk.localedata/share/classes/sun/util/resources/pl/CalendarData_pl.properties - src/jdk.localedata/share/classes/sun/util/resources/pl/LocaleNames_pl.properties - src/jdk.localedata/share/classes/sun/util/resources/pl/PL/CurrencyNames_pl_PL.properties - src/jdk.localedata/share/classes/sun/util/resources/pt/BR/CalendarData_pt_BR.properties - src/jdk.localedata/share/classes/sun/util/resources/pt/BR/CurrencyNames_pt_BR.properties - src/jdk.localedata/share/classes/sun/util/resources/pt/BR/LocaleNames_pt_BR.properties - src/jdk.localedata/share/classes/sun/util/resources/pt/BR/TimeZoneNames_pt_BR.java - src/jdk.localedata/share/classes/sun/util/resources/pt/CalendarData_pt.properties - src/jdk.localedata/share/classes/sun/util/resources/pt/CurrencyNames_pt.properties - src/jdk.localedata/share/classes/sun/util/resources/pt/LocaleNames_pt.properties - src/jdk.localedata/share/classes/sun/util/resources/pt/PT/CalendarData_pt_PT.properties - src/jdk.localedata/share/classes/sun/util/resources/pt/PT/CurrencyNames_pt_PT.properties - src/jdk.localedata/share/classes/sun/util/resources/pt/PT/LocaleNames_pt_PT.properties - src/jdk.localedata/share/classes/sun/util/resources/ro/CalendarData_ro.properties - src/jdk.localedata/share/classes/sun/util/resources/ro/LocaleNames_ro.properties - src/jdk.localedata/share/classes/sun/util/resources/ro/RO/CurrencyNames_ro_RO.properties - src/jdk.localedata/share/classes/sun/util/resources/ru/CalendarData_ru.properties - src/jdk.localedata/share/classes/sun/util/resources/ru/LocaleNames_ru.properties - src/jdk.localedata/share/classes/sun/util/resources/ru/RU/CurrencyNames_ru_RU.properties - src/jdk.localedata/share/classes/sun/util/resources/sk/CalendarData_sk.properties - src/jdk.localedata/share/classes/sun/util/resources/sk/LocaleNames_sk.properties - src/jdk.localedata/share/classes/sun/util/resources/sk/SK/CurrencyNames_sk_SK.properties - src/jdk.localedata/share/classes/sun/util/resources/sl/CalendarData_sl.properties - src/jdk.localedata/share/classes/sun/util/resources/sl/LocaleNames_sl.properties - src/jdk.localedata/share/classes/sun/util/resources/sl/SI/CurrencyNames_sl_SI.properties - src/jdk.localedata/share/classes/sun/util/resources/sq/AL/CurrencyNames_sq_AL.properties - src/jdk.localedata/share/classes/sun/util/resources/sq/CalendarData_sq.properties - src/jdk.localedata/share/classes/sun/util/resources/sq/LocaleNames_sq.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/BA/CalendarData_sr_Latn_BA.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/BA/CurrencyNames_sr_BA.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/BA/CurrencyNames_sr_Latn_BA.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/CS/CurrencyNames_sr_CS.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/CalendarData_sr.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/LocaleNames_sr.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/LocaleNames_sr_Latn.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/ME/CalendarData_sr_Latn_ME.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/ME/CurrencyNames_sr_Latn_ME.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/ME/CurrencyNames_sr_ME.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/RS/CalendarData_sr_Latn_RS.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/RS/CurrencyNames_sr_Latn_RS.properties - src/jdk.localedata/share/classes/sun/util/resources/sr/RS/CurrencyNames_sr_RS.properties - src/jdk.localedata/share/classes/sun/util/resources/sv/CalendarData_sv.properties - src/jdk.localedata/share/classes/sun/util/resources/sv/CurrencyNames_sv.properties - src/jdk.localedata/share/classes/sun/util/resources/sv/LocaleNames_sv.properties - src/jdk.localedata/share/classes/sun/util/resources/sv/SE/CurrencyNames_sv_SE.properties - src/jdk.localedata/share/classes/sun/util/resources/sv/TimeZoneNames_sv.java - src/jdk.localedata/share/classes/sun/util/resources/th/CalendarData_th.properties - src/jdk.localedata/share/classes/sun/util/resources/th/LocaleNames_th.properties - src/jdk.localedata/share/classes/sun/util/resources/th/TH/CurrencyNames_th_TH.properties - src/jdk.localedata/share/classes/sun/util/resources/tr/CalendarData_tr.properties - src/jdk.localedata/share/classes/sun/util/resources/tr/LocaleNames_tr.properties - src/jdk.localedata/share/classes/sun/util/resources/tr/TR/CurrencyNames_tr_TR.properties - src/jdk.localedata/share/classes/sun/util/resources/uk/CalendarData_uk.properties - src/jdk.localedata/share/classes/sun/util/resources/uk/LocaleNames_uk.properties - src/jdk.localedata/share/classes/sun/util/resources/uk/UA/CurrencyNames_uk_UA.properties - src/jdk.localedata/share/classes/sun/util/resources/vi/CalendarData_vi.properties - src/jdk.localedata/share/classes/sun/util/resources/vi/LocaleNames_vi.properties - src/jdk.localedata/share/classes/sun/util/resources/vi/VN/CurrencyNames_vi_VN.properties - src/jdk.localedata/share/classes/sun/util/resources/zh/CN/CurrencyNames_zh_CN.properties - src/jdk.localedata/share/classes/sun/util/resources/zh/CN/TimeZoneNames_zh_CN.java - src/jdk.localedata/share/classes/sun/util/resources/zh/CalendarData_zh.properties - src/jdk.localedata/share/classes/sun/util/resources/zh/HK/CurrencyNames_zh_HK.java - src/jdk.localedata/share/classes/sun/util/resources/zh/HK/LocaleNames_zh_HK.java - src/jdk.localedata/share/classes/sun/util/resources/zh/HK/TimeZoneNames_zh_HK.java - src/jdk.localedata/share/classes/sun/util/resources/zh/LocaleNames_zh.properties - src/jdk.localedata/share/classes/sun/util/resources/zh/SG/CurrencyNames_zh_SG.java - src/jdk.localedata/share/classes/sun/util/resources/zh/SG/LocaleNames_zh_SG.properties - src/jdk.localedata/share/classes/sun/util/resources/zh/TW/CurrencyNames_zh_TW.properties - src/jdk.localedata/share/classes/sun/util/resources/zh/TW/LocaleNames_zh_TW.properties - src/jdk.localedata/share/classes/sun/util/resources/zh/TW/TimeZoneNames_zh_TW.java Changeset: 4f7f1c6d613d Author: lbourges Date: 2016-02-23 22:07 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4f7f1c6d613d 8148886: SEGV in sun.java2d.marlin.Renderer._endRendering Summary: handle reentrancy in both AAShapePipe and MarlinRenderingEngine using new sun.java2d.ReentrantContextProvider implementations Reviewed-by: flar, prr + src/java.desktop/share/classes/sun/java2d/ReentrantContext.java + src/java.desktop/share/classes/sun/java2d/ReentrantContextProvider.java + src/java.desktop/share/classes/sun/java2d/ReentrantContextProviderCLQ.java + src/java.desktop/share/classes/sun/java2d/ReentrantContextProviderTL.java ! src/java.desktop/share/classes/sun/java2d/marlin/ByteArrayCache.java ! src/java.desktop/share/classes/sun/java2d/marlin/FloatArrayCache.java ! src/java.desktop/share/classes/sun/java2d/marlin/IntArrayCache.java ! src/java.desktop/share/classes/sun/java2d/marlin/MarlinCache.java ! src/java.desktop/share/classes/sun/java2d/marlin/MarlinRenderingEngine.java ! src/java.desktop/share/classes/sun/java2d/marlin/RendererContext.java ! src/java.desktop/share/classes/sun/java2d/marlin/Version.java ! src/java.desktop/share/classes/sun/java2d/pipe/AAShapePipe.java + test/sun/java2d/marlin/CrashPaintTest.java Changeset: eaef70a27f44 Author: ssadetsky Date: 2016-02-24 14:36 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/eaef70a27f44 8081722: Provide public access to sun.awt.shell.ShellFolder methods which are required for implementing javax.swing.JFileChooser Reviewed-by: prr, serb, alexsch ! src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java + test/javax/swing/JFileChooser/ShellFolderQueries/ShellFolderQueriesTest.java Changeset: 31b4663ba8d7 Author: ddehaven Date: 2016-02-24 08:58 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/31b4663ba8d7 Merge - src/java.base/share/native/libjava/Bits.c Changeset: dc4974b4210f Author: psadhukhan Date: 2016-02-25 10:22 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/dc4974b4210f 8020039: SynthTableHeaderUI refers to possibly null parameter in cell renderer Reviewed-by: rchamyal, serb Contributed-by: ajit.ghaisas at oracle.com ! src/java.desktop/macosx/classes/com/apple/laf/AquaTableHeaderUI.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTableHeaderUI.java + test/javax/swing/JTableHeader/8020039/TableHeaderRendererExceptionTest.java Changeset: 6f6e9fc90ba2 Author: serb Date: 2016-02-26 18:51 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6f6e9fc90ba2 8141553: [macosx] JDK fails to build with Xcode 7 on 10.11 Reviewed-by: aniyogi, ddehaven, cbensen ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/LWCToolkit.m ! src/jdk.deploy.osx/macosx/native/libosx/CFileManager.m Changeset: 9e1ed9bb68e0 Author: avstepan Date: 2016-02-26 19:24 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9e1ed9bb68e0 8150643: [TEST] add test for JDK-8150176 Reviewed-by: serb + test/java/awt/image/multiresolution/MultiResolutionTrayIconTest/MultiResolutionTrayIconTest.html + test/java/awt/image/multiresolution/MultiResolutionTrayIconTest/MultiResolutionTrayIconTest.java Changeset: fe7f84c6defd Author: psadhukhan Date: 2016-02-29 14:19 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fe7f84c6defd 7126823: JInternalFrame.getNormalBounds() returns bad value after iconify/deiconify Reviewed-by: ssadetsky, rchamyal Contributed-by: prem.balakrishnan at oracle.com ! src/java.desktop/share/classes/javax/swing/DefaultDesktopManager.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthDesktopPaneUI.java + test/javax/swing/JInternalFrame/NormalBoundsTest.java Changeset: 1aaa07a97e58 Author: ddehaven Date: 2016-02-29 09:00 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1aaa07a97e58 Merge Changeset: 0c9bc87633bc Author: serb Date: 2016-03-02 18:28 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0c9bc87633bc 8147994: [macosx] JScrollPane jitters up/down during trackpad scrolling on MacOS/Aqua Reviewed-by: alexp, aivanov ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollPaneUI.java - test/javax/swing/JScrollPane/8033000/bug8033000.java + test/javax/swing/JScrollPane/HorizontalMouseWheelOnShiftPressed/HorizontalMouseWheelOnShiftPressed.java Changeset: 1b9628b3b8b7 Author: psadhukhan Date: 2016-03-03 12:20 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1b9628b3b8b7 8044788: [D3D] clip is ignored during surface->sw blit Reviewed-by: serb, prr Contributed-by: prasanta.sadhukhan at oracle.com, prahalad.kumar.narayanan at oracle.com ! src/java.desktop/windows/classes/sun/java2d/d3d/D3DBlitLoops.java ! test/java/awt/image/DrawImage/IncorrectClipSurface2SW.java Changeset: eeccc1d42482 Author: psadhukhan Date: 2016-03-03 12:34 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/eeccc1d42482 8138749: Revisited: PrinterJob.printDialog() does not support multi-mon, always displayed on primary Reviewed-by: prr, jdv ! src/java.desktop/share/classes/javax/print/ServiceUI.java ! src/java.desktop/share/classes/sun/print/RasterPrinterJob.java + test/java/awt/print/PrinterJob/MultiMonPrintDlgTest.java Changeset: a35c304a7983 Author: avstepan Date: 2016-03-04 18:42 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a35c304a7983 8150258: [TEST] HiDPI: create a test for multiresolution menu items icons Reviewed-by: serb, yan + test/java/awt/image/multiresolution/MenuMultiresolutionIconTest.java Changeset: a68589dd5181 Author: psadhukhan Date: 2016-03-07 11:54 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a68589dd5181 8058316: lookupDefaultPrintService returns null on Solaris 11 Reviewed-by: prr, jdv ! make/mapfiles/libawt/mapfile-mawt-vers ! make/mapfiles/libawt_headless/mapfile-vers ! make/mapfiles/libawt_xawt/mapfile-vers ! src/java.desktop/unix/classes/sun/print/CUPSPrinter.java ! src/java.desktop/unix/native/common/awt/CUPSfuncs.c Changeset: 07645a6edaf5 Author: ddehaven Date: 2016-03-07 16:38 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/07645a6edaf5 Merge - src/java.base/share/classes/sun/misc/Version.java.template - src/java.base/share/native/libjava/Version.c - test/java/lang/invoke/T8139885.java - test/sun/misc/Version/Version.java Changeset: d90622182bc6 Author: ddehaven Date: 2016-03-11 09:16 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d90622182bc6 Merge ! src/java.desktop/macosx/native/libosx/CFileManager.m - test/javax/swing/JScrollPane/8033000/bug8033000.java Changeset: ff3eb28f63c1 Author: ddehaven Date: 2016-03-11 11:27 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ff3eb28f63c1 Merge Changeset: 9417e1bcded6 Author: bpb Date: 2016-03-11 14:07 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9417e1bcded6 8151691: [Findbugs]jdk.internal.math.FormattedFloatingDecimal.getExponent() may expose internal rep Summary: The reference to the internal array is never leaked via the public API but some internal API clarification is added. Reviewed-by: rriggs ! src/java.base/share/classes/jdk/internal/math/FormattedFloatingDecimal.java Changeset: cca479e15cf6 Author: henryjen Date: 2016-03-14 20:53 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/cca479e15cf6 Merge - make/lib/Lib-jdk.deploy.osx.gmk + make/lib/LibosxLibraries.gmk - make/mapfiles/libjfr/mapfile-vers ! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java ! src/java.base/share/classes/java/nio/charset/Charset.java - src/java.base/share/classes/sun/misc/ASCIICaseInsensitiveComparator.java ! src/java.base/share/native/include/jni.h ! src/java.base/windows/native/libjava/java_props_md.c ! src/jdk.charsets/share/classes/sun/nio/cs/ext/AbstractCharsetProvider.java - src/jdk.deploy.osx/macosx/classes/com/apple/concurrent/Dispatch.java - src/jdk.deploy.osx/macosx/classes/com/apple/concurrent/LibDispatchConcurrentQueue.java - src/jdk.deploy.osx/macosx/classes/com/apple/concurrent/LibDispatchMainQueue.java - src/jdk.deploy.osx/macosx/classes/com/apple/concurrent/LibDispatchNative.java - src/jdk.deploy.osx/macosx/classes/com/apple/concurrent/LibDispatchQueue.java - src/jdk.deploy.osx/macosx/classes/com/apple/concurrent/LibDispatchRetainedResource.java - src/jdk.deploy.osx/macosx/classes/com/apple/concurrent/LibDispatchSerialQueue.java - src/jdk.deploy.osx/macosx/classes/com/apple/concurrent/package.html - src/jdk.deploy.osx/macosx/native/libosx/CFileManager.m - src/jdk.deploy.osx/macosx/native/libosx/Dispatch.m ! test/ProblemList.txt ! test/java/lang/instrument/NativeMethodPrefixAgent.java - test/javax/swing/JScrollPane/8033000/bug8033000.java ! test/sample/chatserver/ChatTest.java ! test/sample/mergesort/MergeSortTest.java Changeset: 7d56aa9d7e32 Author: henryjen Date: 2016-03-14 22:12 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7d56aa9d7e32 Merge - src/java.base/share/classes/jdk/internal/jimage/ImageLocationBase.java - src/java.base/share/classes/jdk/internal/jimage/ImageModuleData.java - src/java.base/share/classes/jdk/internal/module/ModuleLoaderMap.dat From mandy.chung at oracle.com Tue Mar 15 06:28:16 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 15 Mar 2016 06:28:16 +0000 Subject: hg: jigsaw/jake/langtools: 12 new changesets Message-ID: <201603150628.u2F6SGxj022654@aojmv0008.oracle.com> Changeset: 01fdf839bbe6 Author: vromero Date: 2016-03-07 13:45 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/01fdf839bbe6 8139474: -release 7 -verbose causes Javac exception Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/ClassFinder.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/RelativePath.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java + test/tools/javac/T8139474/DashRelease7DashVerboseTest.java Changeset: a61a3c4a3cb3 Author: bchristi Date: 2016-03-08 11:37 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/a61a3c4a3cb3 8148187: Remove OS X-specific com.apple.concurrent package Summary: Removed jdk.deploy.osx module (including com.apple.concurrent) Reviewed-by: alanb, erikj, mchung ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/ct.properties ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Profile.java Changeset: 08b48678df34 Author: rfield Date: 2016-03-08 11:53 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/08b48678df34 8148316: jshell tool: Configurable output format 8148317: jshell tool: unify commands into /set 8149524: JShell: CompletenessAnalysis fails on class Case, E2 extends Enum, E3 extends Enum> {} Reviewed-by: jlahoda + src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ArgTokenizer.java + src/jdk.jshell/share/classes/jdk/internal/jshell/tool/Feedback.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java ! src/jdk.jshell/share/classes/jdk/jshell/CompletenessAnalyzer.java ! test/jdk/jshell/CommandCompletionTest.java ! test/jdk/jshell/CompletenessTest.java ! test/jdk/jshell/ExternalEditorTest.java ! test/jdk/jshell/ReplToolTesting.java ! test/jdk/jshell/ToolBasicTest.java + test/jdk/jshell/ToolFormatTest.java Changeset: 7a9d55dbfb84 Author: shade Date: 2016-03-09 12:52 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/7a9d55dbfb84 8151223: String concatenation fails with implicit toString() on package-private class Reviewed-by: mcimadamore, forax ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/StringConcat.java + test/tools/javac/StringConcat/access/Holder.java + test/tools/javac/StringConcat/access/PublicClass.java + test/tools/javac/StringConcat/access/PublicInterface.java + test/tools/javac/StringConcat/access/Public_PrivateInterface1.java + test/tools/javac/StringConcat/access/Public_PrivateInterface2.java + test/tools/javac/StringConcat/access/Public_PublicClass.java + test/tools/javac/StringConcat/access/Public_PublicInterface.java + test/tools/javac/StringConcat/access/Test.java Changeset: d04881ed4d86 Author: shade Date: 2016-03-09 18:31 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/d04881ed4d86 8151516: test/tools/javac/TestIndyStringConcat depends on runtime JDK details Reviewed-by: mcimadamore + test/tools/javac/StringConcat/TestIndyStringConcat.java ! test/tools/javac/StringConcat/access/Test.java - test/tools/javac/TestIndyStringConcat.java Changeset: 985695afdd3a Author: simonis Date: 2016-03-10 08:54 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/985695afdd3a 8150632: jdk.jshell.TaskFactory should use jdk.Version to check for java.specification.version Reviewed-by: rfield ! src/jdk.jshell/share/classes/jdk/jshell/TaskFactory.java Changeset: b2a8c7611686 Author: lana Date: 2016-03-10 09:51 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/b2a8c7611686 Merge - test/tools/javac/TestIndyStringConcat.java Changeset: 0356613310dd Author: rfield Date: 2016-03-10 14:47 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/0356613310dd 8080069: JShell: Support for corralled classes Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java + src/jdk.jshell/share/classes/jdk/jshell/Corraller.java ! src/jdk.jshell/share/classes/jdk/jshell/Eval.java ! src/jdk.jshell/share/classes/jdk/jshell/ExecutionControl.java ! src/jdk.jshell/share/classes/jdk/jshell/UnresolvedReferenceException.java ! src/jdk.jshell/share/classes/jdk/jshell/Wrap.java ! test/jdk/jshell/ClassesTest.java ! test/jdk/jshell/DropTest.java ! test/jdk/jshell/KullaTesting.java ! test/jdk/jshell/ReplaceTest.java Changeset: 9c3966e9a7a7 Author: ksrini Date: 2016-02-24 15:31 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/9c3966e9a7a7 8149139: [javadoc] Modify Content to accept CharSequence Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractMemberWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/LinkInfoImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/MethodWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageIndexFrameWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PropertyWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Comment.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/ContentBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/DocType.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlDocument.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlTree.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/RawHtml.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/StringContent.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/Content.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java Changeset: 9b4c916633f8 Author: jlahoda Date: 2016-03-11 13:00 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/9b4c916633f8 8151570: jtreg tests leave tty in bad state Summary: Use unsupported terminal when running tests, to avoid setting tty to a raw mode. Reviewed-by: rfield ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java Changeset: d225438621c6 Author: henryjen Date: 2016-03-14 20:54 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/d225438621c6 Merge ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/ClassFinder.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageIndexFrameWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Profile.java ! src/jdk.jshell/share/classes/jdk/jshell/ExecutionControl.java ! src/jdk.jshell/share/classes/jdk/jshell/TaskFactory.java ! test/jdk/jshell/CommandCompletionTest.java + test/tools/javac/StringConcat/TestIndyStringConcat.java - test/tools/javac/TestIndyStringConcat.java Changeset: f4f3e68cc569 Author: henryjen Date: 2016-03-14 22:12 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/f4f3e68cc569 Merge From mandy.chung at oracle.com Tue Mar 15 06:28:20 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 15 Mar 2016 06:28:20 +0000 Subject: hg: jigsaw/jake/nashorn: 6 new changesets Message-ID: <201603150628.u2F6SKnk022703@aojmv0008.oracle.com> Changeset: f27bb66ac9d3 Author: mhaupt Date: 2016-03-09 13:24 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/f27bb66ac9d3 8151291: $EXEC yields "unknown command" on Cygwin Reviewed-by: jlaskey, hannesw, sdama ! .hgignore ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/Global.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/CommandExecutor.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptingFunctions.java + test/script/nosecurity/JDK-8151291.js Changeset: 11811302fe75 Author: mhaupt Date: 2016-03-09 15:15 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/11811302fe75 8151518: relax test requirements to reduce dependency on directory contents Reviewed-by: hannesw, sundar ! test/script/nosecurity/JDK-8151291.js Changeset: c80b4edebdcb Author: hannesw Date: 2016-03-09 15:45 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/c80b4edebdcb 8151515: $EXEC output is truncated Reviewed-by: sundar, jlaskey ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/CommandExecutor.java Changeset: 71a37d6a6495 Author: lana Date: 2016-03-10 09:49 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/71a37d6a6495 Merge Changeset: 9937077e48f1 Author: sdama Date: 2016-03-11 11:35 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/9937077e48f1 8138906: [TEST_BUG] Test test/script/trusted/JDK-8087292.js intermittently fails. Reviewed-by: hannesw, mhaupt ! test/script/trusted/JDK-8087292.js + test/script/trusted/JDK-util.js Changeset: b385ca819557 Author: henryjen Date: 2016-03-14 20:54 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/b385ca819557 Merge ! .hgignore From sundararajan.athijegannathan at oracle.com Tue Mar 15 07:08:31 2016 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Tue, 15 Mar 2016 07:08:31 +0000 Subject: hg: jigsaw/jake/nashorn: -Xpatch and -Xbootclasspath/p: needed to use ASM built from the jdk repo rather than the ASM from underlying JDK Message-ID: <201603150708.u2F78VZQ005595@aojmv0008.oracle.com> Changeset: 0d054fe07293 Author: sundar Date: 2016-03-15 12:38 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/0d054fe07293 -Xpatch and -Xbootclasspath/p: needed to use ASM built from the jdk repo rather than the ASM from underlying JDK ! make/BuildNashorn.gmk From mandy.chung at oracle.com Tue Mar 15 07:58:26 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 15 Mar 2016 07:58:26 +0000 Subject: hg: jigsaw/jake/jaxp: jaxp unittest tests need @modules new internal API Message-ID: <201603150758.u2F7wQpH021736@aojmv0008.oracle.com> Changeset: 8748c27f511b Author: mchung Date: 2016-03-15 00:52 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/8748c27f511b jaxp unittest tests need @modules new internal API ! test/javax/xml/jaxp/unittest/TEST.properties From alan.bateman at oracle.com Tue Mar 15 10:48:19 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 15 Mar 2016 10:48:19 +0000 Subject: hg: jigsaw/jake/hotspot: Add implementation file for tracebackend Message-ID: <201603151048.u2FAmJJB018687@aojmv0008.oracle.com> Changeset: 398601df5686 Author: mgronlun Date: 2016-03-15 09:38 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/398601df5686 Add implementation file for tracebackend + src/share/vm/trace/traceBackend.cpp From alan.bateman at oracle.com Tue Mar 15 10:57:46 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 15 Mar 2016 10:57:46 +0000 Subject: hg: jigsaw/jake/jdk: java/net/http/SelectorTest.java failing Message-ID: <201603151057.u2FAvk90022627@aojmv0008.oracle.com> Changeset: 421bd705bf16 Author: alanb Date: 2016-03-15 10:26 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/421bd705bf16 java/net/http/SelectorTest.java failing + test/java/net/httpclient/whitebox/Driver.java - test/java/net/httpclient/whitebox/TEST.properties + test/java/net/httpclient/whitebox/java.httpclient/java/net/http/SelectorTest.java - test/java/net/httpclient/whitebox/java/net/http/SelectorTest.java From vadim.pakhnushev at oracle.com Tue Mar 15 10:58:44 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Tue, 15 Mar 2016 13:58:44 +0300 Subject: [9] Review request for FX Jigsaw changes In-Reply-To: <56E77594.8030401@oracle.com> References: <56E77594.8030401@oracle.com> Message-ID: <56E7EAE4.3010304@oracle.com> Looks good to me. Vadim On 15.03.2016 5:38, Kevin Rushforth wrote: > Please review the webrev for reviewing the jigsaw changes for FX. > > https://bugs.openjdk.java.net/browse/JDK-8092093 > > http://cr.openjdk.java.net/~kcr/8092093/webrev.00/rt/ > http://cr.openjdk.java.net/~kcr/8092093/webrev.00/rt-fxpackager/ > > I have separated out the in-progress changes to modules/fxpackager* > (jdk.packager and jdk.packager.services modules) so they can be > reviewed separately. However, they will be pushed along with the other > changes as a single changeset. > > These changes are planned to be integrated into FX 9 at the same time > as the JDK changes are integrated (probably next week). They will be > synced down to FX 9-dev shortly after that. > > Please note the following: > > * The required boot JDK to build FX after the Jigsaw integration will > be JDK 9 build 109. We are not yet able to build with a Jigsaw-based > JDK 9 as the boot JDK yet, so we will be sticking at JDK 9 build 109 > for a few weeks. > > * gradle 2.11 is required to build using JDK 9 > > * In addition to building JavaFX as modules for use with a > Jigsaw-capable JDK, we still build the "legacy sdk" using the existing > pre-Jigsaw layout, including jfxrt.jar, etc. As such, most developers > during the transition will hopefully not notice too much change. > > * If you do want to run tests using the modules, you will need a > Jigsaw-based JDK with javafx modules included, and point to that with > a JDK9_HOME (likely to be changed to JIGSAW_HOME) env variable. If you > actually want to build the JDK (which you will need to do if any > module dependencies change), we will send out separate instructions. > These will eventually make it onto the OpenJFX Wiki. > > * The fxpackager modules are disabled by default. To enable them, you > need to build a Jigsaw-based JDK *without* the jdk.pacakger* modules > and point to that with a JDK9_HOME (likely to be changed to > JIGSAW_HOME) env variable. Since most developers will not build in > this mode, you need to set 'gradle -PBUILD_FXPACKAGER' to enable > building the packager. > > * I will refresh the webrev tomorrow afternoon, after making a couple > of planned changes and reacting to any feedback, and again on > Wednesday afternoon. > > -- Kevin > From alan.bateman at oracle.com Tue Mar 15 11:15:16 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 15 Mar 2016 11:15:16 +0000 Subject: hg: jigsaw/jake/jdk: Revert ICC_Profile and ServiceDialog, patches from early phases not needed Message-ID: <201603151115.u2FBFGvB028571@aojmv0008.oracle.com> Changeset: a3e1d44fc6ac Author: alanb Date: 2016-03-15 11:14 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a3e1d44fc6ac Revert ICC_Profile and ServiceDialog, patches from early phases not needed ! src/java.desktop/share/classes/java/awt/color/ICC_Profile.java ! src/java.desktop/share/classes/sun/print/ServiceDialog.java ! test/java/awt/patchlib/java.desktop/java/awt/Helper.java From Alan.Bateman at oracle.com Tue Mar 15 11:22:11 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 15 Mar 2016 11:22:11 +0000 Subject: Initial webrev with changes for JDK 9 In-Reply-To: <56E71303.5020009@oracle.com> References: <56E29267.7070501@oracle.com> <56E71303.5020009@oracle.com> Message-ID: <56E7F063.8020403@oracle.com> Thanks again for going through all the changes in this area. I've reverted the changes to java/awt/color/ICC_Profile.java and sun/print/ServiceDialog.java as they changes were clearly left over from early exploration into resource encapsulation. I've decided not to touch com/apple/laf/AquaUtils.java as that is something that should be cleaned up in jdk9/client. The only reason we had to touch this code was because it directly used sun.misc.Launcher, which is now gone. Yuri needs to look at test/java/awt/xembed/server/TesterClient.java as that addExports usage is not right. I hope Yuri can also help on your comment about why skipTestingEmbeddedFrame=true is commented out in test/java/awt/Mixing/AWT_Mixing/OverlappingTestBase.java. test/java/awt/Toolkit/Headless/WrappedToolkitTest/WrappedToolkitTest.sh could do with a clean-up too, I assume the @compile was dropped because the test is invoking javac directly now. -Alan From alan.bateman at oracle.com Tue Mar 15 11:31:16 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 15 Mar 2016 11:31:16 +0000 Subject: hg: jigsaw/jake/langtools: jdk/jshell/ToolFormatTest.java failing Message-ID: <201603151131.u2FBVGAI005346@aojmv0008.oracle.com> Changeset: b50953acc2b9 Author: alanb Date: 2016-03-15 11:30 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/b50953acc2b9 jdk/jshell/ToolFormatTest.java failing ! test/jdk/jshell/ToolFormatTest.java From alan.bateman at oracle.com Tue Mar 15 11:48:05 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 15 Mar 2016 11:48:05 +0000 Subject: hg: jigsaw/jake/jdk: Update com.sun.jdi.ModuleReference to use consistent param name Message-ID: <201603151148.u2FBm5GC011715@aojmv0008.oracle.com> Changeset: 03a2b5f7c9e5 Author: alanb Date: 2016-03-15 11:47 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/03a2b5f7c9e5 Update com.sun.jdi.ModuleReference to use consistent param name ! src/jdk.jdi/share/classes/com/sun/jdi/ModuleReference.java From chris.hegarty at oracle.com Tue Mar 15 12:15:57 2016 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 15 Mar 2016 12:15:57 +0000 Subject: hg: jigsaw/jake/jdk: jartool: code review comments Message-ID: <201603151215.u2FCFvaG022520@aojmv0008.oracle.com> Changeset: 507b98946557 Author: chegar Date: 2016-03-15 12:14 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/507b98946557 jartool: code review comments ! src/jdk.jartool/share/classes/sun/tools/jar/Main.java ! test/tools/jar/modularJar/Basic.java From chris.hegarty at oracle.com Tue Mar 15 12:19:39 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 15 Mar 2016 12:19:39 +0000 Subject: Initial webrev with changes for JDK 9 In-Reply-To: <56E715F2.1010203@oracle.com> References: <56E29267.7070501@oracle.com> <56E71303.5020009@oracle.com> <56E715F2.1010203@oracle.com> Message-ID: <56E7FDDB.1030407@oracle.com> Thank you for the feedback Sherman. On 14/03/16 19:50, Xueming Shen wrote: > jar.Main: comments > > (1) InputstreamSupplier: > since what we really need here is the byte[], maybe just go > straightforward > to use InputStream/Files.(path)readAllBytes() ? That is cleaner. Done. > (2) #273 don't the "moduleInfo" used for consistency check the same one as > the used for updating at #244? can't be shared? Not always, it can be augmented by addExtendedModuleAttributes . > (3) if it was me I would simply have passed the "moduleInfoBytes" around as > a byte[], we might not even need this "InputStreamSupplier" > interface. Similar to 1 above. Done. > (4) printModuleDescriptor: for a "file" jar, it might be much faster to > open the > zip file with a ZipFile, then entry -> input stream. otherwise, > the ZIS might > be very slow if it's a big jar and the descriptor file is at the > end of the file. That is better. Done > (5) hashDependences: > "matcher" can be reused as > Matcher m = dependenciesToHash.matcher(""); > for (...) { > m.reset(...).find() ... > } Thanks, Done. > btw, what's the spec of the "mach" here? a "match()" or a > "find()"? just check. 'find'. You can find the changes here: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/507b98946557 -Chris. From yuri.nesterenko at oracle.com Tue Mar 15 12:52:16 2016 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Tue, 15 Mar 2016 15:52:16 +0300 Subject: Initial webrev with changes for JDK 9 In-Reply-To: <56E7F063.8020403@oracle.com> References: <56E29267.7070501@oracle.com> <56E71303.5020009@oracle.com> <56E7F063.8020403@oracle.com> Message-ID: <56E80580.7090406@oracle.com> On 03/15/2016 02:22 PM, Alan Bateman wrote: [...] > Yuri needs to look at test/java/awt/xembed/server/TesterClient.java as > that addExports usage is not right. I hope Yuri can also help on your ^ this one is historic: it is from immemorial July while the Helper class is dated by December. I could piggyback a change to the new version of my test fix currently on review. > comment about why skipTestingEmbeddedFrame=true is commented out in > test/java/awt/Mixing/AWT_Mixing/OverlappingTestBase.java. Originally, the tests run twice (second time with EmbeddedFrame) and reported "do not skipTestingEmbeddedFrame" in between. Then the Mac port work started, and that second run was skipped for Mac. Then unskipped. > > test/java/awt/Toolkit/Headless/WrappedToolkitTest/WrappedToolkitTest.sh > could do with a clean-up too, I assume the @compile was dropped because > the test is invoking javac directly now. Exactly; it requires now a different set of compile-time flags for every platform which is hard to pass in @compile. I decided not to remove it as a sign "avoid this" for a future reader. But then, what should I clean there? A commented out part? I could also append a change to the outstanding fix. -yan From harold.seigel at oracle.com Tue Mar 15 13:11:03 2016 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Tue, 15 Mar 2016 13:11:03 +0000 Subject: hg: jigsaw/jake/hotspot: Update JNI AddModuleReads() and CanReadModule() to disallow NULL (JDK-8151816) and fix test failures (JDK-8151817) Message-ID: <201603151311.u2FDB3Fm014805@aojmv0008.oracle.com> Changeset: 07df4997bf44 Author: hseigel Date: 2016-03-15 08:41 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/07df4997bf44 Update JNI AddModuleReads() and CanReadModule() to disallow NULL (JDK-8151816) and fix test failures (JDK-8151817) ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jni.h ! test/runtime/modules/AccessCheck/DiffCL_UmodUpkg.java ! test/runtime/modules/AccessCheck/UmodUPkg.java ! test/runtime/modules/AccessCheck/myloaders/MyDiffClassLoader.java ! test/runtime/modules/AccessCheck/myloaders/MySameClassLoader.java - test/runtime/modules/AccessCheck/p3/c3Loose.jcod ! test/runtime/modules/getModuleJNI/GetModule.java From harold.seigel at oracle.com Tue Mar 15 13:12:39 2016 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Tue, 15 Mar 2016 13:12:39 +0000 Subject: hg: jigsaw/jake/jdk: Rename args to match names in JVM. Part of fix for JDK-8151816. Message-ID: <201603151312.u2FDCd44015494@aojmv0008.oracle.com> Changeset: 1e6e0c32f51e Author: hseigel Date: 2016-03-15 08:45 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1e6e0c32f51e Rename args to match names in JVM. Part of fix for JDK-8151816. ! src/java.base/share/native/include/jni.h From peter.levart at gmail.com Tue Mar 15 13:56:29 2016 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 15 Mar 2016 14:56:29 +0100 Subject: Initial webrev with changes for JDK 9 In-Reply-To: <57D437E7-2EC8-45DB-85C0-3ECA3047AA8C@oracle.com> References: <56E29267.7070501@oracle.com> <57D437E7-2EC8-45DB-85C0-3ECA3047AA8C@oracle.com> Message-ID: <56E8148D.4090202@gmail.com> Hi Alan, Paul, Just a comment on comment: wouldn't the variant with a single compute replace a Package with itself on each repeated call? Semantically it is the same, but there is a volatile memory store on the cache-hit involved where in the original variant, it isn't... On 03/11/2016 05:50 PM, Paul Sandoz wrote: > j.l.ClassLoader > ? > > 1777 // define Package object if the named package is not yet defined > 1778 NamedPackage p = packages.computeIfAbsent(name, > 1779 k -> NamedPackage.toPackage(name, m)); > 1780 if (p instanceof Package) > 1781 return (Package)p; > 1782 > 1783 // otherwise, replace the NamedPackage object with Package object > 1784 return (Package)packages.compute(name, this::toPackage); > > You could merge the computeIfAbsent and compute into a single compute call if you so wish. > > return (Package)packages.compute((n, p) -> { > // define Package object if the named package is not yet defined > if (p == null) return NamedPackage.toPackage(name, m); > // otherwise, replace the NamedPackage object with Package object > return (p instanceof Package) ? p : toPackage(n, p); > }); You could pre-screen the .compute with a .get and this would be the more optimal (no locking on cache-hits): NamedPackage p = packages.get(name); if (p instanceof Package) { return (Package) p; } return (Package)packages.compute((n, p) -> { // define Package object if it is not yet defined or replace it if it is a NamedPackage return (p instanceof Package) ? p : NamedPackage.toPackage(n, m); }); See, no private ClassLoader.toPackage(String name, NamedPackage p) needed. If you also care for constant lambda, this could be optimized even further, but for the price of more complex code: NamedPackage p = packages.get(name); if (p instanceof Package) { return (Package) p; } else if (p == null) { Package pkg = NamedPackage.toPackage(name, m); p = packages.putIfAbsent(name, pkg); if (p == null) { return pkg; } } return (Package)packages.compute((n, p) -> { assert p != null; // replace NamedPackage with Package return (p instanceof Package) ? p : NamedPackage.toPackage(p.name(), p.module()); }); Regards, Peter From peter.levart at gmail.com Tue Mar 15 14:11:11 2016 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 15 Mar 2016 15:11:11 +0100 Subject: Initial webrev with changes for JDK 9 In-Reply-To: <56E8148D.4090202@gmail.com> References: <56E29267.7070501@oracle.com> <57D437E7-2EC8-45DB-85C0-3ECA3047AA8C@oracle.com> <56E8148D.4090202@gmail.com> Message-ID: <56E817FF.6000407@gmail.com> Sorry, On 03/15/2016 02:56 PM, Peter Levart wrote: > If you also care for constant lambda, this could be optimized even > further, but for the price of more complex code: > > > NamedPackage p = packages.get(name); > > if (p instanceof Package) { > return (Package) p; > } else if (p == null) { > Package pkg = NamedPackage.toPackage(name, m); > p = packages.putIfAbsent(name, pkg); > if (p == null) { > return pkg; > } > } > > return (Package)packages.compute((n, p) -> { return (Package)packages.compute(name, (n, p) -> { > assert p != null; > // replace NamedPackage with Package > return (p instanceof Package) ? p : > NamedPackage.toPackage(p.name(), p.module()); > }); From sundararajan.athijegannathan at oracle.com Tue Mar 15 14:16:24 2016 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Tue, 15 Mar 2016 14:16:24 +0000 Subject: hg: jigsaw/jake/jdk: Add @implNote warning that jdk.internal.jimage/jrtfs must maintain backwards-compatibility with JDK 8 Message-ID: <201603151416.u2FEGOCL010002@aojmv0008.oracle.com> Changeset: 905d45f82376 Author: sundar Date: 2016-03-15 19:45 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/905d45f82376 Add @implNote warning that jdk.internal.jimage/jrtfs must maintain backwards-compatibility with JDK 8 Reviewed-by: sundar Contributed-by: claes.redestad at oracle.com ! src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java ! src/java.base/share/classes/jdk/internal/jimage/ImageBufferCache.java ! src/java.base/share/classes/jdk/internal/jimage/ImageHeader.java ! src/java.base/share/classes/jdk/internal/jimage/ImageLocation.java ! src/java.base/share/classes/jdk/internal/jimage/ImageReader.java ! src/java.base/share/classes/jdk/internal/jimage/ImageReaderFactory.java ! src/java.base/share/classes/jdk/internal/jimage/ImageStream.java ! src/java.base/share/classes/jdk/internal/jimage/ImageStrings.java ! src/java.base/share/classes/jdk/internal/jimage/ImageStringsReader.java ! src/java.base/share/classes/jdk/internal/jimage/NativeImageBuffer.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/CompressIndexes.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/CompressedResourceHeader.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/Decompressor.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/ResourceDecompressor.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/ResourceDecompressorFactory.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/ResourceDecompressorRepository.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/SignatureParser.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/StringSharingDecompressor.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/StringSharingDecompressorFactory.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/ZipDecompressor.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/ZipDecompressorFactory.java ! src/java.base/share/classes/jdk/internal/jrtfs/AbstractJrtFileAttributes.java ! src/java.base/share/classes/jdk/internal/jrtfs/AbstractJrtFileSystem.java ! src/java.base/share/classes/jdk/internal/jrtfs/AbstractJrtPath.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtDirectoryStream.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtExplodedFileAttributes.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtExplodedFileSystem.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtExplodedPath.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtFileAttributeView.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtFileAttributes.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtFileStore.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtFileSystem.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtFileSystemProvider.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtPath.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtUtils.java ! src/java.base/share/classes/jdk/internal/jrtfs/SystemImages.java ! src/java.base/share/classes/jdk/internal/jrtfs/jrtfsviewer.js ! src/java.base/share/classes/jdk/internal/jrtfs/jrtls.js From jan.lahoda at oracle.com Tue Mar 15 14:25:29 2016 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Tue, 15 Mar 2016 14:25:29 +0000 Subject: hg: jigsaw/jake/langtools: Tweaking comments. Message-ID: <201603151425.u2FEPTpo013648@aojmv0008.oracle.com> Changeset: cc7fca5d54f3 Author: jlahoda Date: 2016-03-15 15:24 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/cc7fca5d54f3 Tweaking comments. ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java From harold.seigel at oracle.com Tue Mar 15 14:31:03 2016 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Tue, 15 Mar 2016 14:31:03 +0000 Subject: hg: jigsaw/jake/hotspot: Partial fix for open build issue. Message-ID: <201603151431.u2FEV3K7016304@aojmv0008.oracle.com> Changeset: 13a7333a92ab Author: hseigel Date: 2016-03-15 10:03 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/13a7333a92ab Partial fix for open build issue. ! src/share/vm/trace/traceTypes.xsl From alan.bateman at oracle.com Tue Mar 15 14:39:58 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 15 Mar 2016 14:39:58 +0000 Subject: hg: jigsaw/jake/jdk: 2 new changesets Message-ID: <201603151439.u2FEdwsQ019796@aojmv0008.oracle.com> Changeset: f8ff31f1b257 Author: alanb Date: 2016-03-15 14:35 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f8ff31f1b257 Missing javadoc for toString/equals/hashCode ! src/java.base/share/classes/java/lang/module/Configuration.java ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java ! src/java.base/share/classes/java/lang/module/ModuleReference.java ! src/java.base/share/classes/java/lang/module/ResolvedModule.java ! src/java.base/share/classes/java/lang/reflect/Module.java Changeset: ae2511546022 Author: alanb Date: 2016-03-15 14:38 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ae2511546022 Constructor specific javadoc showing up in Method and Field ! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java ! src/java.base/share/classes/java/lang/reflect/Constructor.java From lois.foltan at oracle.com Tue Mar 15 14:50:41 2016 From: lois.foltan at oracle.com (lois.foltan at oracle.com) Date: Tue, 15 Mar 2016 14:50:41 +0000 Subject: hg: jigsaw/jake/hotspot: Clean up of InstanceKlass casts within verify_check_access_msg based on code review comment. Message-ID: <201603151450.u2FEofip024171@aojmv0008.oracle.com> Changeset: bc1f549323f8 Author: lfoltan Date: 2016-03-15 10:22 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/bc1f549323f8 Clean up of InstanceKlass casts within verify_check_access_msg based on code review comment. ! src/share/vm/runtime/reflection.cpp From sundararajan.athijegannathan at oracle.com Tue Mar 15 15:17:11 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 15 Mar 2016 20:47:11 +0530 Subject: jlink tool review (Re: Initial webrev with changes for JDK 9) In-Reply-To: <6B75DCA1-60D1-484A-9EEC-BA45F15BF46B@oracle.com> References: <56D84C7D.9020006@oracle.com> <6B75DCA1-60D1-484A-9EEC-BA45F15BF46B@oracle.com> Message-ID: <56E82777.8040508@oracle.com> Hi, Thanks for the review. I've filed a bug to track your suggestions: https://bugs.openjdk.java.net/browse/JDK-8151896 Thanks, -Sundar On 3/14/2016 6:26 PM, Michael Haupt wrote: > Hi again, > > some certain list server doesn't like attachments. ;-) > Find it at http://cr.openjdk.java.net/~mhaupt/jigsaw/ > > Best, > > Michael > >> Am 14.03.2016 um 13:49 schrieb Michael Haupt : >> >> Alan, all, >> >> please find a patch with suggested changes to jlink in the attachment. The patch also contains a file named review-comments.txt, which addresses several topics throughout jlink. I've covered most code; only the jlink.internal package is still missing. I've been able to compile jake with these refactorings applied; I have not yet run all the jlink tests. >> >> Unfortunately, I have to lay down the review work at this time; Sundar is taking over (thanks!!). I'm available for clarification matters. >> >> Best, >> >> Michael > From erik.joelsson at oracle.com Tue Mar 15 15:46:07 2016 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Tue, 15 Mar 2016 15:46:07 +0000 Subject: hg: jigsaw/jake: Changing Jib dependency for jtreg to 4.2 b01 Message-ID: <201603151546.u2FFk7id017184@aojmv0008.oracle.com> Changeset: 65b3f0d0bc2c Author: erikj Date: 2016-03-15 16:45 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/65b3f0d0bc2c Changing Jib dependency for jtreg to 4.2 b01 ! common/conf/jib-profiles.js From alan.bateman at oracle.com Tue Mar 15 16:00:28 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 15 Mar 2016 16:00:28 +0000 Subject: hg: jigsaw/jake/langtools: jdk/jshell/ToolFormatTest.java still failing Message-ID: <201603151600.u2FG0SKf023474@aojmv0008.oracle.com> Changeset: 7b926e339f9d Author: alanb Date: 2016-03-15 16:00 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/7b926e339f9d jdk/jshell/ToolFormatTest.java still failing ! test/jdk/jshell/ToolFormatTest.java From harold.seigel at oracle.com Tue Mar 15 16:05:12 2016 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Tue, 15 Mar 2016 16:05:12 +0000 Subject: hg: jigsaw/jake/hotspot: Fix open build problem. Message-ID: <201603151605.u2FG5CmE025895@aojmv0008.oracle.com> Changeset: 23944543f258 Author: hseigel Date: 2016-03-15 11:37 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/23944543f258 Fix open build problem. ! src/share/vm/trace/traceBackend.cpp From alan.bateman at oracle.com Tue Mar 15 16:19:54 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 15 Mar 2016 16:19:54 +0000 Subject: hg: jigsaw/jake/jdk: Update example in javadoc to make it clearer Message-ID: <201603151619.u2FGJsGp002128@aojmv0008.oracle.com> Changeset: 9c4e80fb153e Author: alanb Date: 2016-03-15 16:19 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9c4e80fb153e Update example in javadoc to make it clearer ! src/java.base/share/classes/java/lang/module/Configuration.java From mandy.chung at oracle.com Tue Mar 15 17:04:10 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 15 Mar 2016 17:04:10 +0000 Subject: hg: jigsaw/jake/jdk: VerifyStackTrace.java test fails with 9-ea version Message-ID: <201603151704.u2FH4Aig022438@aojmv0008.oracle.com> Changeset: 6b54aaa39cd1 Author: mchung Date: 2016-03-15 09:58 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6b54aaa39cd1 VerifyStackTrace.java test fails with 9-ea version ! test/java/lang/StackWalker/VerifyStackTrace.java From harold.seigel at oracle.com Tue Mar 15 17:31:07 2016 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Tue, 15 Mar 2016 17:31:07 +0000 Subject: hg: jigsaw/jake/hotspot: Remove DTRACE from JNI_GetModule(). Message-ID: <201603151731.u2FHV7r8004170@aojmv0008.oracle.com> Changeset: 80cf85f54a3c Author: hseigel Date: 2016-03-15 13:03 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/80cf85f54a3c Remove DTRACE from JNI_GetModule(). ! src/share/vm/prims/jni.cpp From pbenedict at apache.org Tue Mar 15 17:43:29 2016 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 15 Mar 2016 12:43:29 -0500 Subject: Package, import and type declarations are allowed now in module-info.java by spec In-Reply-To: <56E7395A.4000202@oracle.com> References: <56D07F37.1030806@oracle.com> <56D098BB.5070200@oracle.com> <56E021CE.3050801@oracle.com> <56E09D62.3060507@oracle.com> <56E7395A.4000202@oracle.com> Message-ID: On Mon, Mar 14, 2016 at 5:21 PM, Alex Buckley wrote: > The JLS doesn't know what the string "module-info.class" means or what a > "JAR root" is. Of course. Though that wasn't my ultimate point; I was merely illustrating (philosophically) why having "package" in module-info.java is nonsensical syntax. A "package" statement doesn't mean anything useful in the context of specifying module configuration. As far as I am aware, the module syntax is meant to standalone in the file, but please correct me if you have other intentions for the syntax. If you can also declare types, then a "package" statement begins to make more sense -- but it would seem like a clumsy way of doing things, which I wouldn't advocate (or allow syntactically). Cheers, Paul > In 3/14/2016 9:08 AM, Paul Benedict wrote: > >> Alex, you wrote: "The JLS doesn't prevent javac from rejecting a package >> declaration or an import declaration in a file called module-info.java." >> >> It seems that a package declaration, in this context, should be >> prohibited syntax because module-info.class is always in the JAR root >> which has no package. >> >> Cheers, >> Paul >> >> On Wed, Mar 9, 2016 at 4:02 PM, Alex Buckley > > wrote: >> >> The JLS doesn't prevent javac from rejecting a package declaration >> or an import declaration in a file called module-info.java. >> >> In fact, since a package declaration or import declaration must be >> followed by a type declaration, and since a type declaration cannot >> use a hyphen, javac is free to take the optional rule from JLS 7.6 >> -- filename must align with type declaration -- and develop it >> further: rejecting a package declaration or import declaration in >> module-info.java because the filename cannot possibly align with any >> type declaration. >> >> I can't speak to what a particular EA build of javac is doing with a >> particular option. javac options are irrelevant to the JLS. If a >> compiler accepts the Java language circa SE 9, then a module >> declaration is a valid compilation unit. What's the name of the file >> containing such a compilation unit? Anything the compiler likes. >> >> Alex >> >> On 3/9/2016 5:14 AM, Georgiy Rakov wrote: >> >> Hi Alex, >> >> if I understand correctly you mean about following assertions >> from JLS 7.6: >> >> If and only if packages are stored in a file system (?7.2 >> >> < >> http://docs.oracle.com/javase/specs/jls/se8/html/jls-7.html#jls-7.2>), >> the host system may choose to enforce the restriction that >> it is a >> compile-time error if a type is not found in a file under a >> name >> composed of the type name plus an extension (such as >> |.java|or >> |.jav|) if either of the following is true: >> >> * >> >> The type is referred to by code in other compilation >> units of >> the package in which the type is declared. >> >> * >> >> The type is declared |public|(and therefore is >> potentially >> accessible from code in other packages). >> >> Literally these assertion doesn't make presented behavior >> corresponding >> to spec because the declared type is neither public nor being >> referred >> to from other sources being compiled. >> >> Nevertheless following sources doesn't compile either despite >> the fact >> that no types are declared there at all. >> Namely when only package is specified: >> >> mod\module-info.java: >> module mod { >> exports pkg; >> } >> >> mod\pkg\module-info.java: >> package pkg; >> >> then compiling it by following command line with javac from [2]: >> >> javac -modulesourcepath . mod\module-info.java >> mod\pkg\module-info.java >> >> causes following output: >> >> mod\pkg\module-info.java:1: error: expected 'module >> package pkg; >> ^ >> 1 error >> >> When only import statment is specified: >> >> mod\module-info.java: >> module mod { >> exports pkg; >> } >> >> mod\pkg\module-info.java: >> import java.util.List; >> >> then compiling it by following command line with javac from [2]: >> >> javac -modulesourcepath . mod\module-info.java >> mod\pkg\module-info.java >> >> causes following output: >> >> mod\pkg\module-info.java:1: error: expected 'module' >> import java.util.List; >> ^ >> 1 error >> >> Please see minimized test cases attached in tests23.zip. In order >> to >> reproduce, please: >> >> 1. Unzip the attached archive to some dir on Windows machined, say >> directory A; >> 2. Rename A\test2\test_bat to A\test2\test.bat and >> A\test3\test_bat to >> A\test3\test.bat; >> 3. Modify these two test.bat files by changing JDK_HOME variable >> to >> point to your jigsaw JDK 9 installation directory; >> 4. Run test.bat files in turn. >> >> BTW: javac behavior [2] currently differs depending on whether >> sources >> are compiled "in module" mode or not. By "module mode" I mean >> specifying >> modulesourcepath option. For instance without modulesourcepath >> option >> module declarations are not recognized as valid grammar while >> import >> declarations contained within module-info.java compile >> successfully. >> This can be seen by experimenting with test3 from the attached >> testcases. Now javac from [2] even can throw exception in >> "non-module" >> mode, please see https://bugs.openjdk.java.net/browse/JDK-8150733 >> . >> >> Could you please tell if spec will specify somehow two modes of >> processing java-sources, now it [1] doesn't. >> >> [1] http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html >> [2] >> >> http://download.java.net/java/jigsaw/archive/106/binaries/jigsaw-jdk-9-ea+106_windows-x86_bin.zip >> >> Thanks, >> Georgiy. >> >> On 26.02.2016 21:26, Alex Buckley wrote: >> >> On 2/26/2016 8:37 AM, Georgiy Rakov wrote: >> >> current spec [1] now contains following assertions >> related to grammar: >> >> A compilation unit (JLS 7.3) may contain a module >> declaration, in >> which case the filename of the compilation unit is >> typically >> |module-info.java|. >> >> CompilationUnit: >> [PackageDeclaration] {ImportDeclaration} >> {TypeDeclaration} >> ModuleDeclaration >> >> These assertions allows to specify any of import, >> package or type >> declarations in any compilation unit, for instance >> module-info.java is >> allowed to contain any of the mentioned declarations. >> However currently >> javac in the latest jigsaw build [2] reports an error on >> such cases >> provided they are compiled in module mode. For example >> if we have >> following directory structure: >> >> mod\module-info.java: >> module mod { >> exports pkg; >> } >> >> mod\pkg\module-info.java: >> package pkg; >> >> class C { >> } >> >> then compiling it by following command line with javac >> from [2]: >> >> javac -modulesourcepath . mod\module-info.java >> mod\pkg\module-info.java >> >> causes following output: >> >> mod\pkg\module-info.java:1: error: expected 'module' >> package pkg; >> ^ >> 1 error >> >> >> javac is merely choosing to implement the rule at the end of >> JLS 7.6 >> that a type declaration (optionally preceded by package/import >> declarations) must be provided in a suitably named file. >> >> Perhaps I should say "a variant of the rule" because 7.6 as >> written >> concerns a public type and your example has a package-access >> type. >> Still, bottom line, javac is free to require that a >> compilation unit >> which starts with a package declaration _must not_ be in a >> file called >> foo-bar.java -- the hyphen indicates a name that can't >> possibly align >> with the type declared in the compilation unit. >> >> The error message for mod\pkg\module-info.java could be a >> bit more >> helpful, but that's a quality-of-implementation detail. >> >> Conversely, a compilation unit that contains a module >> declaration >> _may_ be in a file called module-info.java, or in a file >> called >> foo-bar.java, or in a file called mod_decl.JAV. The >> "typically" in [1] >> is meant to indicate that the sub-clause on filename is >> non-normative. >> This is akin to how a compilation unit that contains a >> package-access >> type declaration for class C _may_ be in a file D.java. >> >> Alex >> >> >> >> From daniel.fuchs at oracle.com Tue Mar 15 17:48:41 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 15 Mar 2016 18:48:41 +0100 Subject: Initial webrev with changes for JDK 9 In-Reply-To: <56E29267.7070501@oracle.com> References: <56E29267.7070501@oracle.com> Message-ID: <56E84AF9.709@oracle.com> Hi Alan, I had a look at the jdeps changes and they look good. I have a couple of minor comments: http://cr.openjdk.java.net/~alanb/8142968/2/langtools/src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Archive.java.frames.html 120 @Override 121 public int hashCode() { 122 int hash = 7; 123 hash = 67*hash + Objects.hashCode(this.filename) + 124 Objects.hashCode(this.path); 125 return hash; 126 } I wonder if that could be simplified in: return Objects.hash(this.filename, this.path); http://cr.openjdk.java.net/~alanb/8142968/2/langtools/src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsTask.java.frames.html typo: 443 // otherwise analyze the depednencies best regards, -- daniel On 11/03/16 10:39, Alan Bateman wrote: > > I've refreshed the webrevs here: > http://cr.openjdk.java.net/~alanb/8142968/2 > > so that we have a snapshot of what is currently in the jigsaw/jake > forest. The webrevs are against jdk-9+109. > > As I said in the last mail, we would like to integrate this snapshot > into JDK 9 before the end of March. The proposal is to aim to integrate > during the week of March 21, with the the week of March 28 as fallback > in event of problems. > > The related JEPs (JEP 200, JEP 260, JEP 261 and JEP 282) are now in > "Proposed to Target" state. Mark send mail to jdk9-dev with this list > and other proposals yesterday. > > -Alan From alan.bateman at oracle.com Tue Mar 15 18:05:09 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 15 Mar 2016 18:05:09 +0000 Subject: hg: jigsaw/jake/jdk: Move tests out of jdk/jigsaw tree Message-ID: <201603151805.u2FI59h2023156@aojmv0008.oracle.com> Changeset: 8711f9420791 Author: alanb Date: 2016-03-15 18:04 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8711f9420791 Move tests out of jdk/jigsaw tree ! test/ProblemList.jake.txt ! test/TEST.groups ! test/java/lang/Class/forName/modules/TestDriver.java ! test/java/lang/Class/getResource/ResourcesTest.java ! test/java/lang/ClassLoader/getResource/modules/ResourcesTest.java + test/java/lang/invoke/modules/ModuleAccessControlTest.java + test/java/lang/invoke/modules/src/m1/module-info.java + test/java/lang/invoke/modules/src/m1/p1/Main.java + test/java/lang/invoke/modules/src/m1/p1/Type1.java + test/java/lang/invoke/modules/src/m1/p2/Type2.java + test/java/lang/invoke/modules/src/m2/module-info.java + test/java/lang/invoke/modules/src/m2/q1/Type1.java + test/java/lang/invoke/modules/src/m2/q2/Type2.java + test/java/lang/module/AutomaticModulesTest.java + test/java/lang/module/ConfigurationTest.java + test/java/lang/module/ModuleDescriptorTest.java + test/java/lang/module/ModuleFinderTest.java + test/java/lang/module/ModuleReader/ModuleReaderTest.java + test/java/lang/module/ModuleReader/src/m/module-info.java + test/java/lang/module/ModuleReader/src/m/p/Main.java + test/java/lang/module/ModuleReferenceTest.java + test/java/lang/module/VersionTest.java + test/java/lang/reflect/AccessibleObject/ModuleSetAccessibleTest.java + test/java/lang/reflect/Layer/BasicLayerTest.java + test/java/lang/reflect/Layer/LayerAndLoadersTest.java + test/java/lang/reflect/Layer/layertest/Test.java + test/java/lang/reflect/Layer/src/m1/module-info.java + test/java/lang/reflect/Layer/src/m1/p/Main.java + test/java/lang/reflect/Layer/src/m1/p/Service.java + test/java/lang/reflect/Layer/src/m2/module-info.java + test/java/lang/reflect/Layer/src/m2/q/Hello.java + test/java/lang/reflect/Layer/src/m3/module-info.java + test/java/lang/reflect/Layer/src/m3/w/Hello.java + test/java/lang/reflect/Layer/src/m4/impl/ServiceImpl.java + test/java/lang/reflect/Layer/src/m4/module-info.java + test/java/lang/reflect/Module/AddExportsTest.java + test/java/lang/reflect/Module/BasicModuleTest.java + test/java/lang/reflect/Module/access/AccessTest.java + test/java/lang/reflect/Module/access/src/target/module-info.java + test/java/lang/reflect/Module/access/src/target/p/Exported.java + test/java/lang/reflect/Module/access/src/target/p/Helper.java + test/java/lang/reflect/Module/access/src/target/q/Internal.java + test/java/lang/reflect/Module/access/src/test/module-info.java + test/java/lang/reflect/Module/access/src/test/test/Main.java + test/java/lang/reflect/Proxy/ProxyClassAccessTest.java + test/java/lang/reflect/Proxy/ProxyForMethodHandle.java + test/java/lang/reflect/Proxy/ProxyLayerTest.java + test/java/lang/reflect/Proxy/ProxyModuleMapping.java + test/java/lang/reflect/Proxy/ProxyTest.java + test/java/lang/reflect/Proxy/q/NP.java + test/java/lang/reflect/Proxy/q/U.java + test/java/lang/reflect/Proxy/src/m1/module-info.java + test/java/lang/reflect/Proxy/src/m1/p/one/I.java + test/java/lang/reflect/Proxy/src/m1/p/one/internal/J.java + test/java/lang/reflect/Proxy/src/m2/module-info.java + test/java/lang/reflect/Proxy/src/m2/p/two/A.java + test/java/lang/reflect/Proxy/src/m2/p/two/B.java + test/java/lang/reflect/Proxy/src/m2/p/two/Bar.java + test/java/lang/reflect/Proxy/src/m2/p/two/internal/C.java + test/java/lang/reflect/Proxy/src/m3/module-info.java + test/java/lang/reflect/Proxy/src/m3/p/three/P.java + test/java/lang/reflect/Proxy/src/m3/p/three/internal/Q.java + test/java/lang/reflect/Proxy/src/test/jdk/test/Main.java + test/java/lang/reflect/Proxy/src/test/jdk/test/NP.java + test/java/lang/reflect/Proxy/src/test/jdk/test/ProxyClassAccess.java + test/java/lang/reflect/Proxy/src/test/jdk/test/ProxyTest.java + test/java/lang/reflect/Proxy/src/test/jdk/test/internal/R.java + test/java/lang/reflect/Proxy/src/test/jdk/test/internal/RImpl.java + test/java/lang/reflect/Proxy/src/test/jdk/test/internal/foo/Foo.java + test/java/lang/reflect/Proxy/src/test/jdk/test/internal/foo/FooException.java + test/java/lang/reflect/Proxy/src/test/module-info.java ! test/java/security/Provider/SecurityProviderModularTest.java + test/java/util/ServiceLoader/modules/BasicTest.java + test/java/util/ServiceLoader/modules/ServicesTest.java + test/java/util/ServiceLoader/modules/src/bananascript/module-info.java + test/java/util/ServiceLoader/modules/src/bananascript/org/banana/BananaScript.java + test/java/util/ServiceLoader/modules/src/bananascript/org/banana/BananaScriptEngineFactory.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/src/test/module-info.java + test/java/util/ServiceLoader/modules/src/test/test/Main.java ! test/java/util/logging/modules/GetResourceBundleTest.java ! test/javax/security/auth/login/modules/JaasModularClientTest.java - test/jdk/jigsaw/etc/JdkModules.java - test/jdk/jigsaw/invoke/access/ModuleAccessControlTest.java - test/jdk/jigsaw/invoke/access/src/m1/module-info.java - test/jdk/jigsaw/invoke/access/src/m1/p1/Main.java - test/jdk/jigsaw/invoke/access/src/m1/p1/Type1.java - test/jdk/jigsaw/invoke/access/src/m1/p2/Type2.java - test/jdk/jigsaw/invoke/access/src/m2/module-info.java - test/jdk/jigsaw/invoke/access/src/m2/q1/Type1.java - test/jdk/jigsaw/invoke/access/src/m2/q2/Type2.java - test/jdk/jigsaw/launcher/addexports/AddExportsTest.java - test/jdk/jigsaw/launcher/addexports/src/java.transaction/javax/transaction/Transaction.java - test/jdk/jigsaw/launcher/addexports/src/java.transaction/javax/transaction/internal/Helper.java - test/jdk/jigsaw/launcher/addexports/src/java.transaction/module-info.java - test/jdk/jigsaw/launcher/addexports/src/m1/jdk/test1/Main.java - test/jdk/jigsaw/launcher/addexports/src/m1/module-info.java - test/jdk/jigsaw/launcher/addexports/src/m2/jdk/test2/Main.java - test/jdk/jigsaw/launcher/addexports/src/m2/module-info.java - test/jdk/jigsaw/launcher/addexports/src/m3/jdk/test3/Main.java - test/jdk/jigsaw/launcher/addexports/src/m3/module-info.java - test/jdk/jigsaw/launcher/addexports/src/m4/jdk/test4/Type.java - test/jdk/jigsaw/launcher/addexports/src/m4/module-info.java - test/jdk/jigsaw/launcher/addmods/AddModsTest.java - test/jdk/jigsaw/launcher/addmods/src/app/Main.java - test/jdk/jigsaw/launcher/addmods/src/lib/jdk/lib/Util.java - test/jdk/jigsaw/launcher/addmods/src/lib/module-info.java - test/jdk/jigsaw/launcher/addreads/AddReadsTest.java - test/jdk/jigsaw/launcher/addreads/src/junit/org/junit/Assert.java - test/jdk/jigsaw/launcher/addreads/src/m1/module-info.java - test/jdk/jigsaw/launcher/addreads/src/m1/p/Main.java - test/jdk/jigsaw/launcher/basic/BasicTest.java - test/jdk/jigsaw/launcher/basic/src/test/jdk/test/Main.java - test/jdk/jigsaw/launcher/basic/src/test/module-info.java - test/jdk/jigsaw/launcher/limitmods/LimitModsTest.java - test/jdk/jigsaw/launcher/limitmods/src/test/jdk/test/UseAWT.java - test/jdk/jigsaw/launcher/limitmods/src/test/module-info.java - test/jdk/jigsaw/launcher/listmods/ListModsTest.java - test/jdk/jigsaw/launcher/listmods/src/java.transaction/javax/transaction/Transaction.java - test/jdk/jigsaw/launcher/listmods/src/java.transaction/javax/transaction/atomic/Atomic.java - test/jdk/jigsaw/launcher/listmods/src/java.transaction/module-info.java - test/jdk/jigsaw/launcher/listmods/src/m1/module-info.java - test/jdk/jigsaw/launcher/patch/PatchTest.java - test/jdk/jigsaw/launcher/patch/src/test/jdk/test/Main.java - test/jdk/jigsaw/launcher/patch/src/test/module-info.java - test/jdk/jigsaw/launcher/patch/src1/java.base/java/text/Annotation.java - test/jdk/jigsaw/launcher/patch/src1/java.base/java/text/AnnotationBuddy.java - test/jdk/jigsaw/launcher/patch/src1/jdk.compiler/com/sun/tools/javac/Main.java - test/jdk/jigsaw/launcher/patch/src1/jdk.compiler/com/sun/tools/javac/MainBuddy.java - test/jdk/jigsaw/launcher/patch/src1/jdk.naming.dns/com/sun/jndi/dns/DnsClient.java - test/jdk/jigsaw/launcher/patch/src1/jdk.naming.dns/com/sun/jndi/dns/DnsClientBuddy.java - test/jdk/jigsaw/launcher/patch/src2/java.base/java/lang2/Object.java - test/jdk/jigsaw/launcher/patch/src2/jdk.compiler/com/sun/tools/javac2/Main.java - test/jdk/jigsaw/launcher/patch/src2/jdk.naming.dns/com/sun/jndi/dns2/Zone.java - test/jdk/jigsaw/launcher/upgrademodulepath/UpgradeModulePathTest.java - test/jdk/jigsaw/launcher/upgrademodulepath/src/java.enterprise/javax/enterprise/context/Scope.java - test/jdk/jigsaw/launcher/upgrademodulepath/src/java.enterprise/module-info.java - test/jdk/jigsaw/launcher/upgrademodulepath/src/java.transaction/javax/transaction/Transaction.java - test/jdk/jigsaw/launcher/upgrademodulepath/src/java.transaction/module-info.java - test/jdk/jigsaw/launcher/upgrademodulepath/src/test/jdk/test/Main.java - test/jdk/jigsaw/launcher/upgrademodulepath/src/test/module-info.java - test/jdk/jigsaw/lib/CompilerUtils.java - test/jdk/jigsaw/lib/JarUtils.java - test/jdk/jigsaw/lib/ModuleUtils.java - test/jdk/jigsaw/module/AutomaticModulesTest.java - test/jdk/jigsaw/module/ConfigurationTest.java - test/jdk/jigsaw/module/ModuleDescriptorTest.java - test/jdk/jigsaw/module/ModuleFinderTest.java - test/jdk/jigsaw/module/ModuleReader/ModuleReaderTest.java - test/jdk/jigsaw/module/ModuleReader/src/m/module-info.java - test/jdk/jigsaw/module/ModuleReader/src/m/p/Main.java - test/jdk/jigsaw/module/ModuleReferenceTest.java - test/jdk/jigsaw/module/VersionTest.java - test/jdk/jigsaw/reflect/AccessibleObject/ModuleSetAccessibleTest.java - test/jdk/jigsaw/reflect/Layer/BasicLayerTest.java - test/jdk/jigsaw/reflect/Layer/LayerAndLoadersTest.java - test/jdk/jigsaw/reflect/Layer/layertest/Test.java - test/jdk/jigsaw/reflect/Layer/src/m1/module-info.java - test/jdk/jigsaw/reflect/Layer/src/m1/p/Main.java - test/jdk/jigsaw/reflect/Layer/src/m1/p/Service.java - test/jdk/jigsaw/reflect/Layer/src/m2/module-info.java - test/jdk/jigsaw/reflect/Layer/src/m2/q/Hello.java - test/jdk/jigsaw/reflect/Layer/src/m3/module-info.java - test/jdk/jigsaw/reflect/Layer/src/m3/w/Hello.java - test/jdk/jigsaw/reflect/Layer/src/m4/impl/ServiceImpl.java - test/jdk/jigsaw/reflect/Layer/src/m4/module-info.java - test/jdk/jigsaw/reflect/Module/AddExportsTest.java - test/jdk/jigsaw/reflect/Module/BasicModuleTest.java - test/jdk/jigsaw/reflect/Module/access/AccessTest.java - test/jdk/jigsaw/reflect/Module/access/src/target/module-info.java - test/jdk/jigsaw/reflect/Module/access/src/target/p/Exported.java - test/jdk/jigsaw/reflect/Module/access/src/target/p/Helper.java - test/jdk/jigsaw/reflect/Module/access/src/target/q/Internal.java - test/jdk/jigsaw/reflect/Module/access/src/test/module-info.java - test/jdk/jigsaw/reflect/Module/access/src/test/test/Main.java - test/jdk/jigsaw/reflect/Proxy/ProxyClassAccessTest.java - test/jdk/jigsaw/reflect/Proxy/ProxyForMethodHandle.java - test/jdk/jigsaw/reflect/Proxy/ProxyLayerTest.java - test/jdk/jigsaw/reflect/Proxy/ProxyModuleMapping.java - test/jdk/jigsaw/reflect/Proxy/ProxyTest.java - test/jdk/jigsaw/reflect/Proxy/q/NP.java - test/jdk/jigsaw/reflect/Proxy/q/U.java - test/jdk/jigsaw/reflect/Proxy/src/m1/module-info.java - test/jdk/jigsaw/reflect/Proxy/src/m1/p/one/I.java - test/jdk/jigsaw/reflect/Proxy/src/m1/p/one/internal/J.java - test/jdk/jigsaw/reflect/Proxy/src/m2/module-info.java - test/jdk/jigsaw/reflect/Proxy/src/m2/p/two/A.java - test/jdk/jigsaw/reflect/Proxy/src/m2/p/two/B.java - test/jdk/jigsaw/reflect/Proxy/src/m2/p/two/Bar.java - test/jdk/jigsaw/reflect/Proxy/src/m2/p/two/internal/C.java - test/jdk/jigsaw/reflect/Proxy/src/m3/module-info.java - test/jdk/jigsaw/reflect/Proxy/src/m3/p/three/P.java - test/jdk/jigsaw/reflect/Proxy/src/m3/p/three/internal/Q.java - test/jdk/jigsaw/reflect/Proxy/src/test/jdk/test/Main.java - test/jdk/jigsaw/reflect/Proxy/src/test/jdk/test/NP.java - test/jdk/jigsaw/reflect/Proxy/src/test/jdk/test/ProxyClassAccess.java - test/jdk/jigsaw/reflect/Proxy/src/test/jdk/test/ProxyTest.java - test/jdk/jigsaw/reflect/Proxy/src/test/jdk/test/internal/R.java - test/jdk/jigsaw/reflect/Proxy/src/test/jdk/test/internal/RImpl.java - test/jdk/jigsaw/reflect/Proxy/src/test/jdk/test/internal/foo/Foo.java - test/jdk/jigsaw/reflect/Proxy/src/test/jdk/test/internal/foo/FooException.java - test/jdk/jigsaw/reflect/Proxy/src/test/module-info.java - test/jdk/jigsaw/scenarios/automaticmodules/RunWithAutomaticModules.java - test/jdk/jigsaw/scenarios/automaticmodules/src/bananascript/META-INF/services/javax.script.ScriptEngineFactory - test/jdk/jigsaw/scenarios/automaticmodules/src/bananascript/org/banana/BananaScript.java - test/jdk/jigsaw/scenarios/automaticmodules/src/bananascript/org/banana/BananaScriptEngineFactory.java - test/jdk/jigsaw/scenarios/automaticmodules/src/basictest/module-info.java - test/jdk/jigsaw/scenarios/automaticmodules/src/basictest/test/Main.java - test/jdk/jigsaw/scenarios/automaticmodules/src/httpserver/http/HttpServer.java - test/jdk/jigsaw/scenarios/automaticmodules/src/httpserver/http/spi/HttpServerProvider.java - test/jdk/jigsaw/scenarios/automaticmodules/src/logging/logging/Logger.java - test/jdk/jigsaw/scenarios/automaticmodules/src/sptest/module-info.java - test/jdk/jigsaw/scenarios/automaticmodules/src/sptest/test/Main.java - test/jdk/jigsaw/scenarios/container/ContainerTest.java - test/jdk/jigsaw/scenarios/container/src/app1/app1/Main.java - test/jdk/jigsaw/scenarios/container/src/app1/module-info.java - test/jdk/jigsaw/scenarios/container/src/app2/app2/Main.java - test/jdk/jigsaw/scenarios/container/src/app2/module-info.java - test/jdk/jigsaw/scenarios/container/src/container/container/Main.java - test/jdk/jigsaw/scenarios/container/src/container/module-info.java - test/jdk/jigsaw/scenarios/container/src/java.ws.rs/javax/ws/rs/Client.java - test/jdk/jigsaw/scenarios/container/src/java.ws.rs/module-info.java - test/jdk/jigsaw/scenarios/container/src/java.xml.ws/javax/xml/ws/WebService.java - test/jdk/jigsaw/scenarios/container/src/java.xml.ws/module-info.java - test/jdk/jigsaw/scenarios/overlappingpackages/OverlappingPackagesTest.java - test/jdk/jigsaw/scenarios/overlappingpackages/src/m1/module-info.java - test/jdk/jigsaw/scenarios/overlappingpackages/src/m1/p/C1.java - test/jdk/jigsaw/scenarios/overlappingpackages/src/m2/module-info.java - test/jdk/jigsaw/scenarios/overlappingpackages/src/m2/p/C2.java - test/jdk/jigsaw/scenarios/overlappingpackages/src/misc/module-info.java - test/jdk/jigsaw/scenarios/overlappingpackages/src/misc/sun/misc/Unsafe.java - test/jdk/jigsaw/scenarios/overlappingpackages/src/test/module-info.java - test/jdk/jigsaw/scenarios/overlappingpackages/src/test/test/Main.java - test/jdk/jigsaw/tools/jimage/JImageTest.java - test/jdk/jigsaw/tools/jimage/JImageToolTest.java - test/jdk/jigsaw/tools/jimage/VerifyJimage.java - test/jdk/jigsaw/tools/jlink/CheckExecutable.java - test/jdk/jigsaw/tools/jlink/CustomPluginTest.java - test/jdk/jigsaw/tools/jlink/DefaultProviderTest.java - test/jdk/jigsaw/tools/jlink/ImageFileCreatorTest.java - test/jdk/jigsaw/tools/jlink/ImageFilePoolTest.java - test/jdk/jigsaw/tools/jlink/IntegrationTest.java - test/jdk/jigsaw/tools/jlink/JLink2Test.java - test/jdk/jigsaw/tools/jlink/JLinkNegativeTest.java - test/jdk/jigsaw/tools/jlink/JLinkOptimTest.java - test/jdk/jigsaw/tools/jlink/JLinkOptionsTest.java - test/jdk/jigsaw/tools/jlink/JLinkPluginsTest.java - test/jdk/jigsaw/tools/jlink/JLinkPostProcessingTest.java - test/jdk/jigsaw/tools/jlink/JLinkTest.java - test/jdk/jigsaw/tools/jlink/NativeTest.java - test/jdk/jigsaw/tools/jlink/ResourcePoolTest.java - test/jdk/jigsaw/tools/jlink/SecurityTest.java - test/jdk/jigsaw/tools/jlink/asmplugin/AddForgetResourcesTest.java - test/jdk/jigsaw/tools/jlink/asmplugin/AsmPluginTestBase.java - test/jdk/jigsaw/tools/jlink/asmplugin/BasicTest.java - test/jdk/jigsaw/tools/jlink/asmplugin/IdentityPluginTest.java - test/jdk/jigsaw/tools/jlink/asmplugin/NegativeTest.java - test/jdk/jigsaw/tools/jlink/asmplugin/PackageMappingTest.java - test/jdk/jigsaw/tools/jlink/asmplugin/SortingTest.java - test/jdk/jigsaw/tools/jlink/asmplugin/VisitorTest.java - test/jdk/jigsaw/tools/jlink/basic/BasicTest.java - test/jdk/jigsaw/tools/jlink/basic/src/test/jdk/test/Test.java - test/jdk/jigsaw/tools/jlink/basic/src/test/module-info.java - test/jdk/jigsaw/tools/jlink/customplugin/module-info.java - test/jdk/jigsaw/tools/jlink/customplugin/plugin/CustomPlugin.java - test/jdk/jigsaw/tools/jlink/customplugin/plugin/HelloPlugin.java - test/jdk/jigsaw/tools/jlink/hashes/HashesTest.java - test/jdk/jigsaw/tools/jlink/hashes/newsrc/m2/module-info.java - test/jdk/jigsaw/tools/jlink/hashes/newsrc/m2/org/m2/Util.java - test/jdk/jigsaw/tools/jlink/hashes/newsrc/not_matched/module-info.java - test/jdk/jigsaw/tools/jlink/hashes/newsrc/not_matched/org/not_matched/Name.java - test/jdk/jigsaw/tools/jlink/hashes/src/m1/module-info.java - test/jdk/jigsaw/tools/jlink/hashes/src/m1/org/m1/Main.java - test/jdk/jigsaw/tools/jlink/hashes/src/m2/module-info.java - test/jdk/jigsaw/tools/jlink/hashes/src/m2/org/m2/Util.java - test/jdk/jigsaw/tools/jlink/hashes/src/not_matched/module-info.java - test/jdk/jigsaw/tools/jlink/hashes/src/not_matched/org/not_matched/Name.java - test/jdk/jigsaw/tools/jlink/optimplugin/module-info.java - test/jdk/jigsaw/tools/jlink/optimplugin/optim/AType.java - test/jdk/jigsaw/tools/jlink/optimplugin/optim/ForNameTestCase.java - test/jdk/jigsaw/tools/jlink/plugins/CompressIndexesTest.java - test/jdk/jigsaw/tools/jlink/plugins/CompressorPluginTest.java - test/jdk/jigsaw/tools/jlink/plugins/ExcludeFilesPluginTest.java - test/jdk/jigsaw/tools/jlink/plugins/ExcludePluginTest.java - test/jdk/jigsaw/tools/jlink/plugins/ExcludeVMPluginTest.java - test/jdk/jigsaw/tools/jlink/plugins/FileCopierPluginTest.java - test/jdk/jigsaw/tools/jlink/plugins/GetAvailableLocales.java - test/jdk/jigsaw/tools/jlink/plugins/IncludeLocalesPluginTest.java - test/jdk/jigsaw/tools/jlink/plugins/InstalledModuleDescriptors/InstalledModulesTest.java - test/jdk/jigsaw/tools/jlink/plugins/InstalledModuleDescriptors/UserModuleTest.java - test/jdk/jigsaw/tools/jlink/plugins/InstalledModuleDescriptors/src/m1/module-info.java - test/jdk/jigsaw/tools/jlink/plugins/InstalledModuleDescriptors/src/m1/p1/Main.java - test/jdk/jigsaw/tools/jlink/plugins/InstalledModuleDescriptors/src/m1/p2/T.java - test/jdk/jigsaw/tools/jlink/plugins/InstalledModuleDescriptors/src/m2/module-info.java - test/jdk/jigsaw/tools/jlink/plugins/InstalledModuleDescriptors/src/m2/q/S1.java - test/jdk/jigsaw/tools/jlink/plugins/InstalledModuleDescriptors/src/m2/q/S2.java - test/jdk/jigsaw/tools/jlink/plugins/InstalledModuleDescriptors/src/m3/module-info.java - test/jdk/jigsaw/tools/jlink/plugins/LastSorterTest.java - test/jdk/jigsaw/tools/jlink/plugins/PluginOrderTest.java - test/jdk/jigsaw/tools/jlink/plugins/PluginsNegativeTest.java - test/jdk/jigsaw/tools/jlink/plugins/PrevisitorTest.java - test/jdk/jigsaw/tools/jlink/plugins/ResourceFilterTest.java - test/jdk/jigsaw/tools/jlink/plugins/SignatureParserTest.java - test/jdk/jigsaw/tools/jlink/plugins/SorterPluginTest.java - test/jdk/jigsaw/tools/jlink/plugins/StringSharingPluginTest.java - test/jdk/jigsaw/tools/jlink/plugins/StripDebugPluginTest.java - test/jdk/jigsaw/tools/jmod/JmodNegativeTest.java - test/jdk/jigsaw/tools/jmod/JmodTest.java - test/jdk/jigsaw/tools/jmod/src/foo/jdk/test/foo/Foo.java - test/jdk/jigsaw/tools/jmod/src/foo/jdk/test/foo/internal/Message.java - test/jdk/jigsaw/tools/jmod/src/foo/module-info.java - test/jdk/jigsaw/tools/lib/tests/Helper.java - test/jdk/jigsaw/tools/lib/tests/JImageGenerator.java - test/jdk/jigsaw/tools/lib/tests/JImageValidator.java - test/jdk/jigsaw/tools/lib/tests/Result.java - test/jdk/jigsaw/util/ServiceLoader/BasicTest.java - test/jdk/jigsaw/util/ServiceLoader/ServicesTest.java - test/jdk/jigsaw/util/ServiceLoader/src/bananascript/module-info.java - test/jdk/jigsaw/util/ServiceLoader/src/bananascript/org/banana/BananaScript.java - test/jdk/jigsaw/util/ServiceLoader/src/bananascript/org/banana/BananaScriptEngineFactory.java - test/jdk/jigsaw/util/ServiceLoader/src/pearscript/META-INF/services/javax.script.ScriptEngineFactory - test/jdk/jigsaw/util/ServiceLoader/src/pearscript/org/pear/PearScript.java - test/jdk/jigsaw/util/ServiceLoader/src/pearscript/org/pear/PearScriptEngineFactory.java - test/jdk/jigsaw/util/ServiceLoader/src/test/module-info.java - test/jdk/jigsaw/util/ServiceLoader/src/test/test/Main.java + test/jdk/modules/etc/JdkModules.java + test/jdk/modules/scenarios/automaticmodules/RunWithAutomaticModules.java + test/jdk/modules/scenarios/automaticmodules/src/bananascript/META-INF/services/javax.script.ScriptEngineFactory + test/jdk/modules/scenarios/automaticmodules/src/bananascript/org/banana/BananaScript.java + test/jdk/modules/scenarios/automaticmodules/src/bananascript/org/banana/BananaScriptEngineFactory.java + test/jdk/modules/scenarios/automaticmodules/src/basictest/module-info.java + test/jdk/modules/scenarios/automaticmodules/src/basictest/test/Main.java + test/jdk/modules/scenarios/automaticmodules/src/httpserver/http/HttpServer.java + test/jdk/modules/scenarios/automaticmodules/src/httpserver/http/spi/HttpServerProvider.java + test/jdk/modules/scenarios/automaticmodules/src/logging/logging/Logger.java + test/jdk/modules/scenarios/automaticmodules/src/sptest/module-info.java + test/jdk/modules/scenarios/automaticmodules/src/sptest/test/Main.java + test/jdk/modules/scenarios/container/ContainerTest.java + test/jdk/modules/scenarios/container/src/app1/app1/Main.java + test/jdk/modules/scenarios/container/src/app1/module-info.java + test/jdk/modules/scenarios/container/src/app2/app2/Main.java + test/jdk/modules/scenarios/container/src/app2/module-info.java + test/jdk/modules/scenarios/container/src/container/container/Main.java + test/jdk/modules/scenarios/container/src/container/module-info.java + test/jdk/modules/scenarios/container/src/java.ws.rs/javax/ws/rs/Client.java + test/jdk/modules/scenarios/container/src/java.ws.rs/module-info.java + test/jdk/modules/scenarios/container/src/java.xml.ws/javax/xml/ws/WebService.java + test/jdk/modules/scenarios/container/src/java.xml.ws/module-info.java + test/jdk/modules/scenarios/overlappingpackages/OverlappingPackagesTest.java + test/jdk/modules/scenarios/overlappingpackages/src/m1/module-info.java + test/jdk/modules/scenarios/overlappingpackages/src/m1/p/C1.java + test/jdk/modules/scenarios/overlappingpackages/src/m2/module-info.java + test/jdk/modules/scenarios/overlappingpackages/src/m2/p/C2.java + test/jdk/modules/scenarios/overlappingpackages/src/misc/module-info.java + test/jdk/modules/scenarios/overlappingpackages/src/misc/sun/misc/Unsafe.java + test/jdk/modules/scenarios/overlappingpackages/src/test/module-info.java + test/jdk/modules/scenarios/overlappingpackages/src/test/test/Main.java + test/lib/testlibrary/CompilerUtils.java + test/lib/testlibrary/JarUtils.java + test/lib/testlibrary/ModuleUtils.java + test/tools/jimage/JImageTest.java + test/tools/jimage/JImageToolTest.java + test/tools/jimage/VerifyJimage.java + test/tools/jlink/CheckExecutable.java + test/tools/jlink/CustomPluginTest.java + test/tools/jlink/DefaultProviderTest.java + test/tools/jlink/ImageFileCreatorTest.java + test/tools/jlink/ImageFilePoolTest.java + test/tools/jlink/IntegrationTest.java + test/tools/jlink/JLink2Test.java + test/tools/jlink/JLinkNegativeTest.java + test/tools/jlink/JLinkOptimTest.java + test/tools/jlink/JLinkOptionsTest.java + test/tools/jlink/JLinkPluginsTest.java + test/tools/jlink/JLinkPostProcessingTest.java + test/tools/jlink/JLinkTest.java + test/tools/jlink/NativeTest.java + test/tools/jlink/ResourcePoolTest.java + test/tools/jlink/SecurityTest.java + test/tools/jlink/asmplugin/AddForgetResourcesTest.java + test/tools/jlink/asmplugin/AsmPluginTestBase.java + test/tools/jlink/asmplugin/BasicTest.java + test/tools/jlink/asmplugin/IdentityPluginTest.java + test/tools/jlink/asmplugin/NegativeTest.java + test/tools/jlink/asmplugin/PackageMappingTest.java + test/tools/jlink/asmplugin/SortingTest.java + test/tools/jlink/asmplugin/VisitorTest.java + test/tools/jlink/basic/BasicTest.java + test/tools/jlink/basic/src/test/jdk/test/Test.java + test/tools/jlink/basic/src/test/module-info.java + test/tools/jlink/customplugin/module-info.java + test/tools/jlink/customplugin/plugin/CustomPlugin.java + test/tools/jlink/customplugin/plugin/HelloPlugin.java + test/tools/jlink/hashes/HashesTest.java + test/tools/jlink/hashes/newsrc/m2/module-info.java + test/tools/jlink/hashes/newsrc/m2/org/m2/Util.java + test/tools/jlink/hashes/newsrc/not_matched/module-info.java + test/tools/jlink/hashes/newsrc/not_matched/org/not_matched/Name.java + test/tools/jlink/hashes/src/m1/module-info.java + test/tools/jlink/hashes/src/m1/org/m1/Main.java + test/tools/jlink/hashes/src/m2/module-info.java + test/tools/jlink/hashes/src/m2/org/m2/Util.java + test/tools/jlink/hashes/src/not_matched/module-info.java + test/tools/jlink/hashes/src/not_matched/org/not_matched/Name.java + test/tools/jlink/optimplugin/module-info.java + test/tools/jlink/optimplugin/optim/AType.java + test/tools/jlink/optimplugin/optim/ForNameTestCase.java + test/tools/jlink/plugins/CompressIndexesTest.java + test/tools/jlink/plugins/CompressorPluginTest.java + test/tools/jlink/plugins/ExcludeFilesPluginTest.java + test/tools/jlink/plugins/ExcludePluginTest.java + test/tools/jlink/plugins/ExcludeVMPluginTest.java + test/tools/jlink/plugins/FileCopierPluginTest.java + test/tools/jlink/plugins/GetAvailableLocales.java + test/tools/jlink/plugins/IncludeLocalesPluginTest.java + test/tools/jlink/plugins/InstalledModuleDescriptors/InstalledModulesTest.java + test/tools/jlink/plugins/InstalledModuleDescriptors/UserModuleTest.java + test/tools/jlink/plugins/InstalledModuleDescriptors/src/m1/module-info.java + test/tools/jlink/plugins/InstalledModuleDescriptors/src/m1/p1/Main.java + test/tools/jlink/plugins/InstalledModuleDescriptors/src/m1/p2/T.java + test/tools/jlink/plugins/InstalledModuleDescriptors/src/m2/module-info.java + test/tools/jlink/plugins/InstalledModuleDescriptors/src/m2/q/S1.java + test/tools/jlink/plugins/InstalledModuleDescriptors/src/m2/q/S2.java + test/tools/jlink/plugins/InstalledModuleDescriptors/src/m3/module-info.java + test/tools/jlink/plugins/LastSorterTest.java + test/tools/jlink/plugins/PluginOrderTest.java + test/tools/jlink/plugins/PluginsNegativeTest.java + test/tools/jlink/plugins/PrevisitorTest.java + test/tools/jlink/plugins/ResourceFilterTest.java + test/tools/jlink/plugins/SignatureParserTest.java + test/tools/jlink/plugins/SorterPluginTest.java + test/tools/jlink/plugins/StringSharingPluginTest.java + test/tools/jlink/plugins/StripDebugPluginTest.java + test/tools/jmod/JmodNegativeTest.java + test/tools/jmod/JmodTest.java + test/tools/jmod/src/foo/jdk/test/foo/Foo.java + test/tools/jmod/src/foo/jdk/test/foo/internal/Message.java + test/tools/jmod/src/foo/module-info.java + test/tools/launcher/modules/addexports/AddExportsTest.java + test/tools/launcher/modules/addexports/src/java.transaction/javax/transaction/Transaction.java + test/tools/launcher/modules/addexports/src/java.transaction/javax/transaction/internal/Helper.java + test/tools/launcher/modules/addexports/src/java.transaction/module-info.java + test/tools/launcher/modules/addexports/src/m1/jdk/test1/Main.java + test/tools/launcher/modules/addexports/src/m1/module-info.java + test/tools/launcher/modules/addexports/src/m2/jdk/test2/Main.java + test/tools/launcher/modules/addexports/src/m2/module-info.java + test/tools/launcher/modules/addexports/src/m3/jdk/test3/Main.java + test/tools/launcher/modules/addexports/src/m3/module-info.java + test/tools/launcher/modules/addexports/src/m4/jdk/test4/Type.java + test/tools/launcher/modules/addexports/src/m4/module-info.java + test/tools/launcher/modules/addmods/AddModsTest.java + test/tools/launcher/modules/addmods/src/app/Main.java + test/tools/launcher/modules/addmods/src/lib/jdk/lib/Util.java + test/tools/launcher/modules/addmods/src/lib/module-info.java + test/tools/launcher/modules/addreads/AddReadsTest.java + test/tools/launcher/modules/addreads/src/junit/org/junit/Assert.java + test/tools/launcher/modules/addreads/src/m1/module-info.java + test/tools/launcher/modules/addreads/src/m1/p/Main.java + test/tools/launcher/modules/basic/BasicTest.java + test/tools/launcher/modules/basic/src/test/jdk/test/Main.java + test/tools/launcher/modules/basic/src/test/module-info.java + test/tools/launcher/modules/limitmods/LimitModsTest.java + test/tools/launcher/modules/limitmods/src/test/jdk/test/UseAWT.java + test/tools/launcher/modules/limitmods/src/test/module-info.java + test/tools/launcher/modules/listmods/ListModsTest.java + test/tools/launcher/modules/listmods/src/java.transaction/javax/transaction/Transaction.java + test/tools/launcher/modules/listmods/src/java.transaction/javax/transaction/atomic/Atomic.java + test/tools/launcher/modules/listmods/src/java.transaction/module-info.java + test/tools/launcher/modules/listmods/src/m1/module-info.java + test/tools/launcher/modules/patch/PatchTest.java + test/tools/launcher/modules/patch/src/test/jdk/test/Main.java + test/tools/launcher/modules/patch/src/test/module-info.java + test/tools/launcher/modules/patch/src1/java.base/java/text/Annotation.java + test/tools/launcher/modules/patch/src1/java.base/java/text/AnnotationBuddy.java + test/tools/launcher/modules/patch/src1/jdk.compiler/com/sun/tools/javac/Main.java + test/tools/launcher/modules/patch/src1/jdk.compiler/com/sun/tools/javac/MainBuddy.java + test/tools/launcher/modules/patch/src1/jdk.naming.dns/com/sun/jndi/dns/DnsClient.java + test/tools/launcher/modules/patch/src1/jdk.naming.dns/com/sun/jndi/dns/DnsClientBuddy.java + test/tools/launcher/modules/patch/src2/java.base/java/lang2/Object.java + test/tools/launcher/modules/patch/src2/jdk.compiler/com/sun/tools/javac2/Main.java + test/tools/launcher/modules/patch/src2/jdk.naming.dns/com/sun/jndi/dns2/Zone.java + test/tools/launcher/modules/upgrademodulepath/UpgradeModulePathTest.java + test/tools/launcher/modules/upgrademodulepath/src/java.enterprise/javax/enterprise/context/Scope.java + test/tools/launcher/modules/upgrademodulepath/src/java.enterprise/module-info.java + test/tools/launcher/modules/upgrademodulepath/src/java.transaction/javax/transaction/Transaction.java + test/tools/launcher/modules/upgrademodulepath/src/java.transaction/module-info.java + test/tools/launcher/modules/upgrademodulepath/src/test/jdk/test/Main.java + test/tools/launcher/modules/upgrademodulepath/src/test/module-info.java + test/tools/lib/tests/Helper.java + test/tools/lib/tests/JImageGenerator.java + test/tools/lib/tests/JImageValidator.java + test/tools/lib/tests/Result.java From mandy.chung at oracle.com Tue Mar 15 18:21:05 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 15 Mar 2016 18:21:05 +0000 Subject: hg: jigsaw/jake/jdk: 2 new changesets Message-ID: <201603151821.u2FIL5Gu029934@aojmv0008.oracle.com> Changeset: 37c2fa5d57ce Author: mchung Date: 2016-03-15 11:19 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/37c2fa5d57ce Move ProblemList.jake.txt to ProblemList.txt ! test/Makefile - test/ProblemList.jake.txt ! test/ProblemList.txt Changeset: ec17ca2d2932 Author: mchung Date: 2016-03-15 11:20 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ec17ca2d2932 Update test/Makefile to use jtreg 4.2 ! test/Makefile From pbenedict at apache.org Tue Mar 15 18:25:49 2016 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 15 Mar 2016 13:25:49 -0500 Subject: Package, import and type declarations are allowed now in module-info.java by spec In-Reply-To: References: <56D07F37.1030806@oracle.com> <56D098BB.5070200@oracle.com> <56E021CE.3050801@oracle.com> <56E09D62.3060507@oracle.com> <56E7395A.4000202@oracle.com> Message-ID: I am happy to say the latest EA only allows "module" or types. It is either-or but not both. Cheers, Paul On Tue, Mar 15, 2016 at 12:43 PM, Paul Benedict wrote: > On Mon, Mar 14, 2016 at 5:21 PM, Alex Buckley > wrote: > >> The JLS doesn't know what the string "module-info.class" means or what a >> "JAR root" is. > > > Of course. Though that wasn't my ultimate point; I was merely illustrating > (philosophically) why having "package" in module-info.java is nonsensical > syntax. A "package" statement doesn't mean anything useful in the context > of specifying module configuration. As far as I am aware, the module syntax > is meant to standalone in the file, but please correct me if you have other > intentions for the syntax. If you can also declare types, then a "package" > statement begins to make more sense -- but it would seem like a clumsy way > of doing things, which I wouldn't advocate (or allow syntactically). > > Cheers, > Paul > > >> In 3/14/2016 9:08 AM, Paul Benedict wrote: >> >>> Alex, you wrote: "The JLS doesn't prevent javac from rejecting a package >>> declaration or an import declaration in a file called module-info.java." >>> >>> It seems that a package declaration, in this context, should be >>> prohibited syntax because module-info.class is always in the JAR root >>> which has no package. >>> >>> Cheers, >>> Paul >>> >>> On Wed, Mar 9, 2016 at 4:02 PM, Alex Buckley >> > wrote: >>> >>> The JLS doesn't prevent javac from rejecting a package declaration >>> or an import declaration in a file called module-info.java. >>> >>> In fact, since a package declaration or import declaration must be >>> followed by a type declaration, and since a type declaration cannot >>> use a hyphen, javac is free to take the optional rule from JLS 7.6 >>> -- filename must align with type declaration -- and develop it >>> further: rejecting a package declaration or import declaration in >>> module-info.java because the filename cannot possibly align with any >>> type declaration. >>> >>> I can't speak to what a particular EA build of javac is doing with a >>> particular option. javac options are irrelevant to the JLS. If a >>> compiler accepts the Java language circa SE 9, then a module >>> declaration is a valid compilation unit. What's the name of the file >>> containing such a compilation unit? Anything the compiler likes. >>> >>> Alex >>> >>> On 3/9/2016 5:14 AM, Georgiy Rakov wrote: >>> >>> Hi Alex, >>> >>> if I understand correctly you mean about following assertions >>> from JLS 7.6: >>> >>> If and only if packages are stored in a file system (?7.2 >>> >>> < >>> http://docs.oracle.com/javase/specs/jls/se8/html/jls-7.html#jls-7.2>), >>> the host system may choose to enforce the restriction that >>> it is a >>> compile-time error if a type is not found in a file under a >>> name >>> composed of the type name plus an extension (such as >>> |.java|or >>> |.jav|) if either of the following is true: >>> >>> * >>> >>> The type is referred to by code in other compilation >>> units of >>> the package in which the type is declared. >>> >>> * >>> >>> The type is declared |public|(and therefore is >>> potentially >>> accessible from code in other packages). >>> >>> Literally these assertion doesn't make presented behavior >>> corresponding >>> to spec because the declared type is neither public nor being >>> referred >>> to from other sources being compiled. >>> >>> Nevertheless following sources doesn't compile either despite >>> the fact >>> that no types are declared there at all. >>> Namely when only package is specified: >>> >>> mod\module-info.java: >>> module mod { >>> exports pkg; >>> } >>> >>> mod\pkg\module-info.java: >>> package pkg; >>> >>> then compiling it by following command line with javac from [2]: >>> >>> javac -modulesourcepath . mod\module-info.java >>> mod\pkg\module-info.java >>> >>> causes following output: >>> >>> mod\pkg\module-info.java:1: error: expected 'module >>> package pkg; >>> ^ >>> 1 error >>> >>> When only import statment is specified: >>> >>> mod\module-info.java: >>> module mod { >>> exports pkg; >>> } >>> >>> mod\pkg\module-info.java: >>> import java.util.List; >>> >>> then compiling it by following command line with javac from [2]: >>> >>> javac -modulesourcepath . mod\module-info.java >>> mod\pkg\module-info.java >>> >>> causes following output: >>> >>> mod\pkg\module-info.java:1: error: expected 'module' >>> import java.util.List; >>> ^ >>> 1 error >>> >>> Please see minimized test cases attached in tests23.zip. In >>> order to >>> reproduce, please: >>> >>> 1. Unzip the attached archive to some dir on Windows machined, >>> say >>> directory A; >>> 2. Rename A\test2\test_bat to A\test2\test.bat and >>> A\test3\test_bat to >>> A\test3\test.bat; >>> 3. Modify these two test.bat files by changing JDK_HOME variable >>> to >>> point to your jigsaw JDK 9 installation directory; >>> 4. Run test.bat files in turn. >>> >>> BTW: javac behavior [2] currently differs depending on whether >>> sources >>> are compiled "in module" mode or not. By "module mode" I mean >>> specifying >>> modulesourcepath option. For instance without modulesourcepath >>> option >>> module declarations are not recognized as valid grammar while >>> import >>> declarations contained within module-info.java compile >>> successfully. >>> This can be seen by experimenting with test3 from the attached >>> testcases. Now javac from [2] even can throw exception in >>> "non-module" >>> mode, please see >>> https://bugs.openjdk.java.net/browse/JDK-8150733. >>> >>> Could you please tell if spec will specify somehow two modes of >>> processing java-sources, now it [1] doesn't. >>> >>> [1] http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html >>> [2] >>> >>> http://download.java.net/java/jigsaw/archive/106/binaries/jigsaw-jdk-9-ea+106_windows-x86_bin.zip >>> >>> Thanks, >>> Georgiy. >>> >>> On 26.02.2016 21:26, Alex Buckley wrote: >>> >>> On 2/26/2016 8:37 AM, Georgiy Rakov wrote: >>> >>> current spec [1] now contains following assertions >>> related to grammar: >>> >>> A compilation unit (JLS 7.3) may contain a module >>> declaration, in >>> which case the filename of the compilation unit is >>> typically >>> |module-info.java|. >>> >>> CompilationUnit: >>> [PackageDeclaration] {ImportDeclaration} >>> {TypeDeclaration} >>> ModuleDeclaration >>> >>> These assertions allows to specify any of import, >>> package or type >>> declarations in any compilation unit, for instance >>> module-info.java is >>> allowed to contain any of the mentioned declarations. >>> However currently >>> javac in the latest jigsaw build [2] reports an error on >>> such cases >>> provided they are compiled in module mode. For example >>> if we have >>> following directory structure: >>> >>> mod\module-info.java: >>> module mod { >>> exports pkg; >>> } >>> >>> mod\pkg\module-info.java: >>> package pkg; >>> >>> class C { >>> } >>> >>> then compiling it by following command line with javac >>> from [2]: >>> >>> javac -modulesourcepath . mod\module-info.java >>> mod\pkg\module-info.java >>> >>> causes following output: >>> >>> mod\pkg\module-info.java:1: error: expected 'module' >>> package pkg; >>> ^ >>> 1 error >>> >>> >>> javac is merely choosing to implement the rule at the end of >>> JLS 7.6 >>> that a type declaration (optionally preceded by >>> package/import >>> declarations) must be provided in a suitably named file. >>> >>> Perhaps I should say "a variant of the rule" because 7.6 as >>> written >>> concerns a public type and your example has a package-access >>> type. >>> Still, bottom line, javac is free to require that a >>> compilation unit >>> which starts with a package declaration _must not_ be in a >>> file called >>> foo-bar.java -- the hyphen indicates a name that can't >>> possibly align >>> with the type declared in the compilation unit. >>> >>> The error message for mod\pkg\module-info.java could be a >>> bit more >>> helpful, but that's a quality-of-implementation detail. >>> >>> Conversely, a compilation unit that contains a module >>> declaration >>> _may_ be in a file called module-info.java, or in a file >>> called >>> foo-bar.java, or in a file called mod_decl.JAV. The >>> "typically" in [1] >>> is meant to indicate that the sub-clause on filename is >>> non-normative. >>> This is akin to how a compilation unit that contains a >>> package-access >>> type declaration for class C _may_ be in a file D.java. >>> >>> Alex >>> >>> >>> >>> > From pbenedict at apache.org Tue Mar 15 18:29:17 2016 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 15 Mar 2016 13:29:17 -0500 Subject: Unexpected package bug in jdk-9-ea+109 Message-ID: File src/z/module-info.java: package z; Command line: javac -d out src/z/module-info.java Output: An exception has occurred in the compiler (9-ea). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.j ava.com) for duplicates. Include your program and the following diagnostic in your report. Thank you. java.lang.NullPointerException at com.sun.tools.javac.comp.TypeEnter$ImportsPhase.checkClassPackageClash(jdk.compiler at 9-ea /TypeEnter.java:362) at com.sun.tools.javac.comp.TypeEnter$ImportsPhase.resolveImports(jdk.compiler at 9-ea /TypeEnter.java:342) at com.sun.tools.javac.comp.TypeEnter$ImportsPhase.access$1600(jdk.compiler at 9-ea /TypeEnter.java:284) at com.sun.tools.javac.comp.TypeEnter.lambda$ensureImportsChecked$0(jdk.compiler at 9-ea /TypeEnter.java:169) at com.sun.tools.javac.comp.TypeEnter.finishImports(jdk.compiler at 9-ea /TypeEnter.java:220) at com.sun.tools.javac.comp.TypeEnter.ensureImportsChecked(jdk.compiler at 9-ea /TypeEnter.java:169) at com.sun.tools.javac.comp.Enter.complete(jdk.compiler at 9-ea /Enter.java:553) at com.sun.tools.javac.comp.Enter.main(jdk.compiler at 9-ea /Enter.java:524) at com.sun.tools.javac.main.JavaCompiler.enterTrees(jdk.compiler at 9-ea /JavaCompiler.java:1038) at com.sun.tools.javac.main.JavaCompiler.compile(jdk.compiler at 9-ea /JavaCompiler.java:904) at com.sun.tools.javac.main.Main.compile(jdk.compiler at 9-ea /Main.java:261) at com.sun.tools.javac.main.Main.compile(jdk.compiler at 9-ea /Main.java:143) at com.sun.tools.javac.Main.compile(jdk.compiler at 9-ea/Main.java:55) at com.sun.tools.javac.Main.main(jdk.compiler at 9-ea/Main.java:41) Cheers, Paul From Alan.Bateman at oracle.com Tue Mar 15 18:32:52 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 15 Mar 2016 18:32:52 +0000 Subject: Unexpected package bug in jdk-9-ea+109 In-Reply-To: References: Message-ID: <56E85554.3000604@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8150733 On 15/03/2016 18:29, Paul Benedict wrote: > File src/z/module-info.java: > package z; > > Command line: > javac -d out src/z/module-info.java > > Output: > An exception has occurred in the compiler (9-ea). Please file a bug against > the Java compiler via the Java bug reporting page (http://bugreport.java.com) > after checking the Bug Database (http://bugs.j > ava.com) for duplicates. Include your program and the following diagnostic > in your report. Thank you. > java.lang.NullPointerException > at > com.sun.tools.javac.comp.TypeEnter$ImportsPhase.checkClassPackageClash(jdk.compiler at 9-ea > /TypeEnter.java:362) > at > com.sun.tools.javac.comp.TypeEnter$ImportsPhase.resolveImports(jdk.compiler at 9-ea > /TypeEnter.java:342) > at > com.sun.tools.javac.comp.TypeEnter$ImportsPhase.access$1600(jdk.compiler at 9-ea > /TypeEnter.java:284) > at > com.sun.tools.javac.comp.TypeEnter.lambda$ensureImportsChecked$0(jdk.compiler at 9-ea > /TypeEnter.java:169) > at > com.sun.tools.javac.comp.TypeEnter.finishImports(jdk.compiler at 9-ea > /TypeEnter.java:220) > at > com.sun.tools.javac.comp.TypeEnter.ensureImportsChecked(jdk.compiler at 9-ea > /TypeEnter.java:169) > at com.sun.tools.javac.comp.Enter.complete(jdk.compiler at 9-ea > /Enter.java:553) > at com.sun.tools.javac.comp.Enter.main(jdk.compiler at 9-ea > /Enter.java:524) > at > com.sun.tools.javac.main.JavaCompiler.enterTrees(jdk.compiler at 9-ea > /JavaCompiler.java:1038) > at com.sun.tools.javac.main.JavaCompiler.compile(jdk.compiler at 9-ea > /JavaCompiler.java:904) > at com.sun.tools.javac.main.Main.compile(jdk.compiler at 9-ea > /Main.java:261) > at com.sun.tools.javac.main.Main.compile(jdk.compiler at 9-ea > /Main.java:143) > at com.sun.tools.javac.Main.compile(jdk.compiler at 9-ea/Main.java:55) > at com.sun.tools.javac.Main.main(jdk.compiler at 9-ea/Main.java:41) > > Cheers, > Paul From alan.bateman at oracle.com Tue Mar 15 18:49:07 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 15 Mar 2016 18:49:07 +0000 Subject: hg: jigsaw/jake/jdk: Missing test for -adds ALL_MODULE-PATH Message-ID: <201603151849.u2FIn7uc011961@aojmv0008.oracle.com> Changeset: 22b9f705226c Author: alanb Date: 2016-03-15 18:48 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/22b9f705226c Missing test for -adds ALL_MODULE-PATH ! test/tools/launcher/modules/addmods/AddModsTest.java From mandy.chung at oracle.com Tue Mar 15 19:05:18 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 15 Mar 2016 19:05:18 +0000 Subject: hg: jigsaw/jake/jdk: Rename and clean up JdkModules test Message-ID: <201603151905.u2FJ5Iwo018896@aojmv0008.oracle.com> Changeset: 98fa6b5b262f Author: mchung Date: 2016-03-15 12:05 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/98fa6b5b262f Rename and clean up JdkModules test - test/jdk/modules/etc/JdkModules.java + test/jdk/modules/etc/VerifyModuleDelegation.java From mandy.chung at oracle.com Tue Mar 15 19:07:52 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 15 Mar 2016 19:07:52 +0000 Subject: hg: jigsaw/jake/hotspot: Bump jtreg requiredVersion to 4.2 Message-ID: <201603151907.u2FJ7q6q020209@aojmv0008.oracle.com> Changeset: 425a05d96c09 Author: mchung Date: 2016-03-15 12:00 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/425a05d96c09 Bump jtreg requiredVersion to 4.2 ! test/TEST.ROOT From pbenedict at apache.org Tue Mar 15 19:07:52 2016 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 15 Mar 2016 14:07:52 -0500 Subject: "Provides" and "with" type relationships Message-ID: module z { exports z; provides z.Main with z.Main; } The SOTM says "Service-provider declarations can be further interpreted to ensure that providers (e.g., com.mysql.jdbc.Driver) actually do implement their declared service interfaces" (section 4, para. 8). I see javac checking that they are related types, but javac is not checking that "provides" is an interface type. That is what I was expecting based on the reading material. The other unexpected outcome was that provides/with allows the identical type. I don't know if that's intended, but please advise. PS: I did go through the open tickets this time (thanks Alan) and do not see any similar reports. If I missed it, I apologize; just trying not to waste your time by reporting a duplicate. Cheers, Paul From mandy.chung at oracle.com Tue Mar 15 19:08:00 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 15 Mar 2016 19:08:00 +0000 Subject: hg: jigsaw/jake/jaxp: Bump jtreg requiredVersion to 4.2 Message-ID: <201603151908.u2FJ80nc020334@aojmv0008.oracle.com> Changeset: d5f6b0d71c34 Author: mchung Date: 2016-03-15 12:00 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/d5f6b0d71c34 Bump jtreg requiredVersion to 4.2 ! test/TEST.ROOT From mandy.chung at oracle.com Tue Mar 15 19:08:06 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 15 Mar 2016 19:08:06 +0000 Subject: hg: jigsaw/jake/jdk: Bump jtreg requiredVersion to 4.2 Message-ID: <201603151908.u2FJ86Dk020521@aojmv0008.oracle.com> Changeset: 31d2982578fe Author: mchung Date: 2016-03-15 12:01 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/31d2982578fe Bump jtreg requiredVersion to 4.2 ! test/TEST.ROOT From mandy.chung at oracle.com Tue Mar 15 19:08:13 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 15 Mar 2016 19:08:13 +0000 Subject: hg: jigsaw/jake/langtools: Bump jtreg requiredVersion to 4.2 Message-ID: <201603151908.u2FJ8DFJ020582@aojmv0008.oracle.com> Changeset: 9dd59ecda4eb Author: mchung Date: 2016-03-15 12:01 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/9dd59ecda4eb Bump jtreg requiredVersion to 4.2 ! test/TEST.ROOT From mandy.chung at oracle.com Tue Mar 15 19:08:15 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 15 Mar 2016 19:08:15 +0000 Subject: hg: jigsaw/jake/nashorn: Bump jtreg requiredVersion to 4.2 Message-ID: <201603151908.u2FJ8FNY020636@aojmv0008.oracle.com> Changeset: 0dfe12b7a113 Author: mchung Date: 2016-03-15 12:01 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/0dfe12b7a113 Bump jtreg requiredVersion to 4.2 ! test/TEST.ROOT From alan.bateman at oracle.com Tue Mar 15 19:16:30 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 15 Mar 2016 19:16:30 +0000 Subject: hg: jigsaw/jake/jdk: 2 new changesets Message-ID: <201603151916.u2FJGVEI024552@aojmv0008.oracle.com> Changeset: 25f2e8deaa8c Author: alanb Date: 2016-03-15 19:12 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/25f2e8deaa8c Module::toString needs more tests ! test/java/lang/reflect/Module/BasicModuleTest.java Changeset: 2ebb5997fb5c Author: alanb Date: 2016-03-15 19:12 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2ebb5997fb5c Merge - test/jdk/modules/etc/JdkModules.java From alex.buckley at oracle.com Tue Mar 15 19:26:15 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 15 Mar 2016 12:26:15 -0700 Subject: "Provides" and "with" type relationships In-Reply-To: References: Message-ID: <56E861D7.4070005@oracle.com> The first operand to 'provides' (the "service interface") is not constrained to be an interface by "Modules in the Java Language and JVM". This is because the spec of j.u.ServiceLoader ("a service is represented by a single type, that is, a single interface or abstract class"). The second operand to 'provides' (the "service implementation") is constrained not to be an interface or an abstract class by "Modules in the Java Language and JVM". This is also because of the spec of j.u.ServiceLoader ("provider classes must have a zero-argument constructor so that they can be instantiated during loading"). Bear in mind that the JCK team can easily set up abstract test cases like this. What they can't do is check whether YOUR application runs on JDK-9-with-Jigsaw, or whether arbitrary JARs on YOUR classpath work as automatic modules. Alex On 3/15/2016 12:07 PM, Paul Benedict wrote: > module z { > exports z; > provides z.Main with z.Main; > } > > The SOTM says "Service-provider declarations can be further interpreted to > ensure that providers (e.g., com.mysql.jdbc.Driver) actually do implement > their declared service interfaces" (section 4, para. 8). > > I see javac checking that they are related types, but javac is not checking > that "provides" is an interface type. That is what I was expecting based on > the reading material. > > The other unexpected outcome was that provides/with allows the identical > type. I don't know if that's intended, but please advise. > > PS: I did go through the open tickets this time (thanks Alan) and do not > see any similar reports. If I missed it, I apologize; just trying not to > waste your time by reporting a duplicate. > > Cheers, > Paul > From pbenedict at apache.org Tue Mar 15 19:39:42 2016 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 15 Mar 2016 14:39:42 -0500 Subject: "Provides" and "with" type relationships In-Reply-To: <56E861D7.4070005@oracle.com> References: <56E861D7.4070005@oracle.com> Message-ID: Thanks for your response Alex. If I am understanding you correctly, "provides" is "not constrained to be an interface" because it can be "a single interface or abstract class". So shouldn't my concrete class for "provides" be rejected by the compiler? And is it okay that both types were identical? Cheers, Paul On Tue, Mar 15, 2016 at 2:26 PM, Alex Buckley wrote: > The first operand to 'provides' (the "service interface") is not > constrained to be an interface by "Modules in the Java Language and JVM". > This is because the spec of j.u.ServiceLoader ("a service is represented by > a single type, that is, a single interface or abstract class"). > > The second operand to 'provides' (the "service implementation") is > constrained not to be an interface or an abstract class by "Modules in the > Java Language and JVM". This is also because of the spec of > j.u.ServiceLoader ("provider classes must have a zero-argument constructor > so that they can be instantiated during loading"). > > Bear in mind that the JCK team can easily set up abstract test cases like > this. What they can't do is check whether YOUR application runs on > JDK-9-with-Jigsaw, or whether arbitrary JARs on YOUR classpath work as > automatic modules. > > Alex > > > On 3/15/2016 12:07 PM, Paul Benedict wrote: > >> module z { >> exports z; >> provides z.Main with z.Main; >> } >> >> The SOTM says "Service-provider declarations can be further interpreted to >> ensure that providers (e.g., com.mysql.jdbc.Driver) actually do implement >> their declared service interfaces" (section 4, para. 8). >> >> I see javac checking that they are related types, but javac is not >> checking >> that "provides" is an interface type. That is what I was expecting based >> on >> the reading material. >> >> The other unexpected outcome was that provides/with allows the identical >> type. I don't know if that's intended, but please advise. >> >> PS: I did go through the open tickets this time (thanks Alan) and do not >> see any similar reports. If I missed it, I apologize; just trying not to >> waste your time by reporting a duplicate. >> >> Cheers, >> Paul >> >> From harold.seigel at oracle.com Tue Mar 15 19:42:44 2016 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Tue, 15 Mar 2016 19:42:44 +0000 Subject: hg: jigsaw/jake/hotspot: Fix failing jvmci/compilerToVM tests. Message-ID: <201603151942.u2FJgiOK007013@aojmv0008.oracle.com> Changeset: 474012546f4d Author: hseigel Date: 2016-03-15 15:15 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/474012546f4d Fix failing jvmci/compilerToVM tests. ! test/compiler/jvmci/compilerToVM/LookupKlassInPoolTest.java ! test/compiler/jvmci/compilerToVM/LookupKlassRefIndexInPoolTest.java ! test/compiler/jvmci/compilerToVM/LookupMethodInPoolTest.java ! test/compiler/jvmci/compilerToVM/LookupNameAndTypeRefIndexInPoolTest.java ! test/compiler/jvmci/compilerToVM/LookupNameInPoolTest.java ! test/compiler/jvmci/compilerToVM/LookupSignatureInPoolTest.java ! test/compiler/jvmci/compilerToVM/ResolveConstantInPoolTest.java ! test/compiler/jvmci/compilerToVM/ResolveFieldInPoolTest.java ! test/compiler/jvmci/compilerToVM/ResolvePossiblyCachedConstantInPoolTest.java ! test/compiler/jvmci/compilerToVM/ResolveTypeInPoolTest.java From alex.buckley at oracle.com Tue Mar 15 20:14:34 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 15 Mar 2016 13:14:34 -0700 Subject: "Provides" and "with" type relationships In-Reply-To: References: <56E861D7.4070005@oracle.com> Message-ID: <56E86D2A.1010202@oracle.com> A 'provides' clause specifies two things: a service interface and a service implementation. Using those terms helps to avoid confusion. A service interface does not have to be an interface; it can be an abstract class or even (not recommended) a concrete class. A service implementation must not be an interface, or an abstract class; it must be a concrete class. Therefore, it's not OK if the same type is specified as both service interface and service implementation, and JCK will be writing tests for that, I promise. Alex On 3/15/2016 12:39 PM, Paul Benedict wrote: > Thanks for your response Alex. If I am understanding you correctly, > "provides" is "not constrained to be an interface" because it can be "a > single interface or abstract class". So shouldn't my concrete class for > "provides" be rejected by the compiler? And is it okay that both types > were identical? > > Cheers, > Paul > > On Tue, Mar 15, 2016 at 2:26 PM, Alex Buckley > wrote: > > The first operand to 'provides' (the "service interface") is not > constrained to be an interface by "Modules in the Java Language and > JVM". This is because the spec of j.u.ServiceLoader ("a service is > represented by a single type, that is, a single interface or > abstract class"). > > The second operand to 'provides' (the "service implementation") is > constrained not to be an interface or an abstract class by "Modules > in the Java Language and JVM". This is also because of the spec of > j.u.ServiceLoader ("provider classes must have a zero-argument > constructor so that they can be instantiated during loading"). > > Bear in mind that the JCK team can easily set up abstract test cases > like this. What they can't do is check whether YOUR application runs > on JDK-9-with-Jigsaw, or whether arbitrary JARs on YOUR classpath > work as automatic modules. > > Alex > > > On 3/15/2016 12:07 PM, Paul Benedict wrote: > > module z { > exports z; > provides z.Main with z.Main; > } > > The SOTM says "Service-provider declarations can be further > interpreted to > ensure that providers (e.g., com.mysql.jdbc.Driver) actually do > implement > their declared service interfaces" (section 4, para. 8). > > I see javac checking that they are related types, but javac is > not checking > that "provides" is an interface type. That is what I was > expecting based on > the reading material. > > The other unexpected outcome was that provides/with allows the > identical > type. I don't know if that's intended, but please advise. > > PS: I did go through the open tickets this time (thanks Alan) > and do not > see any similar reports. If I missed it, I apologize; just > trying not to > waste your time by reporting a duplicate. > > Cheers, > Paul > > From alex.buckley at oracle.com Tue Mar 15 20:19:22 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 15 Mar 2016 13:19:22 -0700 Subject: "Provides" and "with" type relationships In-Reply-To: References: <56E861D7.4070005@oracle.com> Message-ID: <56E86E4A.3020505@oracle.com> // Ignore last mail (mail client did a surprising thing) A 'provides' clause specifies two things: a service interface and a service implementation. Using those terms helps to avoid confusion. A service interface does not have to be an interface; it can be an abstract class or even (not recommended) a concrete class. A service implementation must not be an interface, or an abstract class; it must be a concrete class. Therefore, it's legal (but not recommended) for a concrete class to be specified as both service interface and service implementation. It's illegal for an interface (or abstract class) to be specified as both service interface and service implementation. JCK will be writing tests for edge cases like this. Alex On 3/15/2016 12:39 PM, Paul Benedict wrote: > Thanks for your response Alex. If I am understanding you correctly, > "provides" is "not constrained to be an interface" because it can be "a > single interface or abstract class". So shouldn't my concrete class for > "provides" be rejected by the compiler? And is it okay that both types > were identical? > > Cheers, > Paul > > On Tue, Mar 15, 2016 at 2:26 PM, Alex Buckley > wrote: > > The first operand to 'provides' (the "service interface") is not > constrained to be an interface by "Modules in the Java Language and > JVM". This is because the spec of j.u.ServiceLoader ("a service is > represented by a single type, that is, a single interface or > abstract class"). > > The second operand to 'provides' (the "service implementation") is > constrained not to be an interface or an abstract class by "Modules > in the Java Language and JVM". This is also because of the spec of > j.u.ServiceLoader ("provider classes must have a zero-argument > constructor so that they can be instantiated during loading"). > > Bear in mind that the JCK team can easily set up abstract test cases > like this. What they can't do is check whether YOUR application runs > on JDK-9-with-Jigsaw, or whether arbitrary JARs on YOUR classpath > work as automatic modules. > > Alex > > > On 3/15/2016 12:07 PM, Paul Benedict wrote: > > module z { > exports z; > provides z.Main with z.Main; > } > > The SOTM says "Service-provider declarations can be further > interpreted to > ensure that providers (e.g., com.mysql.jdbc.Driver) actually do > implement > their declared service interfaces" (section 4, para. 8). > > I see javac checking that they are related types, but javac is > not checking > that "provides" is an interface type. That is what I was > expecting based on > the reading material. > > The other unexpected outcome was that provides/with allows the > identical > type. I don't know if that's intended, but please advise. > > PS: I did go through the open tickets this time (thanks Alan) > and do not > see any similar reports. If I missed it, I apologize; just > trying not to > waste your time by reporting a duplicate. > > Cheers, > Paul > > From chris.hegarty at oracle.com Tue Mar 15 20:21:22 2016 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 15 Mar 2016 20:21:22 +0000 Subject: hg: jigsaw/jake/jdk: jmod code review comments. Message-ID: <201603152021.u2FKLM0Z024342@aojmv0008.oracle.com> Changeset: 7e5d2398a250 Author: chegar Date: 2016-03-15 20:20 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7e5d2398a250 jmod code review comments. 1) format describe output similar to -listmods 2) always remove .tmp file 3) disallow classes in the unnamed package 4) remove unused message resources ! src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java ! src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod.properties ! test/tools/jlink/JLinkNegativeTest.java ! test/tools/jmod/JmodTest.java From chris.hegarty at oracle.com Tue Mar 15 20:27:36 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 15 Mar 2016 20:27:36 +0000 Subject: Initial webrev with changes for JDK 9 In-Reply-To: <45A05D29-1062-437A-9DE3-CCE14599352A@oracle.com> References: <56E29267.7070501@oracle.com> <45A05D29-1062-437A-9DE3-CCE14599352A@oracle.com> Message-ID: Mandy, On 14 Mar 2016, at 20:37, Mandy Chung wrote: > >> On Mar 11, 2016, at 1:39 AM, Alan Bateman wrote: >> >> >> I've refreshed the webrevs here: >> http://cr.openjdk.java.net/~alanb/8142968/2 > > > I have reviewed the jmod tool and some comments: > > 299 private boolean printModuleDescriptor(InputStream in) > > jmod -p option prints the output in different sections. > java -listmods: prints the module descriptor closer to > module-info.java declaration. Also jmod -p does not do any > sorting and names are unordered. > > It would be better for both options to use similar format. I think > closer to how it is declared in module-info.java would be preferred. > The optional attributes will follow it - the existing format is fine. Good idea. I updated the output as close as possible, where applicable, to -listmods:. > It?d help if the package names and uses are printed in alphabetical order. > > 584 } catch (ZipException x) { > 585 // Skip. Do nothing. No packages will be added > > When ZipException is thrown? Should it be handled in the same way as IOException? I do remember adding this explicit catch. I?m reluctant to remove it until I can find my notes, as to why it was added. I?ll have to get back to you on this. > 603 .filter(pkg -> pkg.length() > 0) // module-info > > I think jmod should detect if there is any unnamed package and output an error since unnamed package is not allowed in named module. Currently any classes in unnamed package are include in the jmod file. Classes in the unnamed package are now disallowed. > findPackages should filter module-info.class explicitly. > > 396 Path tempTarget = target.resolveSibling(target.getFileName() + ".tmp?); > > When any error occurs, foo.mod.tmp is left behind. Fixed. > jmods.properties - some unused messages. > > err.cp.must.be.specified:--class-path must be specified > err.dir.not.empty=not empty: {0} > err.invalid.arg.for.option=invalid argument for option: {0} > err.option.after.class=option must be specified before classes: {0} Removed. Changeset with the above updates: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7e5d2398a250 -Chris. From mandy.chung at oracle.com Tue Mar 15 21:45:38 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 15 Mar 2016 21:45:38 +0000 Subject: hg: jigsaw/jake: 2 new changesets Message-ID: <201603152145.u2FLjdk1026609@aojmv0008.oracle.com> Changeset: ea2ee1d57d22 Author: lana Date: 2016-03-15 13:48 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/ea2ee1d57d22 Added tag jdk-9+110 for changeset 925be13b3740 ! .hgtags Changeset: f1d1ac446fb2 Author: mchung Date: 2016-03-15 14:43 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/f1d1ac446fb2 Merge - make/CheckModules.gmk - make/GenerateModuleDeps.gmk - modules.xml From mandy.chung at oracle.com Tue Mar 15 21:45:46 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 15 Mar 2016 21:45:46 +0000 Subject: hg: jigsaw/jake/corba: 2 new changesets Message-ID: <201603152145.u2FLjkWp026793@aojmv0008.oracle.com> Changeset: c842d4efaf48 Author: lana Date: 2016-03-15 13:48 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/c842d4efaf48 Added tag jdk-9+110 for changeset 9666775734fb ! .hgtags Changeset: c7801b2f56a6 Author: mchung Date: 2016-03-15 14:43 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/c7801b2f56a6 Merge From mandy.chung at oracle.com Tue Mar 15 21:45:54 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 15 Mar 2016 21:45:54 +0000 Subject: hg: jigsaw/jake/hotspot: 2 new changesets Message-ID: <201603152145.u2FLjshn026981@aojmv0008.oracle.com> Changeset: 0de4d895a5c8 Author: lana Date: 2016-03-15 13:48 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0de4d895a5c8 Added tag jdk-9+110 for changeset 2f5d1578b240 ! .hgtags Changeset: 77095b95631f Author: mchung Date: 2016-03-15 14:43 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/77095b95631f Merge ! .hgtags - src/jdk.vm.ci/share/classes/META-INF/services/jdk.vm.ci.hotspot.HotSpotJVMCIBackendFactory - test/compiler/jsr292/NonInlinedCall/NonInlinedReinvoker.java - test/compiler/jvmci/common/CompilerToVMHelper.java - test/compiler/jvmci/common/PublicMetaspaceWrapperObject.java - test/compiler/jvmci/events/MetaAccessWrapper.java - test/runtime/BadObjectClass/Object.java - test/testlibrary/jdk/test/lib/PerfCounter.java - test/testlibrary/jdk/test/lib/PerfCounters.java From mandy.chung at oracle.com Tue Mar 15 21:46:09 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 15 Mar 2016 21:46:09 +0000 Subject: hg: jigsaw/jake/jaxp: 2 new changesets Message-ID: <201603152146.u2FLk9Uh027173@aojmv0008.oracle.com> Changeset: 5a94c67f40c8 Author: lana Date: 2016-03-15 13:48 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/5a94c67f40c8 Added tag jdk-9+110 for changeset 1c1bb661d35b ! .hgtags Changeset: 310469c55c5c Author: mchung Date: 2016-03-15 14:43 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/310469c55c5c Merge From mandy.chung at oracle.com Tue Mar 15 21:46:12 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 15 Mar 2016 21:46:12 +0000 Subject: hg: jigsaw/jake/jaxws: 2 new changesets Message-ID: <201603152146.u2FLkCPx027229@aojmv0008.oracle.com> Changeset: fb63c9b3af03 Author: lana Date: 2016-03-15 13:48 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/fb63c9b3af03 Added tag jdk-9+110 for changeset 0db939c930f3 ! .hgtags Changeset: 45d5f4ff89aa Author: mchung Date: 2016-03-15 14:43 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/45d5f4ff89aa Merge From mandy.chung at oracle.com Tue Mar 15 21:46:18 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 15 Mar 2016 21:46:18 +0000 Subject: hg: jigsaw/jake/jdk: 2 new changesets Message-ID: <201603152146.u2FLkIhE027391@aojmv0008.oracle.com> Changeset: edb95a70985f Author: lana Date: 2016-03-15 13:48 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/edb95a70985f Added tag jdk-9+110 for changeset 9417e1bcded6 ! .hgtags Changeset: 988c192cecc5 Author: mchung Date: 2016-03-15 14:43 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/988c192cecc5 Merge ! .hgtags - make/gendata/Gendata-jdk.jdeps.gmk - make/gensrc/Gensrc-jdk.dev.gmk - make/gensrc/Gensrc-jdk.jvmstat.gmk - make/launcher/Launcher-jdk.dev.gmk - make/scripts/localelist.sh - make/src/classes/build/tools/module/GenJdepsModulesXml.java - make/src/classes/build/tools/module/GenModulesList.java - make/src/classes/build/tools/module/ImageBuilder.java - make/src/classes/build/tools/module/ModuleArchive.java - make/src/classes/build/tools/module/boot.modules - make/src/classes/build/tools/module/ext.modules - src/java.base/share/classes/jdk/internal/jimage/Archive.java - src/java.base/share/classes/jdk/internal/jimage/BasicImageWriter.java - src/java.base/share/classes/jdk/internal/jimage/ExternalFilesWriter.java - src/java.base/share/classes/jdk/internal/jimage/ImageFileCreator.java - src/java.base/share/classes/jdk/internal/jimage/ImageJavaSubstrate.java - src/java.base/share/classes/jdk/internal/jimage/ImageLocationBase.java - src/java.base/share/classes/jdk/internal/jimage/ImageLocationWriter.java - src/java.base/share/classes/jdk/internal/jimage/ImageModuleData.java - src/java.base/share/classes/jdk/internal/jimage/ImageModuleDataWriter.java - src/java.base/share/classes/jdk/internal/jimage/ImageNativeSubstrate.java - src/java.base/share/classes/jdk/internal/jimage/ImageResourcesTree.java - src/java.base/share/classes/jdk/internal/jimage/ImageStringsWriter.java - src/java.base/share/classes/jdk/internal/jimage/ImageSubstrate.java - src/java.base/share/classes/jdk/internal/jimage/PerfectHashBuilder.java - src/java.base/share/classes/jdk/internal/jimage/ResourcePool.java - src/java.base/share/classes/jdk/internal/jimage/ResourcePoolImpl.java - src/java.base/share/classes/jdk/internal/jimage/StringTable.java - src/java.base/share/classes/jdk/internal/jimage/UTF8String.java - src/java.base/share/classes/sun/misc/Launcher.java - src/java.base/share/classes/sun/util/CoreResourceBundleControl-XLocales.java.template - src/java.base/share/native/libjava/Package.c - src/java.base/share/native/libjava/Proxy.c - src/java.base/share/native/libjimage/ImageNativeSubstrate.cpp - src/java.desktop/share/classes/META-INF/services/java.net.ContentHandlerFactory - src/java.desktop/share/classes/META-INF/services/javax.print.PrintServiceLookup - src/java.desktop/share/classes/META-INF/services/javax.print.StreamPrintServiceFactory - src/java.desktop/share/classes/META-INF/services/javax.sound.midi.spi.MidiDeviceProvider - src/java.desktop/share/classes/META-INF/services/javax.sound.midi.spi.MidiFileReader - src/java.desktop/share/classes/META-INF/services/javax.sound.midi.spi.MidiFileWriter - src/java.desktop/share/classes/META-INF/services/javax.sound.midi.spi.SoundbankReader - src/java.desktop/share/classes/META-INF/services/javax.sound.sampled.spi.AudioFileReader - src/java.desktop/share/classes/META-INF/services/javax.sound.sampled.spi.AudioFileWriter - src/java.desktop/share/classes/META-INF/services/javax.sound.sampled.spi.FormatConversionProvider - src/java.desktop/share/classes/META-INF/services/javax.sound.sampled.spi.MixerProvider - src/java.desktop/share/classes/META-INF/services/sun.datatransfer.DesktopDatatransferService - src/java.logging/share/classes/META-INF/services/jdk.internal.logger.DefaultLoggerFinder - src/java.security.jgss/share/classes/META-INF/services/sun.security.ssl.ClientKeyExchangeService - src/jdk.accessibility/windows/classes/META-INF/services/javax.accessibility.AccessibilityProvider - src/jdk.attach/share/classes/META-INF/services/com.sun.tools.attach.spi.AttachProvider - src/jdk.charsets/share/classes/META-INF/services/java.nio.charset.spi.CharsetProvider - src/jdk.dev/share/classes/jdk/tools/jimage/ExtractedImage.java - src/jdk.dev/share/classes/jdk/tools/jimage/JImageTask.java - src/jdk.dev/share/classes/jdk/tools/jimage/Main.java - src/jdk.dev/share/classes/jdk/tools/jimage/TaskHelper.java - src/jdk.dev/share/classes/jdk/tools/jimage/resources/jimage.properties - src/jdk.jdi/share/classes/META-INF/services/com.sun.jdi.connect.Connector - src/jdk.jdi/share/classes/META-INF/services/com.sun.jdi.connect.spi.TransportService - src/jdk.jvmstat.rmi/share/classes/META-INF/services/sun.jvmstat.monitor.MonitoredHostService - src/jdk.jvmstat/share/classes/META-INF/services/sun.jvmstat.monitor.MonitoredHostService - src/jdk.localedata/share/classes/META-INF/services/sun.util.locale.provider.LocaleDataMetaInfo - src/jdk.management/share/classes/META-INF/services/sun.management.spi.PlatformMBeanProvider - src/jdk.naming.dns/share/classes/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - src/jdk.zipfs/share/classes/META-INF/services/java.nio.file.spi.FileSystemProvider - test/java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.sh - test/java/net/DatagramSocket/SetDatagramSocketImplFactory/java/net/MyDatagramSocketImplFactory.java - test/java/net/httpclient/whitebox/TEST.properties - test/java/net/httpclient/whitebox/java/net/http/SelectorTest.java - test/java/util/stream/bootlib/TEST.properties - test/jdk/internal/jimage/ExecutableTest.java - test/jdk/internal/jimage/JImageTest.java - test/jdk/internal/jimage/VerifyJimage.java - test/sun/security/krb5/config/NamingManager.java - test/sun/security/krb5/config/dns.sh - test/sun/security/mscapi/IsSunMSCAPIAvailable.sh - test/sun/security/ssl/StatusStapling/BogusStatusRequest.java - test/sun/security/ssl/StatusStapling/CertStatusReqExtensionTests.java - test/sun/security/ssl/StatusStapling/CertStatusReqItemV2Tests.java - test/sun/security/ssl/StatusStapling/CertStatusReqListV2ExtensionTests.java - test/sun/security/ssl/StatusStapling/OCSPStatusRequestTests.java - test/sun/security/ssl/StatusStapling/StatusResponseManagerTests.java - test/sun/security/ssl/StatusStapling/TestCase.java - test/sun/security/ssl/StatusStapling/TestUtils.java From mandy.chung at oracle.com Tue Mar 15 21:46:29 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 15 Mar 2016 21:46:29 +0000 Subject: hg: jigsaw/jake/langtools: 2 new changesets Message-ID: <201603152146.u2FLkTDk027560@aojmv0008.oracle.com> Changeset: dbd1f626bd00 Author: lana Date: 2016-03-15 13:48 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/dbd1f626bd00 Added tag jdk-9+110 for changeset 9b4c916633f8 ! .hgtags Changeset: 8f70f503ce72 Author: mchung Date: 2016-03-15 14:43 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/8f70f503ce72 Merge ! .hgtags - src/jdk.compiler/share/classes/com/sun/tools/javac/sym/CreateSymbols.java - src/jdk.compiler/share/classes/com/sun/tools/javac/sym/Profiles.java - src/jdk.compiler/share/classes/com/sun/tools/javac/util/ServiceLoader.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/AbstractProfileIndexWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfileIndexFrameWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageFrameWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageIndexFrameWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageWriterImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfileWriterImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/ProfilePackageSummaryWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/ProfileSummaryWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ProfilePackageSummaryBuilder.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ProfileSummaryBuilder.java - src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModulesXmlReader.java - src/jdk.jdeps/share/classes/com/sun/tools/jdeps/PlatformClassPath.java - test/com/sun/javadoc/testLinkOption/java/lang/StringBuilderChild.java - test/com/sun/javadoc/testLinkOption/package-list - test/com/sun/javadoc/testProfiles/TestProfiles.java - test/com/sun/javadoc/testProfiles/TestProfilesConfiguration.java - test/com/sun/javadoc/testProfiles/pkg1/Class1Pkg1.java - test/com/sun/javadoc/testProfiles/pkg1/Class2Pkg1.java - test/com/sun/javadoc/testProfiles/pkg1/Class3Pkg1.java - test/com/sun/javadoc/testProfiles/pkg1/Interface1Pkg1.java - test/com/sun/javadoc/testProfiles/pkg2/Anno1Pkg2.java - test/com/sun/javadoc/testProfiles/pkg2/Anno2Pkg2.java - test/com/sun/javadoc/testProfiles/pkg2/Class1Pkg2.java - test/com/sun/javadoc/testProfiles/pkg2/ClassError.java - test/com/sun/javadoc/testProfiles/pkg2/ClassException.java - test/com/sun/javadoc/testProfiles/pkg3/Class1Pkg3.java - test/com/sun/javadoc/testProfiles/pkg3/Class2Pkg3.java - test/com/sun/javadoc/testProfiles/pkg3/Interface1Pkg3.java - test/com/sun/javadoc/testProfiles/pkg4/Anno1Pkg4.java - test/com/sun/javadoc/testProfiles/pkg4/Class1Pkg4.java - test/com/sun/javadoc/testProfiles/pkg5/Class1Pkg5.java - test/com/sun/javadoc/testProfiles/pkg5/Interface1Pkg5.java - test/com/sun/javadoc/testProfiles/pkgDeprecated/Class1PkgDeprecated.java - test/com/sun/javadoc/testProfiles/pkgDeprecated/package-info.java - test/com/sun/javadoc/testProfiles/profile-rtjar-includes-nopkgs.txt - test/com/sun/javadoc/testProfiles/profile-rtjar-includes.txt - test/jdk/javadoc/doclet/testLinkOption/java/lang/StringBuilderChild.java - test/jdk/javadoc/doclet/testLinkOption/package-list - test/tools/javac/Object1.java - test/tools/javac/Object1.out - test/tools/javac/Object2.java - test/tools/javac/Object2.out - test/tools/javac/profiles/ProfileTest.java - test/tools/javac/proprietary/WarnClass.java - test/tools/javac/proprietary/WarnClass.out - test/tools/javac/proprietary/WarnImport.java - test/tools/javac/proprietary/WarnImport.out - test/tools/javac/proprietary/WarnMethod.java - test/tools/javac/proprietary/WarnMethod.out - test/tools/javac/proprietary/WarnStaticImport.java - test/tools/javac/proprietary/WarnStaticImport.out - test/tools/javac/proprietary/WarnVariable.java - test/tools/javac/proprietary/WarnVariable.out - test/tools/javac/proprietary/WarnWildcard.java - test/tools/javac/proprietary/WarnWildcard.out - test/tools/javac/synthesize/Boolean.java - test/tools/javac/synthesize/Byte.java - test/tools/javac/synthesize/Character.java - test/tools/javac/synthesize/Cloneable.java - test/tools/javac/synthesize/Double.java - test/tools/javac/synthesize/Float.java - test/tools/javac/synthesize/Integer.java - test/tools/javac/synthesize/Long.java - test/tools/javac/synthesize/Number.java - test/tools/javac/synthesize/Object.java - test/tools/javac/synthesize/Serializable.java - test/tools/javac/synthesize/Short.java - test/tools/javac/synthesize/Test.java - test/tools/javac/synthesize/Void.java - test/tools/jdeps/VerboseFormat/use/indirect/DontUseUnsafe2.java - test/tools/jdeps/VerboseFormat/use/indirect/UseUnsafeIndirectly.java - test/tools/jdeps/VerboseFormat/use/indirect2/DontUseUnsafe3.java - test/tools/jdeps/VerboseFormat/use/indirect2/UseUnsafeIndirectly2.java - test/tools/jdeps/VerboseFormat/use/unsafe/DontUseUnsafe.java - test/tools/jdeps/VerboseFormat/use/unsafe/UseClassWithUnsafe.java - test/tools/jdeps/VerboseFormat/use/unsafe/UseUnsafeClass.java - test/tools/jdeps/VerboseFormat/use/unsafe/UseUnsafeClass2.java - test/tools/jdeps/javax/activity/NotCompactProfile.java From mandy.chung at oracle.com Tue Mar 15 21:46:33 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 15 Mar 2016 21:46:33 +0000 Subject: hg: jigsaw/jake/nashorn: 2 new changesets Message-ID: <201603152146.u2FLkXSl027740@aojmv0008.oracle.com> Changeset: f64433f6ff69 Author: lana Date: 2016-03-15 13:48 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/f64433f6ff69 Added tag jdk-9+110 for changeset 9937077e48f1 ! .hgtags Changeset: ea5605f73921 Author: mchung Date: 2016-03-15 14:44 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/ea5605f73921 Merge ! .hgtags - src/jdk.scripting.nashorn/share/classes/META-INF/MANIFEST.MF - src/jdk.scripting.nashorn/share/classes/META-INF/services/javax.script.ScriptEngineFactory From jonathan.gibbons at oracle.com Tue Mar 15 23:17:45 2016 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 15 Mar 2016 23:17:45 +0000 Subject: hg: jigsaw/jake/langtools: move problem tests to main ProblemList.txt Message-ID: <201603152317.u2FNHj7X007687@aojmv0008.oracle.com> Changeset: 34fbc157727e Author: jjg Date: 2016-03-15 16:17 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/34fbc157727e move problem tests to main ProblemList.txt - test/ProblemList.jake.txt ! test/ProblemList.txt ! test/tools/javac/diags/examples.not-yet.txt From lois.foltan at oracle.com Tue Mar 15 23:45:00 2016 From: lois.foltan at oracle.com (lois.foltan at oracle.com) Date: Tue, 15 Mar 2016 23:45:00 +0000 Subject: hg: jigsaw/jake/hotspot: 8151908: Fix remaining extension class loader references in AppCDS code Message-ID: <201603152345.u2FNj0g5017457@aojmv0008.oracle.com> Changeset: 5420f2f73383 Author: jiangli Date: 2016-03-15 13:40 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5420f2f73383 8151908: Fix remaining extension class loader references in AppCDS code Summary: Fix extension classloader references in AppCDS code and comments. Reviewed-by: mchung ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoader.hpp ! src/share/vm/oops/instanceKlass.hpp From jonathan.gibbons at oracle.com Wed Mar 16 01:42:37 2016 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 16 Mar 2016 01:42:37 +0000 Subject: hg: jigsaw/jake/langtools: cleanup diags examples Message-ID: <201603160142.u2G1gbNX004825@aojmv0008.oracle.com> Changeset: e743f91c2e24 Author: jjg Date: 2016-03-15 18:42 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/e743f91c2e24 cleanup diags examples ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java ! test/ProblemList.txt ! test/tools/javac/diags/Example.java ! test/tools/javac/diags/examples/DirPathElementNotFound.java ! test/tools/javac/diags/examples/InvalidDefaultInterface/InvalidDefaultInterface.java ! test/tools/javac/diags/examples/InvalidStaticInterface/InvalidStaticInterface.java ! test/tools/javac/diags/examples/NoJavaLang.java ! test/tools/javac/diags/examples/NoSuperclass.java From mandy.chung at oracle.com Wed Mar 16 03:32:04 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 16 Mar 2016 03:32:04 +0000 Subject: hg: jigsaw/jake/langtools: Cleanup after ProblemList.jake.txt removal Message-ID: <201603160332.u2G3W4uO018498@aojmv0008.oracle.com> Changeset: d8475d27a07c Author: mchung Date: 2016-03-15 20:32 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/d8475d27a07c Cleanup after ProblemList.jake.txt removal ! make/build.xml ! test/Makefile From mandy.chung at oracle.com Wed Mar 16 03:37:46 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 16 Mar 2016 03:37:46 +0000 Subject: hg: jigsaw/jake/langtools: 2 new changesets Message-ID: <201603160337.u2G3bkb1020205@aojmv0008.oracle.com> Changeset: 9d07ca03b896 Author: mchung Date: 2016-03-15 20:37 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/9d07ca03b896 print output in sorted order ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleAnalyzer.java Changeset: 85a52d56ec3c Author: mchung Date: 2016-03-15 20:37 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/85a52d56ec3c review comment from dfuchs ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Analyzer.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Archive.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsTask.java From mandy.chung at oracle.com Wed Mar 16 03:42:09 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 15 Mar 2016 20:42:09 -0700 Subject: Initial webrev with changes for JDK 9 In-Reply-To: <56E84AF9.709@oracle.com> References: <56E29267.7070501@oracle.com> <56E84AF9.709@oracle.com> Message-ID: <0D1DDEAC-C50B-4DD5-B46D-D90C0A201C41@oracle.com> Daniel, Thanks for the review. > On Mar 15, 2016, at 10:48 AM, Daniel Fuchs wrote: > > > 120 @Override > 121 public int hashCode() { > 122 int hash = 7; > 123 hash = 67*hash + Objects.hashCode(this.filename) + > 124 Objects.hashCode(this.path); > 125 return hash; > 126 } > > I wonder if that could be simplified in: > > return Objects.hash(this.filename, this.path); > Good idea. I made the change. > > typo: > 443 // otherwise analyze the depednencies Fixed. Mandy From mandy.chung at oracle.com Wed Mar 16 03:58:11 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 16 Mar 2016 03:58:11 +0000 Subject: hg: jigsaw/jake/jdk: Fix javadoc warnings Message-ID: <201603160358.u2G3wBN3026420@aojmv0008.oracle.com> Changeset: 43aa40114786 Author: mchung Date: 2016-03-15 20:58 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/43aa40114786 Fix javadoc warnings ! src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/Pool.java From bhavesh.x.patel at oracle.com Wed Mar 16 05:56:10 2016 From: bhavesh.x.patel at oracle.com (Bhavesh Patel) Date: Tue, 15 Mar 2016 22:56:10 -0700 Subject: Initial webrev with changes for JDK 9 In-Reply-To: <56DEF447.4000309@oracle.com> References: <56D84C7D.9020006@oracle.com> <56DEF447.4000309@oracle.com> Message-ID: <56E8F57A.5040505@oracle.com> Hi, I have review the javadoc (including doclet and tests) changes. It mostly looks good. Following are my comments on the changes 1) jdk/javadoc/internal/doclets/formats/html/ConfigurationImpl.java - (Line 522) PackageSymbol "pd" is cast to ModuleSymbol which is incorrect. 2) jdk/javadoc/internal/doclets/toolkit/AbstractDoclet.java - (Lines 109 and 111) e.printStackTrace() needs to be deleted. 3) jdk/javadoc/internal/doclets/formats/html/PackageWriterImpl.java - (Lines 130 - 135) The Module label and name gets enclosed in

. We need to update this to enclose them in a

and similar to what we do in jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java (Lines 200 - 205). Other minor changes that are needed are as follows 4) com/sun/tools/doclets/formats/html/PackageWriterImpl.java - The class lists no changes other than the copyright year change. If no changes have happened, the copyright year change needs to be reverted. 5) com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java - (Line 275) Missing @param. - (Line 292) Missing documentation. 6) com/sun/tools/doclets/internal/toolkit/util/DocFileFactory.java - Copyright year shows 2012 instead of 2016. 7) com/sun/tools/javadoc/DocletInvoker.java - (Line 367) Missing @param. - (Line 384) Missing documentation. 8) jdk/javadoc/internal/doclets/formats/html/WriterFactoryImpl.java - (Lines 94 - 102) needs to be deleted. 9) jdk/javadoc/internal/doclets/toolkit/AbstractDoclet.java - Line 121 needs to be deleted 10) jdk/javadoc/internal/doclets/toolkit/Configuration.java - Extra line 398 needs to be deleted. - (Line 654) Not updated as a part of this fix but @return needs to be updated. 11) jdk/javadoc/internal/doclets/toolkit/WriterFactory.java - (Line 74) The param name should be "mdle" instead of "module" 12) jdk/javadoc/internal/doclets/toolkit/builders/BuilderFactory.java - (Line 108) The param name should be "mdle" instead of "module" 13) jdk/javadoc/internal/doclets/toolkit/taglets/TagletManager.java - (Line 266) Missing @param. - (Line 285) Missing documentation. 14) jdk/javadoc/internal/doclets/toolkit/util/DocPaths.java - (Line 158) should be "The name of the file for the module overview frame." 15) jdk/javadoc/internal/tool/Start.java - (Line 313) Missing @param. 16) jdk/javadoc/internal/doclets/toolkit/builders/ModuleSummaryBuilder.java - (Line 80) "module" should be "mdle". - (Line 95) "module" should be "mdle". Regards, Bhavesh. From Alan.Bateman at oracle.com Wed Mar 16 08:30:03 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 16 Mar 2016 08:30:03 +0000 Subject: Initial webrev with changes for JDK 9 In-Reply-To: <56D84C7D.9020006@oracle.com> References: <56D84C7D.9020006@oracle.com> Message-ID: <56E9198B.6080105@oracle.com> I've refreshed the webrevs here: http://cr.openjdk.java.net/~alanb/8142968/3 so that we have an up to date snapshot of what is currently in the jigsaw/jake forest. The webrevs are against jdk-9+110. Thank you to the many people that have been helping with the review and addressing comments/issues quickly. Overall, I think we are converging to the bits that we will push to jdk9/jdk9. As expected, there are a few issues where some re-work is needed and those issues will be tracked in JIRA to avoid destabilizing things now. So at this point then I think we are on track to integrate into JDK 9 next week for jdk-9+111. If something serious comes up then we might have to change that plan and go for the week after that, I hope not. I sent a note to jdk9-dev last week [1] so that the wider project knows what is coming. I will send another note later in the week once confidence is higher about next week. In terms of logistics then we have created jigsaw/m3 as a staging forest. We used jigsaw/m1 to stage JEP 201 and jigsaw/m2 to stage JEP 220 so this is a similar deal except jigsaw/m3 has jcheck configured to only accept change-sets that can be pushed to JDK 9. There will be activity in this new staging forest for the next few weeks, the notifications go to this mailing list so apologies for the spam. -Alan. [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-March/003877.html From harold.seigel at oracle.com Wed Mar 16 12:09:25 2016 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Wed, 16 Mar 2016 12:09:25 +0000 Subject: hg: jigsaw/jake/hotspot: Fix slowdebug build issues Message-ID: <201603161209.u2GC9PZs012451@aojmv0008.oracle.com> Changeset: 25a32e104032 Author: iklam Date: 2016-03-16 07:41 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/25a32e104032 Fix slowdebug build issues ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/whitebox.cpp From alan.bateman at oracle.com Wed Mar 16 12:59:44 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 16 Mar 2016 12:59:44 +0000 Subject: hg: jigsaw/jake/jdk: 2 new changesets Message-ID: <201603161259.u2GCxiiL001859@aojmv0008.oracle.com> Changeset: d52918ec556e Author: alanb Date: 2016-03-16 12:56 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d52918ec556e Update JDI based on comments ! src/jdk.jdi/share/classes/com/sun/jdi/InvalidModuleException.java ! src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java Changeset: cd4af7af77ab Author: simonis Date: 2016-03-16 13:12 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/cd4af7af77ab 8151987: jexec should be executable ! src/jdk.jlink/share/classes/jdk/tools/jlink/builder/DefaultImageBuilder.java From sundararajan.athijegannathan at oracle.com Wed Mar 16 14:27:21 2016 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Wed, 16 Mar 2016 14:27:21 +0000 Subject: hg: jigsaw/jake/jdk: 8150195: tools/jimage/JImageTest.java fails with AccessDeniedException Message-ID: <201603161427.u2GERLc4008119@aojmv0008.oracle.com> Changeset: f99cbeea7056 Author: sundar Date: 2016-03-16 19:57 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f99cbeea7056 8150195: tools/jimage/JImageTest.java fails with AccessDeniedException Reviewed-by: jlaskey ! src/jdk.jlink/share/classes/jdk/tools/jimage/JImageTask.java From konstantin.barzilovich at oracle.com Wed Mar 16 17:24:31 2016 From: konstantin.barzilovich at oracle.com (Konstantin Barzilovich) Date: Wed, 16 Mar 2016 20:24:31 +0300 Subject: "Provides" and "with" type relationships In-Reply-To: <56E86E4A.3020505@oracle.com> References: <56E861D7.4070005@oracle.com> <56E86E4A.3020505@oracle.com> Message-ID: Sorry, if this question was asked before. Does service implementation need to inherit service interface? Thanks, Konstantin. > // Ignore last mail (mail client did a surprising thing) > > A 'provides' clause specifies two things: a service interface and a > service implementation. Using those terms helps to avoid confusion. > > A service interface does not have to be an interface; it can be an > abstract class or even (not recommended) a concrete class. > > A service implementation must not be an interface, or an abstract class; > it must be a concrete class. > > Therefore, it's legal (but not recommended) for a concrete class to be > specified as both service interface and service implementation. It's > illegal for an interface (or abstract class) to be specified as both > service interface and service implementation. JCK will be writing tests > for edge cases like this. > > Alex > > On 3/15/2016 12:39 PM, Paul Benedict wrote: >> Thanks for your response Alex. If I am understanding you correctly, >> "provides" is "not constrained to be an interface" because it can be "a >> single interface or abstract class". So shouldn't my concrete class for >> "provides" be rejected by the compiler? And is it okay that both types >> were identical? >> >> Cheers, >> Paul >> >> On Tue, Mar 15, 2016 at 2:26 PM, Alex Buckley > > wrote: >> >> The first operand to 'provides' (the "service interface") is not >> constrained to be an interface by "Modules in the Java Language and >> JVM". This is because the spec of j.u.ServiceLoader ("a service is >> represented by a single type, that is, a single interface or >> abstract class"). >> >> The second operand to 'provides' (the "service implementation") is >> constrained not to be an interface or an abstract class by "Modules >> in the Java Language and JVM". This is also because of the spec of >> j.u.ServiceLoader ("provider classes must have a zero-argument >> constructor so that they can be instantiated during loading"). >> >> Bear in mind that the JCK team can easily set up abstract test cases >> like this. What they can't do is check whether YOUR application runs >> on JDK-9-with-Jigsaw, or whether arbitrary JARs on YOUR classpath >> work as automatic modules. >> >> Alex >> >> >> On 3/15/2016 12:07 PM, Paul Benedict wrote: >> >> module z { >> exports z; >> provides z.Main with z.Main; >> } >> >> The SOTM says "Service-provider declarations can be further >> interpreted to >> ensure that providers (e.g., com.mysql.jdbc.Driver) actually do >> implement >> their declared service interfaces" (section 4, para. 8). >> >> I see javac checking that they are related types, but javac is >> not checking >> that "provides" is an interface type. That is what I was >> expecting based on >> the reading material. >> >> The other unexpected outcome was that provides/with allows the >> identical >> type. I don't know if that's intended, but please advise. >> >> PS: I did go through the open tickets this time (thanks Alan) >> and do not >> see any similar reports. If I missed it, I apologize; just >> trying not to >> waste your time by reporting a duplicate. >> >> Cheers, >> Paul >> >> -- Thanks, Konstantin. From mandy.chung at oracle.com Wed Mar 16 17:28:29 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 16 Mar 2016 17:28:29 +0000 Subject: hg: jigsaw/jake/jdk: ProblemList JImageTest.java on 32-bit build only Message-ID: <201603161728.u2GHSTWW024436@aojmv0008.oracle.com> Changeset: d2d136698413 Author: mchung Date: 2016-03-16 10:22 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d2d136698413 ProblemList JImageTest.java on 32-bit build only ! test/ProblemList.txt From peter.levart at gmail.com Wed Mar 16 17:30:13 2016 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 16 Mar 2016 18:30:13 +0100 Subject: Initial webrev with changes for JDK 9 In-Reply-To: <56E9198B.6080105@oracle.com> References: <56D84C7D.9020006@oracle.com> <56E9198B.6080105@oracle.com> Message-ID: <56E99825.3050704@gmail.com> Hi Alan, Just one nit. On 03/16/2016 09:30 AM, Alan Bateman wrote: > > I've refreshed the webrevs here: > http://cr.openjdk.java.net/~alanb/8142968/3 > In java.lang.ClassLoader: ...the package-private definePackage(String name, Module m) is OK to use a single packages.compute(...) call performance-wise since it is pre-screened with packages.get() in public getDefinedPackage(String name) method. But there's also a package-private packages() method (a basis for public methods getPackages() and getDefinedPackages()) that constructs a Stream of defined Packages which unnecessarily calls definePackage() for each value of packages map: Stream packages() { return packages.values().stream() .map(p -> definePackage(p.packageName(), p.module())); } It would be nice performance-wise to avoid calling definePackage if the value is already a Package: Stream packages() { return packages.values().stream() .map(p -> p instanceof Package ? (Package) p : definePackage(p.packageName(), p.module())); } Regards, Peter From mandy.chung at oracle.com Wed Mar 16 18:00:44 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 16 Mar 2016 18:00:44 +0000 Subject: hg: jigsaw/jake/jdk: jdk.jsobject uses is missing and incorrect copyright start year Message-ID: <201603161800.u2GI0iQH011756@aojmv0008.oracle.com> Changeset: 7adf3d3cd01e Author: mchung Date: 2016-03-16 11:00 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7adf3d3cd01e jdk.jsobject uses is missing and incorrect copyright start year ! src/jdk.jsobject/share/classes/module-info.java From jonathan.gibbons at oracle.com Wed Mar 16 18:30:55 2016 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 16 Mar 2016 18:30:55 +0000 Subject: hg: jigsaw/jake/langtools: Address review feedback Message-ID: <201603161830.u2GIUuio023166@aojmv0008.oracle.com> Changeset: f6d069e0b7e3 Author: jjg Date: 2016-03-16 11:30 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/f6d069e0b7e3 Address review feedback ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFileFactory.java ! src/jdk.javadoc/share/classes/com/sun/tools/javadoc/DocletInvoker.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConfigurationImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/WriterFactoryImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/AbstractDoclet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/Configuration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/WriterFactory.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/BuilderFactory.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ModuleSummaryBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletManager.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocPaths.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java From mandy.chung at oracle.com Wed Mar 16 18:50:43 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 16 Mar 2016 11:50:43 -0700 Subject: Initial webrev with changes for JDK 9 In-Reply-To: <56E8148D.4090202@gmail.com> References: <56E29267.7070501@oracle.com> <57D437E7-2EC8-45DB-85C0-3ECA3047AA8C@oracle.com> <56E8148D.4090202@gmail.com> Message-ID: Hi Peter, Thanks for the review feedback. > > NamedPackage p = packages.get(name); > if (p instanceof Package) { > return (Package) p; > } > > return (Package)packages.compute((n, p) -> { > // define Package object if it is not yet defined or replace it if it is a NamedPackage > return (p instanceof Package) ? p : NamedPackage.toPackage(n, m); > }); > > See, no private ClassLoader.toPackage(String name, NamedPackage p) needed. > I like this suggestion that allows me to remove this private method. I have this patch: http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/jigsaw-m3/webrev-03-16/ One thing to note is that I don?t view definePackage returning Package object is performance critical. java.lang.Package is legacy and from my scan of its usage, it's mainly used for getting the package name. The versioning info is more for tracing/debugging use. Package objects has not been defined for every packages. Not to mention its assumption on class loader hierarchy and packages are not splitted among JAR files. In jake, Alex and I rewrote the java.lang.Package class spec. Also fixed several design issue of Package. I?d recommend any use of Class.getPackage().getName() be replaced with Class::getPackageName which is more performant if performance is important to them. Package annotation (package-info) is the main useful info to be obtained from Package object. Otherwise I am not aware anything in Package class needed to be performant. > > If you also care for constant lambda, this could be optimized even further, but for the price of more complex code: Simple clean code as above is good for this case. > On Mar 16, 2016, at 10:30 AM, Peter Levart wrote: > > In java.lang.ClassLoader: > > ...the package-private definePackage(String name, Module m) is OK to use a single packages.compute(...) call performance-wise since it is pre-screened with packages.get() in public getDefinedPackage(String name) method. But there's also a package-private packages() method (a basis for public methods getPackages() and getDefinedPackages()) that constructs a Stream of defined Packages which unnecessarily calls definePackage() for each value of packages map: > > Stream packages() { > return packages.values().stream() > .map(p -> definePackage(p.packageName(), p.module())); > } > > > It would be nice performance-wise to avoid calling definePackage if the value is already a Package: > > Stream packages() { > return packages.values().stream() > .map(p -> p instanceof Package > ? (Package) p > : definePackage(p.packageName(), p.module())); > } > As explained above, getting a Package object is not performance critical. I?ll keep this in mind for other performance critical code. thanks Mandy From alex.buckley at oracle.com Wed Mar 16 19:15:31 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 16 Mar 2016 12:15:31 -0700 Subject: "Provides" and "with" type relationships In-Reply-To: References: <56E861D7.4070005@oracle.com> <56E86E4A.3020505@oracle.com> Message-ID: <56E9B0D3.7000601@oracle.com> Yes. 'uses' and 'provides' are nothing more than static declarations that configure java.util.ServiceLoader, so all questions can be resolved by looking at the ServiceLoader spec: http://download.java.net/java/jigsaw/docs/api/java/util/ServiceLoader.html Alex On 3/16/2016 10:24 AM, Konstantin Barzilovich wrote: > Sorry, if this question was asked before. > Does service implementation need to inherit service interface? > > Thanks, > Konstantin. > >> // Ignore last mail (mail client did a surprising thing) >> >> A 'provides' clause specifies two things: a service interface and a >> service implementation. Using those terms helps to avoid confusion. >> >> A service interface does not have to be an interface; it can be an >> abstract class or even (not recommended) a concrete class. >> >> A service implementation must not be an interface, or an abstract >> class; it must be a concrete class. >> >> Therefore, it's legal (but not recommended) for a concrete class to be >> specified as both service interface and service implementation. It's >> illegal for an interface (or abstract class) to be specified as both >> service interface and service implementation. JCK will be writing >> tests for edge cases like this. >> >> Alex >> >> On 3/15/2016 12:39 PM, Paul Benedict wrote: >>> Thanks for your response Alex. If I am understanding you correctly, >>> "provides" is "not constrained to be an interface" because it can be "a >>> single interface or abstract class". So shouldn't my concrete class for >>> "provides" be rejected by the compiler? And is it okay that both types >>> were identical? >>> >>> Cheers, >>> Paul >>> >>> On Tue, Mar 15, 2016 at 2:26 PM, Alex Buckley >> > wrote: >>> >>> The first operand to 'provides' (the "service interface") is not >>> constrained to be an interface by "Modules in the Java Language and >>> JVM". This is because the spec of j.u.ServiceLoader ("a service is >>> represented by a single type, that is, a single interface or >>> abstract class"). >>> >>> The second operand to 'provides' (the "service implementation") is >>> constrained not to be an interface or an abstract class by "Modules >>> in the Java Language and JVM". This is also because of the spec of >>> j.u.ServiceLoader ("provider classes must have a zero-argument >>> constructor so that they can be instantiated during loading"). >>> >>> Bear in mind that the JCK team can easily set up abstract test cases >>> like this. What they can't do is check whether YOUR application runs >>> on JDK-9-with-Jigsaw, or whether arbitrary JARs on YOUR classpath >>> work as automatic modules. >>> >>> Alex >>> >>> >>> On 3/15/2016 12:07 PM, Paul Benedict wrote: >>> >>> module z { >>> exports z; >>> provides z.Main with z.Main; >>> } >>> >>> The SOTM says "Service-provider declarations can be further >>> interpreted to >>> ensure that providers (e.g., com.mysql.jdbc.Driver) actually do >>> implement >>> their declared service interfaces" (section 4, para. 8). >>> >>> I see javac checking that they are related types, but javac is >>> not checking >>> that "provides" is an interface type. That is what I was >>> expecting based on >>> the reading material. >>> >>> The other unexpected outcome was that provides/with allows the >>> identical >>> type. I don't know if that's intended, but please advise. >>> >>> PS: I did go through the open tickets this time (thanks Alan) >>> and do not >>> see any similar reports. If I missed it, I apologize; just >>> trying not to >>> waste your time by reporting a duplicate. >>> >>> Cheers, >>> Paul >>> >>> > > From peter.levart at gmail.com Wed Mar 16 20:04:21 2016 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 16 Mar 2016 21:04:21 +0100 Subject: Initial webrev with changes for JDK 9 In-Reply-To: <56E9198B.6080105@oracle.com> References: <56D84C7D.9020006@oracle.com> <56E9198B.6080105@oracle.com> Message-ID: <56E9BC45.9090601@gmail.com> Hi Alan, On 03/16/2016 09:30 AM, Alan Bateman wrote: > I've refreshed the webrevs here: > http://cr.openjdk.java.net/~alanb/8142968/3 I have another optimization... In java.lang.reflect.Proxy, a package is added dynamically to the module the 1st time a proxy class is defined in that module. Each time new proxy class is defined, an array of module package names is compiled by concatenating two Streams, dumping them into array, wrapping it with an ArrayStream and searching for package if it is already defined: 583 // add the package to the runtime module if not exists 584 if (m.isNamed() && !Stream.of(m.getPackages()).anyMatch(proxyPkg::equals)) { 585 m.addPackage(proxyPkg); 586 } ... just to avoid calling Module.addPackage() in case the package is already defined in that module, although the Module.addPackage() is idempotent. Presumably to avoid synchronization? But if the module has lots of packages, then such linear search is expensive and produces garbage. Here's how this linear search and the synchronization in Module.addPackage() can be avoided: http://cr.openjdk.java.net/~plevart/jake/Proxy.addPackage.opt/webrev.01/ Regards, Peter From Alan.Bateman at oracle.com Wed Mar 16 20:13:52 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 16 Mar 2016 20:13:52 +0000 Subject: Initial webrev with changes for JDK 9 In-Reply-To: <56E9BC45.9090601@gmail.com> References: <56D84C7D.9020006@oracle.com> <56E9198B.6080105@oracle.com> <56E9BC45.9090601@gmail.com> Message-ID: <56E9BE80.2010701@oracle.com> On 16/03/2016 20:04, Peter Levart wrote: > : > > I have another optimization... > > In java.lang.reflect.Proxy, a package is added dynamically to the > module the 1st time a proxy class is defined in that module. Each time > new proxy class is defined, an array of module package names is > compiled by concatenating two Streams, dumping them into array, > wrapping it with an ArrayStream and searching for package if it is > already defined: > > 583 // add the package to the runtime module if not exists > 584 if (m.isNamed() && > !Stream.of(m.getPackages()).anyMatch(proxyPkg::equals)) { > 585 m.addPackage(proxyPkg); > 586 } > > ... just to avoid calling Module.addPackage() in case the package is > already defined in that module, although the Module.addPackage() is > idempotent. Presumably to avoid synchronization? But if the module has > lots of packages, then such linear search is expensive and produces > garbage. > > Here's how this linear search and the synchronization in > Module.addPackage() can be avoided: > > http://cr.openjdk.java.net/~plevart/jake/Proxy.addPackage.opt/webrev.01/ > Ugh, I haven't noticed that ProxyClassFactory defineProxyClass was doing a linear search, that's a consequence of getPackages() returning an array. So I think what you have make sense - thanks! -Alan From alan.bateman at oracle.com Wed Mar 16 20:17:40 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 16 Mar 2016 20:17:40 +0000 Subject: hg: jigsaw/jake/jdk: Fix typos and @see in javadoc Message-ID: <201603162017.u2GKHfgd004219@aojmv0008.oracle.com> Changeset: a6997d7ad4e6 Author: alanb Date: 2016-03-16 19:36 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a6997d7ad4e6 Fix typos and @see in javadoc ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java ! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java From christian.tornqvist at oracle.com Wed Mar 16 20:25:15 2016 From: christian.tornqvist at oracle.com (christian.tornqvist at oracle.com) Date: Wed, 16 Mar 2016 20:25:15 +0000 Subject: hg: jigsaw/jake/hotspot: 8151813: Quarantine BootAppendTests.java Message-ID: <201603162025.u2GKPF7O006382@aojmv0008.oracle.com> Changeset: 2795325cdef6 Author: ctornqvi Date: 2016-03-16 13:23 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2795325cdef6 8151813: Quarantine BootAppendTests.java ! test/runtime/SharedArchiveFile/BootAppendTests.java From mandy.chung at oracle.com Wed Mar 16 20:38:37 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 16 Mar 2016 13:38:37 -0700 Subject: Initial webrev with changes for JDK 9 In-Reply-To: <56E9BC45.9090601@gmail.com> References: <56D84C7D.9020006@oracle.com> <56E9198B.6080105@oracle.com> <56E9BC45.9090601@gmail.com> Message-ID: <004127D7-EB41-49D9-B23B-424AFDC104ED@oracle.com> > On Mar 16, 2016, at 1:04 PM, Peter Levart wrote: > > Hi Alan, > > On 03/16/2016 09:30 AM, Alan Bateman wrote: >> I've refreshed the webrevs here: >> http://cr.openjdk.java.net/~alanb/8142968/3 > > I have another optimization... > > In java.lang.reflect.Proxy, a package is added dynamically to the module the 1st time a proxy class is defined in that module. Each time new proxy class is defined, an array of module package names is compiled by concatenating two Streams, dumping them into array, wrapping it with an ArrayStream and searching for package if it is already defined: > > 583 // add the package to the runtime module if not exists > 584 if (m.isNamed() && !Stream.of(m.getPackages()).anyMatch(proxyPkg::equals)) { > 585 m.addPackage(proxyPkg); > 586 } > > ... just to avoid calling Module.addPackage() in case the package is already defined in that module, although the Module.addPackage() is idempotent. Presumably to avoid synchronization? But if the module has lots of packages, then such linear search is expensive and produces garbage. > > Here's how this linear search and the synchronization in Module.addPackage() can be avoided: > > http://cr.openjdk.java.net/~plevart/jake/Proxy.addPackage.opt/webrev.01/ I?ll sponsor this patch. Mandy From mark.reinhold at oracle.com Wed Mar 16 20:55:01 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 16 Mar 2016 13:55:01 -0700 Subject: modulepath and classpath mixture In-Reply-To: References: <56CBAD62.3010508@oracle.com> Message-ID: <20160316135501.530460938eggemoggin.niobe.net> 2016/2/27 3:25 -0800, rfscholte at apache.org: > I noticed[1] that -addmods already has a special option: ALL-SYSTEM > What I'm looking for is something like ALL-MP or ALL-MODULEPATH, which > simply exposes all modules on the modulepath to the classpath. The set of > moduleEntries on the modulePath are already chosen with care and are in > the end all required to be able to compile the test-classes without the > need of knowing the name of the module being used to compile with. We added a special ALL-MODULE-PATH token to the -addmods option, with this description now in JEP 261 (http://openjdk.java.net/jeps/261): As a further special case, if `` is `ALL-MODULE-PATH` then all observable modules found on module paths are added to the root set. `ALL-MODULE-PATH` is valid at compile time when compiling classes in the unnamed module, and at run time when the main class of the application is loaded from the class path into the unnamed module. This change is in Jigsaw EA build #4647 (https://jdk9.java.net/jigsaw/). Please try it out and let us know what you think. - Mark From mandy.chung at oracle.com Wed Mar 16 20:56:18 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 16 Mar 2016 20:56:18 +0000 Subject: hg: jigsaw/jake/jdk: Rename classes with "Installed" prefix to "System" consistent with ModuleFinder::ofSystem Message-ID: <201603162056.u2GKuIPK018669@aojmv0008.oracle.com> Changeset: 0d7ba0a49fe3 Author: mchung Date: 2016-03-16 13:56 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0d7ba0a49fe3 Rename classes with "Installed" prefix to "System" consistent with ModuleFinder::ofSystem - src/java.base/share/classes/java/lang/module/InstalledModuleFinder.java ! src/java.base/share/classes/java/lang/module/ModuleFinder.java + src/java.base/share/classes/java/lang/module/SystemModuleFinder.java ! src/java.base/share/classes/jdk/internal/module/Builder.java - src/java.base/share/classes/jdk/internal/module/InstalledModules.java + src/java.base/share/classes/jdk/internal/module/SystemModules.java - src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/InstalledModuleDescriptorPlugin.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModuleDescriptorPlugin.java ! src/jdk.jlink/share/classes/module-info.java From mandy.chung at oracle.com Wed Mar 16 21:03:53 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 16 Mar 2016 14:03:53 -0700 Subject: Initial webrev with changes for JDK 9 In-Reply-To: References: <56E29267.7070501@oracle.com> <57D437E7-2EC8-45DB-85C0-3ECA3047AA8C@oracle.com> <56E8148D.4090202@gmail.com> Message-ID: <4E48E13A-0790-43FF-97CB-F6DE9CFD7CDD@oracle.com> > On Mar 16, 2016, at 11:50 AM, Mandy Chung wrote: > >> On Mar 16, 2016, at 10:30 AM, Peter Levart wrote: >> >> In java.lang.ClassLoader: >> >> ...the package-private definePackage(String name, Module m) is OK to use a single packages.compute(...) call performance-wise since it is pre-screened with packages.get() in public getDefinedPackage(String name) method. Peter - thanks for clarifying this. This suggests no need to change definePackage(String,Module). >> But there's also a package-private packages() method (a basis for public methods getPackages() and getDefinedPackages()) that constructs a Stream of defined Packages which unnecessarily calls definePackage() for each value of packages map: >> >> Stream packages() { >> return packages.values().stream() >> .map(p -> definePackage(p.packageName(), p.module())); >> } >> >> >> It would be nice performance-wise to avoid calling definePackage if the value is already a Package: >> >> Stream packages() { >> return packages.values().stream() >> .map(p -> p instanceof Package >> ? (Package) p >> : definePackage(p.packageName(), p.module())); >> } >> I have cleaned up the code to use toPackage instead: http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/jigsaw-m3/webrev-03-16/index.html Mandy From harold.seigel at oracle.com Wed Mar 16 21:09:45 2016 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Wed, 16 Mar 2016 21:09:45 +0000 Subject: hg: jigsaw/jake/hotspot: Fix JVMTI Jake test failures Message-ID: <201603162109.u2GL9jU0024272@aojmv0008.oracle.com> Changeset: ed6046fc103f Author: sspitsyn Date: 2016-03-16 16:41 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ed6046fc103f Fix JVMTI Jake test failures ! src/share/vm/prims/jvmtiEnvBase.hpp ! src/share/vm/prims/jvmtiEventController.cpp From mandy.chung at oracle.com Wed Mar 16 21:52:44 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 16 Mar 2016 21:52:44 +0000 Subject: hg: jigsaw/jake/jdk: Module::addPackage to check for an existing package Message-ID: <201603162152.u2GLqiWO010298@aojmv0008.oracle.com> Changeset: 3463722f77cc Author: plevart Date: 2016-03-16 14:00 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3463722f77cc Module::addPackage to check for an existing package ! src/java.base/share/classes/java/lang/reflect/Module.java ! src/java.base/share/classes/java/lang/reflect/Proxy.java From jonathan.gibbons at oracle.com Wed Mar 16 22:17:32 2016 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 16 Mar 2016 22:17:32 +0000 Subject: hg: jigsaw/jake/langtools: Simplify module test organization Message-ID: <201603162217.u2GMHW6q020021@aojmv0008.oracle.com> Changeset: ea2696da9140 Author: jjg Date: 2016-03-16 15:17 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/ea2696da9140 Simplify module test organization - test/tools/javac/main/MOptionTest.java + test/tools/javac/modules/MOptionTest.java + test/tools/javac/modules/ModuleTestBase.java + test/tools/javac/modules/NPEEmptyFileTest.java + test/tools/javac/modules/ServiceInStaticClassErrorTest.java + test/tools/javac/modules/ServiceProvidedButNotExportedOrUsedTest.java - test/tools/javac/modules/T8133058/NPEEmptyFileTest.java - test/tools/javac/modules/T8145013/ServiceProvidedButNotExportedOrUsedTest.java - test/tools/javac/modules/T8149033/ServiceInStaticClassErrorTest.java - test/tools/lib/ModuleTestBase.java From peter.levart at gmail.com Wed Mar 16 22:18:11 2016 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 16 Mar 2016 23:18:11 +0100 Subject: Initial webrev with changes for JDK 9 In-Reply-To: <4E48E13A-0790-43FF-97CB-F6DE9CFD7CDD@oracle.com> References: <56E29267.7070501@oracle.com> <57D437E7-2EC8-45DB-85C0-3ECA3047AA8C@oracle.com> <56E8148D.4090202@gmail.com> <4E48E13A-0790-43FF-97CB-F6DE9CFD7CDD@oracle.com> Message-ID: <56E9DBA3.80702@gmail.com> Hi Mandy, On 03/16/2016 10:03 PM, Mandy Chung wrote: > I have cleaned up the code to use toPackage instead: > http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/jigsaw-m3/webrev-03-16/index.html > > Mandy Was your intention for public methods getDefinedPackage(name), getPackages() and getDefinedPackages() to return transient Package instances in cases where NamedPackage(s) are present in 'packages' map? Previously, NamedPackage(s) were replaced with Package(s) in 'packages' map when 1st requested. The toPackage(String, NamedPackage, Module) does not replace - it just creates new Package instance if needed. Perhaps we need a method like: private Package definePackageIfNeeded(String name, Module m, /* nullable */ NamedPackage np) { return (np instanceof Package) ? (Package) np : packages.compute(name, (n, p) -> (p instanceof Package) ? (Package) p : NamedPackage.toPackage(n, m)); } Then we can use it everywhere: public final Package getDefinedPackage(String name) { NamedPackage p = packages.get(name); return (p == null) ? null : definePackageIfNeeded(p.packageName(), p.module(), p); } Stream packages() { return packages.values().stream() .map(p -> definePackageIfNeeded(p.packageName(), p.module(), p)); } Package definePackage(String name, Module m) { if (name.isEmpty() && m.isNamed()) { throw new InternalError("unnamed package in " + m); } return definePackageIfNeeded(name, m, null); } What do you think? Regards, Peter From mandy.chung at oracle.com Wed Mar 16 23:01:14 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 16 Mar 2016 16:01:14 -0700 Subject: Initial webrev with changes for JDK 9 In-Reply-To: <56E9DBA3.80702@gmail.com> References: <56E29267.7070501@oracle.com> <57D437E7-2EC8-45DB-85C0-3ECA3047AA8C@oracle.com> <56E8148D.4090202@gmail.com> <4E48E13A-0790-43FF-97CB-F6DE9CFD7CDD@oracle.com> <56E9DBA3.80702@gmail.com> Message-ID: <8CABF9E8-972F-4E47-B0E5-DD0B056D29B3@oracle.com> > On Mar 16, 2016, at 3:18 PM, Peter Levart wrote: > > Hi Mandy, > > On 03/16/2016 10:03 PM, Mandy Chung wrote: >> I have cleaned up the code to use toPackage instead: >> >> http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/jigsaw-m3/webrev-03-16/index.html >> >> >> Mandy >> > Please see the updated webrev that essentially achieve the same result as you propose. Mandy From mandy.chung at oracle.com Wed Mar 16 23:30:57 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 16 Mar 2016 23:30:57 +0000 Subject: hg: jigsaw/jake/jdk: Review comment from plevart Message-ID: <201603162330.u2GNUvIX016835@aojmv0008.oracle.com> Changeset: 870503e3c62d Author: mchung Date: 2016-03-16 16:30 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/870503e3c62d Review comment from plevart ! src/java.base/share/classes/java/lang/ClassLoader.java From mandy.chung at oracle.com Wed Mar 16 23:34:14 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 16 Mar 2016 23:34:14 +0000 Subject: hg: jigsaw/jake/jdk: ResourceBundleProviderSupport::loadResourceBundle now throws SecurityPermission Message-ID: <201603162334.u2GNYEOi018417@aojmv0008.oracle.com> Changeset: 66de7da75869 Author: okutsu Date: 2016-03-16 16:34 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/66de7da75869 ResourceBundleProviderSupport::loadResourceBundle now throws SecurityPermission ! src/java.base/share/classes/java/util/ResourceBundle.java ! src/java.base/share/classes/java/util/spi/AbstractResourceBundleProvider.java ! src/java.base/share/classes/sun/util/locale/provider/ResourceBundleProviderSupport.java From mandy.chung at oracle.com Thu Mar 17 00:01:16 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 17 Mar 2016 00:01:16 +0000 Subject: hg: jigsaw/jake/jdk: New test for ResourceBundle::getBundle Message-ID: <201603170001.u2H01GQ0029141@aojmv0008.oracle.com> Changeset: 2a8555360c79 Author: mchung Date: 2016-03-16 17:01 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2a8555360c79 New test for ResourceBundle::getBundle + test/java/util/ResourceBundle/modules/security/TestPermission.java + test/java/util/ResourceBundle/modules/security/src/m1/module-info.java + test/java/util/ResourceBundle/modules/security/src/m1/p1/Bundle.java + test/java/util/ResourceBundle/modules/security/src/m1/p1/resources/MyResources.java + test/java/util/ResourceBundle/modules/security/src/test/jdk/test/Main.java + test/java/util/ResourceBundle/modules/security/src/test/jdk/test/resources/TestResources.java + test/java/util/ResourceBundle/modules/security/src/test/module-info.java From kevin.rushforth at oracle.com Thu Mar 17 03:00:17 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 16 Mar 2016 20:00:17 -0700 Subject: [9] Review request for FX Jigsaw changes In-Reply-To: <56E77594.8030401@oracle.com> References: <56E77594.8030401@oracle.com> Message-ID: <56EA1DC1.7020609@oracle.com> Here are the proposed final webrevs barring any last minute problems: https://bugs.openjdk.java.net/browse/JDK-8092093 http://cr.openjdk.java.net/~kcr/8092093/webrev.01/rt/ http://cr.openjdk.java.net/~kcr/8092093/webrev.01/rt-fxpackager/ Here are the delta webrevs from version 00. There is no change to fxpackager in version 01: http://cr.openjdk.java.net/~kcr/8092093/webrev.delta-00-01/rt/ http://cr.openjdk.java.net/~kcr/8092093/webrev.delta-00-01/rt-fxpackager/ -- Kevin Kevin Rushforth wrote: > Please review the webrev for reviewing the jigsaw changes for FX. > > https://bugs.openjdk.java.net/browse/JDK-8092093 > > http://cr.openjdk.java.net/~kcr/8092093/webrev.00/rt/ > http://cr.openjdk.java.net/~kcr/8092093/webrev.00/rt-fxpackager/ > > I have separated out the in-progress changes to modules/fxpackager* > (jdk.packager and jdk.packager.services modules) so they can be > reviewed separately. However, they will be pushed along with the other > changes as a single changeset. > > These changes are planned to be integrated into FX 9 at the same time > as the JDK changes are integrated (probably next week). They will be > synced down to FX 9-dev shortly after that. > > Please note the following: > > * The required boot JDK to build FX after the Jigsaw integration will > be JDK 9 build 109. We are not yet able to build with a Jigsaw-based > JDK 9 as the boot JDK yet, so we will be sticking at JDK 9 build 109 > for a few weeks. > > * gradle 2.11 is required to build using JDK 9 > > * In addition to building JavaFX as modules for use with a > Jigsaw-capable JDK, we still build the "legacy sdk" using the existing > pre-Jigsaw layout, including jfxrt.jar, etc. As such, most developers > during the transition will hopefully not notice too much change. > > * If you do want to run tests using the modules, you will need a > Jigsaw-based JDK with javafx modules included, and point to that with > a JDK9_HOME (likely to be changed to JIGSAW_HOME) env variable. If you > actually want to build the JDK (which you will need to do if any > module dependencies change), we will send out separate instructions. > These will eventually make it onto the OpenJFX Wiki. > > * The fxpackager modules are disabled by default. To enable them, you > need to build a Jigsaw-based JDK *without* the jdk.pacakger* modules > and point to that with a JDK9_HOME (likely to be changed to > JIGSAW_HOME) env variable. Since most developers will not build in > this mode, you need to set 'gradle -PBUILD_FXPACKAGER' to enable > building the packager. > > * I will refresh the webrev tomorrow afternoon, after making a couple > of planned changes and reacting to any feedback, and again on > Wednesday afternoon. > > -- Kevin > From kevin.rushforth at oracle.com Thu Mar 17 03:04:17 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 16 Mar 2016 20:04:17 -0700 Subject: [9] Review request for FX Jigsaw changes In-Reply-To: <56EA1DC1.7020609@oracle.com> References: <56E77594.8030401@oracle.com> <56EA1DC1.7020609@oracle.com> Message-ID: <56EA1EB1.9030809@oracle.com> I should add that the only changes are related to: 1) Renamed JDK9_HOME to JIGSAW_HOME 2) Cleanup FIXME comments -- Kevin Kevin Rushforth wrote: > Here are the proposed final webrevs barring any last minute problems: > > https://bugs.openjdk.java.net/browse/JDK-8092093 > > http://cr.openjdk.java.net/~kcr/8092093/webrev.01/rt/ > http://cr.openjdk.java.net/~kcr/8092093/webrev.01/rt-fxpackager/ > > Here are the delta webrevs from version 00. There is no change to > fxpackager in version 01: > > http://cr.openjdk.java.net/~kcr/8092093/webrev.delta-00-01/rt/ > http://cr.openjdk.java.net/~kcr/8092093/webrev.delta-00-01/rt-fxpackager/ > > -- Kevin > > > Kevin Rushforth wrote: >> Please review the webrev for reviewing the jigsaw changes for FX. >> >> https://bugs.openjdk.java.net/browse/JDK-8092093 >> >> http://cr.openjdk.java.net/~kcr/8092093/webrev.00/rt/ >> http://cr.openjdk.java.net/~kcr/8092093/webrev.00/rt-fxpackager/ >> >> I have separated out the in-progress changes to modules/fxpackager* >> (jdk.packager and jdk.packager.services modules) so they can be >> reviewed separately. However, they will be pushed along with the >> other changes as a single changeset. >> >> These changes are planned to be integrated into FX 9 at the same time >> as the JDK changes are integrated (probably next week). They will be >> synced down to FX 9-dev shortly after that. >> >> Please note the following: >> >> * The required boot JDK to build FX after the Jigsaw integration will >> be JDK 9 build 109. We are not yet able to build with a Jigsaw-based >> JDK 9 as the boot JDK yet, so we will be sticking at JDK 9 build 109 >> for a few weeks. >> >> * gradle 2.11 is required to build using JDK 9 >> >> * In addition to building JavaFX as modules for use with a >> Jigsaw-capable JDK, we still build the "legacy sdk" using the >> existing pre-Jigsaw layout, including jfxrt.jar, etc. As such, most >> developers during the transition will hopefully not notice too much >> change. >> >> * If you do want to run tests using the modules, you will need a >> Jigsaw-based JDK with javafx modules included, and point to that with >> a JDK9_HOME (likely to be changed to JIGSAW_HOME) env variable. If >> you actually want to build the JDK (which you will need to do if any >> module dependencies change), we will send out separate instructions. >> These will eventually make it onto the OpenJFX Wiki. >> >> * The fxpackager modules are disabled by default. To enable them, you >> need to build a Jigsaw-based JDK *without* the jdk.pacakger* modules >> and point to that with a JDK9_HOME (likely to be changed to >> JIGSAW_HOME) env variable. Since most developers will not build in >> this mode, you need to set 'gradle -PBUILD_FXPACKAGER' to enable >> building the packager. >> >> * I will refresh the webrev tomorrow afternoon, after making a couple >> of planned changes and reacting to any feedback, and again on >> Wednesday afternoon. >> >> -- Kevin >> From catull at gmail.com Thu Mar 17 06:23:07 2016 From: catull at gmail.com (Carlo Dapor) Date: Thu, 17 Mar 2016 07:23:07 +0100 Subject: hg: jigsaw/jake/jdk: Review comment from plevart In-Reply-To: <201603162330.u2GNUvIX016835@aojmv0008.oracle.com> References: <201603162330.u2GNUvIX016835@aojmv0008.oracle.com> Message-ID: Hello Mandy Your correction can be shortened. The null-check can be left out. p instanceof Package is a combined null check and a type check. Regards, Carlo On Mar 17, 2016 00:31, wrote: > Changeset: 870503e3c62d > Author: mchung > Date: 2016-03-16 16:30 -0700 > URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/870503e3c62d > > Review comment from plevart > > ! src/java.base/share/classes/java/lang/ClassLoader.java > > From Alan.Bateman at oracle.com Thu Mar 17 07:10:20 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 17 Mar 2016 07:10:20 +0000 Subject: [9] Review request for FX Jigsaw changes In-Reply-To: <56EA1EB1.9030809@oracle.com> References: <56E77594.8030401@oracle.com> <56EA1DC1.7020609@oracle.com> <56EA1EB1.9030809@oracle.com> Message-ID: <56EA585C.90005@oracle.com> On 17/03/2016 03:04, Kevin Rushforth wrote: > I should add that the only changes are related to: > > 1) Renamed JDK9_HOME to JIGSAW_HOME Is this for transition purposes and it would revert again to JDK9_HOME later? -Alan From forax at univ-mlv.fr Thu Mar 17 10:37:46 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 17 Mar 2016 11:37:46 +0100 (CET) Subject: jdk.internal.module.Service.ServicesCatalog should use synchronized to improve the VM boot time In-Reply-To: <1987251085.2929810.1458210454296.JavaMail.zimbra@u-pem.fr> Message-ID: <682162903.2938830.1458211066049.JavaMail.zimbra@u-pem.fr> Hi all, currently ServicesCatalog uses a R/W lock which is great if looking up for a service was a contended operation, but i don't think it is. I will not care if ServicesCatalog was not used early in the boot process, but it is. As far as i know, no other class uses a R/W lock during the boot process (I may be wrong, i've checked only against the latest jdk8) so i think that - using synchronized here is good enough - it will avoid to load a bunch of classes from java.util.concurrent.locks thus make the VM boot faster. regards, R?mi From Alan.Bateman at oracle.com Thu Mar 17 10:47:21 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 17 Mar 2016 10:47:21 +0000 Subject: jdk.internal.module.Service.ServicesCatalog should use synchronized to improve the VM boot time In-Reply-To: <682162903.2938830.1458211066049.JavaMail.zimbra@u-pem.fr> References: <682162903.2938830.1458211066049.JavaMail.zimbra@u-pem.fr> Message-ID: <56EA8B39.7010407@oracle.com> On 17/03/2016 10:37, Remi Forax wrote: > Hi all, > currently ServicesCatalog uses a R/W lock which is great if looking up for a service was a contended operation, > but i don't think it is. I will not care if ServicesCatalog was not used early in the boot process, but it is. > > As far as i know, no other class uses a R/W lock during the boot process > (I may be wrong, i've checked only against the latest jdk8) > so i think that > - using synchronized here is good enough > - it will avoid to load a bunch of classes from java.util.concurrent.locks thus make the VM boot faster. > Fair point, it is the first user of ReentrantReadWriteLock. I expect we'll replace this code once we address a number of other issues and so I'd prefer not to change it now, at least for the initial integration. -Alan. From alan.bateman at oracle.com Thu Mar 17 12:20:49 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 17 Mar 2016 12:20:49 +0000 Subject: hg: jigsaw/jake/jdk: 2 new changesets Message-ID: <201603171220.u2HCKnBf029816@aojmv0008.oracle.com> Changeset: f34b2eb63587 Author: alanb Date: 2016-03-17 07:44 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f34b2eb63587 Clean/review comment ! src/java.base/share/classes/java/lang/ClassLoader.java Changeset: 33f9fee5f0d3 Author: alanb Date: 2016-03-17 11:25 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/33f9fee5f0d3 Add note to builder javadoc ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java From forax at univ-mlv.fr Thu Mar 17 12:25:04 2016 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 17 Mar 2016 13:25:04 +0100 (CET) Subject: jdk.internal.module.Service.ServicesCatalog should use synchronized to improve the VM boot time In-Reply-To: <56EA8B39.7010407@oracle.com> References: <682162903.2938830.1458211066049.JavaMail.zimbra@u-pem.fr> <56EA8B39.7010407@oracle.com> Message-ID: <431381526.3013332.1458217504855.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Alan Bateman" > ?: "Remi Forax" , "jigsaw-dev" > Envoy?: Jeudi 17 Mars 2016 11:47:21 > Objet: Re: jdk.internal.module.Service.ServicesCatalog should use synchronized to improve the VM boot time > > On 17/03/2016 10:37, Remi Forax wrote: > > Hi all, > > currently ServicesCatalog uses a R/W lock which is great if looking up for > > a service was a contended operation, > > but i don't think it is. I will not care if ServicesCatalog was not used > > early in the boot process, but it is. > > > > As far as i know, no other class uses a R/W lock during the boot process > > (I may be wrong, i've checked only against the latest jdk8) > > so i think that > > - using synchronized here is good enough > > - it will avoid to load a bunch of classes from java.util.concurrent.locks > > thus make the VM boot faster. > > > Fair point, it is the first user of ReentrantReadWriteLock. I expect > we'll replace this code once we address a number of other issues and so > I'd prefer not to change it now, at least for the initial integration. yes, i agree, it's a post-integration works. > > -Alan. > R?mi From Alan.Bateman at oracle.com Thu Mar 17 12:30:11 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 17 Mar 2016 12:30:11 +0000 Subject: jdk.internal.module.Service.ServicesCatalog should use synchronized to improve the VM boot time In-Reply-To: <431381526.3013332.1458217504855.JavaMail.zimbra@u-pem.fr> References: <682162903.2938830.1458211066049.JavaMail.zimbra@u-pem.fr> <56EA8B39.7010407@oracle.com> <431381526.3013332.1458217504855.JavaMail.zimbra@u-pem.fr> Message-ID: <56EAA353.80800@oracle.com> On 17/03/2016 12:25, forax at univ-mlv.fr wrote: > : > yes, i agree, it's a post-integration works. > > Yeah, once we get the initial integration in then we can start to get through the many issues that need to be sorted out before feature complete. I've no doubt that many areas of the code will be re-worked. Lots of cleanup and startup work to do. -Alan. From konstantin.barzilovich at oracle.com Thu Mar 17 13:02:45 2016 From: konstantin.barzilovich at oracle.com (Konstantin Barzilovich) Date: Thu, 17 Mar 2016 16:02:45 +0300 Subject: "Provides" and "with" type relationships In-Reply-To: <56E9B0D3.7000601@oracle.com> References: <56E861D7.4070005@oracle.com> <56E86E4A.3020505@oracle.com> <56E9B0D3.7000601@oracle.com> Message-ID: Thanks. It is described in API spec in detail. But from compiler point of view, it is allowed to use implementation without inheritance. It would be grate to add some of these statements to compiler spec, if it is possible. Thanks, Konstantin. > Yes. 'uses' and 'provides' are nothing more than static declarations > that configure java.util.ServiceLoader, so all questions can be resolved > by looking at the ServiceLoader spec: > http://download.java.net/java/jigsaw/docs/api/java/util/ServiceLoader.html > > Alex > > On 3/16/2016 10:24 AM, Konstantin Barzilovich wrote: >> Sorry, if this question was asked before. >> Does service implementation need to inherit service interface? >> >> Thanks, >> Konstantin. >> >>> // Ignore last mail (mail client did a surprising thing) >>> >>> A 'provides' clause specifies two things: a service interface and a >>> service implementation. Using those terms helps to avoid confusion. >>> >>> A service interface does not have to be an interface; it can be an >>> abstract class or even (not recommended) a concrete class. >>> >>> A service implementation must not be an interface, or an abstract >>> class; it must be a concrete class. >>> >>> Therefore, it's legal (but not recommended) for a concrete class to be >>> specified as both service interface and service implementation. It's >>> illegal for an interface (or abstract class) to be specified as both >>> service interface and service implementation. JCK will be writing >>> tests for edge cases like this. >>> >>> Alex >>> >>> On 3/15/2016 12:39 PM, Paul Benedict wrote: >>>> Thanks for your response Alex. If I am understanding you correctly, >>>> "provides" is "not constrained to be an interface" because it can be >>>> "a >>>> single interface or abstract class". So shouldn't my concrete class >>>> for >>>> "provides" be rejected by the compiler? And is it okay that both types >>>> were identical? >>>> >>>> Cheers, >>>> Paul >>>> >>>> On Tue, Mar 15, 2016 at 2:26 PM, Alex Buckley >>> > wrote: >>>> >>>> The first operand to 'provides' (the "service interface") is not >>>> constrained to be an interface by "Modules in the Java Language >>>> and >>>> JVM". This is because the spec of j.u.ServiceLoader ("a service is >>>> represented by a single type, that is, a single interface or >>>> abstract class"). >>>> >>>> The second operand to 'provides' (the "service implementation") is >>>> constrained not to be an interface or an abstract class by >>>> "Modules >>>> in the Java Language and JVM". This is also because of the spec of >>>> j.u.ServiceLoader ("provider classes must have a zero-argument >>>> constructor so that they can be instantiated during loading"). >>>> >>>> Bear in mind that the JCK team can easily set up abstract test >>>> cases >>>> like this. What they can't do is check whether YOUR application >>>> runs >>>> on JDK-9-with-Jigsaw, or whether arbitrary JARs on YOUR classpath >>>> work as automatic modules. >>>> >>>> Alex >>>> >>>> >>>> On 3/15/2016 12:07 PM, Paul Benedict wrote: >>>> >>>> module z { >>>> exports z; >>>> provides z.Main with z.Main; >>>> } >>>> >>>> The SOTM says "Service-provider declarations can be further >>>> interpreted to >>>> ensure that providers (e.g., com.mysql.jdbc.Driver) actually >>>> do >>>> implement >>>> their declared service interfaces" (section 4, para. 8). >>>> >>>> I see javac checking that they are related types, but javac is >>>> not checking >>>> that "provides" is an interface type. That is what I was >>>> expecting based on >>>> the reading material. >>>> >>>> The other unexpected outcome was that provides/with allows the >>>> identical >>>> type. I don't know if that's intended, but please advise. >>>> >>>> PS: I did go through the open tickets this time (thanks Alan) >>>> and do not >>>> see any similar reports. If I missed it, I apologize; just >>>> trying not to >>>> waste your time by reporting a duplicate. >>>> >>>> Cheers, >>>> Paul >>>> >>>> >> >> -- Thanks, Konstantin. From konstantin.barzilovich at oracle.com Thu Mar 17 13:10:19 2016 From: konstantin.barzilovich at oracle.com (Konstantin Barzilovich) Date: Thu, 17 Mar 2016 16:10:19 +0300 Subject: "Provides" and "with" type relationships In-Reply-To: <56E9B0D3.7000601@oracle.com> References: <56E861D7.4070005@oracle.com> <56E86E4A.3020505@oracle.com> <56E9B0D3.7000601@oracle.com> Message-ID: Sorry, I mean "great", not "grate". > Yes. 'uses' and 'provides' are nothing more than static declarations > that configure java.util.ServiceLoader, so all questions can be resolved > by looking at the ServiceLoader spec: > http://download.java.net/java/jigsaw/docs/api/java/util/ServiceLoader.html > > Alex > > On 3/16/2016 10:24 AM, Konstantin Barzilovich wrote: >> Sorry, if this question was asked before. >> Does service implementation need to inherit service interface? >> >> Thanks, >> Konstantin. >> >>> // Ignore last mail (mail client did a surprising thing) >>> >>> A 'provides' clause specifies two things: a service interface and a >>> service implementation. Using those terms helps to avoid confusion. >>> >>> A service interface does not have to be an interface; it can be an >>> abstract class or even (not recommended) a concrete class. >>> >>> A service implementation must not be an interface, or an abstract >>> class; it must be a concrete class. >>> >>> Therefore, it's legal (but not recommended) for a concrete class to be >>> specified as both service interface and service implementation. It's >>> illegal for an interface (or abstract class) to be specified as both >>> service interface and service implementation. JCK will be writing >>> tests for edge cases like this. >>> >>> Alex >>> >>> On 3/15/2016 12:39 PM, Paul Benedict wrote: >>>> Thanks for your response Alex. If I am understanding you correctly, >>>> "provides" is "not constrained to be an interface" because it can be >>>> "a >>>> single interface or abstract class". So shouldn't my concrete class >>>> for >>>> "provides" be rejected by the compiler? And is it okay that both types >>>> were identical? >>>> >>>> Cheers, >>>> Paul >>>> >>>> On Tue, Mar 15, 2016 at 2:26 PM, Alex Buckley >>> > wrote: >>>> >>>> The first operand to 'provides' (the "service interface") is not >>>> constrained to be an interface by "Modules in the Java Language >>>> and >>>> JVM". This is because the spec of j.u.ServiceLoader ("a service is >>>> represented by a single type, that is, a single interface or >>>> abstract class"). >>>> >>>> The second operand to 'provides' (the "service implementation") is >>>> constrained not to be an interface or an abstract class by >>>> "Modules >>>> in the Java Language and JVM". This is also because of the spec of >>>> j.u.ServiceLoader ("provider classes must have a zero-argument >>>> constructor so that they can be instantiated during loading"). >>>> >>>> Bear in mind that the JCK team can easily set up abstract test >>>> cases >>>> like this. What they can't do is check whether YOUR application >>>> runs >>>> on JDK-9-with-Jigsaw, or whether arbitrary JARs on YOUR classpath >>>> work as automatic modules. >>>> >>>> Alex >>>> >>>> >>>> On 3/15/2016 12:07 PM, Paul Benedict wrote: >>>> >>>> module z { >>>> exports z; >>>> provides z.Main with z.Main; >>>> } >>>> >>>> The SOTM says "Service-provider declarations can be further >>>> interpreted to >>>> ensure that providers (e.g., com.mysql.jdbc.Driver) actually >>>> do >>>> implement >>>> their declared service interfaces" (section 4, para. 8). >>>> >>>> I see javac checking that they are related types, but javac is >>>> not checking >>>> that "provides" is an interface type. That is what I was >>>> expecting based on >>>> the reading material. >>>> >>>> The other unexpected outcome was that provides/with allows the >>>> identical >>>> type. I don't know if that's intended, but please advise. >>>> >>>> PS: I did go through the open tickets this time (thanks Alan) >>>> and do not >>>> see any similar reports. If I missed it, I apologize; just >>>> trying not to >>>> waste your time by reporting a duplicate. >>>> >>>> Cheers, >>>> Paul >>>> >>>> >> >> -- Thanks, Konstantin. From Alan.Bateman at oracle.com Thu Mar 17 14:32:03 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 17 Mar 2016 14:32:03 +0000 Subject: Project Jigsaw, build 110 on 03-16-2016 (#4664) Message-ID: <56EABFE3.9040508@oracle.com> jigsaw/jake was sync'ed up to jdk-9+110 earlier in the week and the EA build [1] has been refreshed. We expect this will be the last EA build before we integrate into JDK 9. This means that this EA build is essentially what will be jdk-9+111 next week. As always, please help out by trying out existing code and libraries to see what works and doesn't work. We have a detailed list of compatibility issues listed in JEP 261 [2]. Also feedback and questions from those that trying the EA build to modularize existing code would be appreciated. We also want to know what works and doesn't work here. -Alan [1] https://jdk9.java.net/jigsaw/ [2] http://openjdk.java.net/jeps/261 From kevin.rushforth at oracle.com Thu Mar 17 14:55:56 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 17 Mar 2016 07:55:56 -0700 Subject: [9] Review request for FX Jigsaw changes In-Reply-To: <56EA585C.90005@oracle.com> References: <56E77594.8030401@oracle.com> <56EA1DC1.7020609@oracle.com> <56EA1EB1.9030809@oracle.com> <56EA585C.90005@oracle.com> Message-ID: <56EAC57C.4080908@oracle.com> It is transitional, and will be eliminated later once we are able to use a Jigsaw-enabled JDK 9 as our boot JDK> -- Kevin Alan Bateman wrote: > > On 17/03/2016 03:04, Kevin Rushforth wrote: >> I should add that the only changes are related to: >> >> 1) Renamed JDK9_HOME to JIGSAW_HOME > Is this for transition purposes and it would revert again to JDK9_HOME > later? > > -Alan From christian.tornqvist at oracle.com Thu Mar 17 15:24:42 2016 From: christian.tornqvist at oracle.com (christian.tornqvist at oracle.com) Date: Thu, 17 Mar 2016 15:24:42 +0000 Subject: hg: jigsaw/jake/hotspot: Remove @ignore for 8134071 Message-ID: <201603171524.u2HFOgU6017109@aojmv0008.oracle.com> Changeset: 8f7a797c4239 Author: ctornqvi Date: 2016-03-17 08:23 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/8f7a797c4239 Remove @ignore for 8134071 ! test/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java ! test/serviceability/sa/jmap-hashcode/Test8028623.java From mandy.chung at oracle.com Thu Mar 17 17:32:51 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 17 Mar 2016 17:32:51 +0000 Subject: hg: jigsaw/jake/jdk: review comment from mullan Message-ID: <201603171732.u2HHWptd005634@aojmv0008.oracle.com> Changeset: cd356e5ee0de Author: mchung Date: 2016-03-17 10:32 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/cd356e5ee0de review comment from mullan ! src/java.base/share/classes/java/lang/ClassLoader.java From jonathan.gibbons at oracle.com Thu Mar 17 18:19:41 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 17 Mar 2016 11:19:41 -0700 Subject: "Provides" and "with" type relationships In-Reply-To: References: <56E861D7.4070005@oracle.com> <56E86E4A.3020505@oracle.com> <56E9B0D3.7000601@oracle.com> Message-ID: <56EAF53D.6050500@oracle.com> Konstantin, The compiler checks that the service implementation implements the service type. I have confidence that when the final specification is published, there will be suitable assertions (either explicit or implicit) to back up that check. -- Jon On 03/17/2016 06:02 AM, Konstantin Barzilovich wrote: > > Thanks. > It is described in API spec in detail. > But from compiler point of view, it is allowed to use implementation > without inheritance. > It would be grate to add some of these statements to compiler spec, if > it is possible. > > Thanks, > Konstantin. > >> Yes. 'uses' and 'provides' are nothing more than static declarations >> that configure java.util.ServiceLoader, so all questions can be >> resolved by looking at the ServiceLoader spec: >> http://download.java.net/java/jigsaw/docs/api/java/util/ServiceLoader.html >> >> Alex >> >> On 3/16/2016 10:24 AM, Konstantin Barzilovich wrote: >>> Sorry, if this question was asked before. >>> Does service implementation need to inherit service interface? >>> >>> Thanks, >>> Konstantin. >>> >>>> // Ignore last mail (mail client did a surprising thing) >>>> >>>> A 'provides' clause specifies two things: a service interface and a >>>> service implementation. Using those terms helps to avoid confusion. >>>> >>>> A service interface does not have to be an interface; it can be an >>>> abstract class or even (not recommended) a concrete class. >>>> >>>> A service implementation must not be an interface, or an abstract >>>> class; it must be a concrete class. >>>> >>>> Therefore, it's legal (but not recommended) for a concrete class to be >>>> specified as both service interface and service implementation. It's >>>> illegal for an interface (or abstract class) to be specified as both >>>> service interface and service implementation. JCK will be writing >>>> tests for edge cases like this. >>>> >>>> Alex >>>> >>>> On 3/15/2016 12:39 PM, Paul Benedict wrote: >>>>> Thanks for your response Alex. If I am understanding you correctly, >>>>> "provides" is "not constrained to be an interface" because it can >>>>> be "a >>>>> single interface or abstract class". So shouldn't my concrete >>>>> class for >>>>> "provides" be rejected by the compiler? And is it okay that both >>>>> types >>>>> were identical? >>>>> >>>>> Cheers, >>>>> Paul >>>>> >>>>> On Tue, Mar 15, 2016 at 2:26 PM, Alex Buckley >>>>> >>>> > wrote: >>>>> >>>>> The first operand to 'provides' (the "service interface") is not >>>>> constrained to be an interface by "Modules in the Java >>>>> Language and >>>>> JVM". This is because the spec of j.u.ServiceLoader ("a >>>>> service is >>>>> represented by a single type, that is, a single interface or >>>>> abstract class"). >>>>> >>>>> The second operand to 'provides' (the "service >>>>> implementation") is >>>>> constrained not to be an interface or an abstract class by >>>>> "Modules >>>>> in the Java Language and JVM". This is also because of the >>>>> spec of >>>>> j.u.ServiceLoader ("provider classes must have a zero-argument >>>>> constructor so that they can be instantiated during loading"). >>>>> >>>>> Bear in mind that the JCK team can easily set up abstract test >>>>> cases >>>>> like this. What they can't do is check whether YOUR >>>>> application runs >>>>> on JDK-9-with-Jigsaw, or whether arbitrary JARs on YOUR classpath >>>>> work as automatic modules. >>>>> >>>>> Alex >>>>> >>>>> >>>>> On 3/15/2016 12:07 PM, Paul Benedict wrote: >>>>> >>>>> module z { >>>>> exports z; >>>>> provides z.Main with z.Main; >>>>> } >>>>> >>>>> The SOTM says "Service-provider declarations can be further >>>>> interpreted to >>>>> ensure that providers (e.g., com.mysql.jdbc.Driver) >>>>> actually do >>>>> implement >>>>> their declared service interfaces" (section 4, para. 8). >>>>> >>>>> I see javac checking that they are related types, but >>>>> javac is >>>>> not checking >>>>> that "provides" is an interface type. That is what I was >>>>> expecting based on >>>>> the reading material. >>>>> >>>>> The other unexpected outcome was that provides/with allows >>>>> the >>>>> identical >>>>> type. I don't know if that's intended, but please advise. >>>>> >>>>> PS: I did go through the open tickets this time (thanks Alan) >>>>> and do not >>>>> see any similar reports. If I missed it, I apologize; just >>>>> trying not to >>>>> waste your time by reporting a duplicate. >>>>> >>>>> Cheers, >>>>> Paul >>>>> >>>>> >>> >>> > > From alex.buckley at oracle.com Thu Mar 17 18:41:53 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 17 Mar 2016 11:41:53 -0700 Subject: "Provides" and "with" type relationships In-Reply-To: <56EAF53D.6050500@oracle.com> References: <56E861D7.4070005@oracle.com> <56E86E4A.3020505@oracle.com> <56E9B0D3.7000601@oracle.com> <56EAF53D.6050500@oracle.com> Message-ID: <56EAFA71.5010407@oracle.com> There are also some improvements to make to the ServiceLoader API spec, and at that time we'll lock in alignment of API spec and JLS. (Consistent terminology; duplication of rules only where essential; appropriate "call outs" to module system concepts such as service binding). Alex On 3/17/2016 11:19 AM, Jonathan Gibbons wrote: > Konstantin, > > The compiler checks that the service implementation implements the > service type. > I have confidence that when the final specification is published, there > will be suitable assertions (either explicit or implicit) to back up > that check. > > -- Jon > > On 03/17/2016 06:02 AM, Konstantin Barzilovich wrote: >> >> Thanks. >> It is described in API spec in detail. >> But from compiler point of view, it is allowed to use implementation >> without inheritance. >> It would be grate to add some of these statements to compiler spec, if >> it is possible. >> >> Thanks, >> Konstantin. >> >>> Yes. 'uses' and 'provides' are nothing more than static declarations >>> that configure java.util.ServiceLoader, so all questions can be >>> resolved by looking at the ServiceLoader spec: >>> http://download.java.net/java/jigsaw/docs/api/java/util/ServiceLoader.html >>> >>> >>> Alex >>> >>> On 3/16/2016 10:24 AM, Konstantin Barzilovich wrote: >>>> Sorry, if this question was asked before. >>>> Does service implementation need to inherit service interface? >>>> >>>> Thanks, >>>> Konstantin. >>>> >>>>> // Ignore last mail (mail client did a surprising thing) >>>>> >>>>> A 'provides' clause specifies two things: a service interface and a >>>>> service implementation. Using those terms helps to avoid confusion. >>>>> >>>>> A service interface does not have to be an interface; it can be an >>>>> abstract class or even (not recommended) a concrete class. >>>>> >>>>> A service implementation must not be an interface, or an abstract >>>>> class; it must be a concrete class. >>>>> >>>>> Therefore, it's legal (but not recommended) for a concrete class to be >>>>> specified as both service interface and service implementation. It's >>>>> illegal for an interface (or abstract class) to be specified as both >>>>> service interface and service implementation. JCK will be writing >>>>> tests for edge cases like this. >>>>> >>>>> Alex >>>>> >>>>> On 3/15/2016 12:39 PM, Paul Benedict wrote: >>>>>> Thanks for your response Alex. If I am understanding you correctly, >>>>>> "provides" is "not constrained to be an interface" because it can >>>>>> be "a >>>>>> single interface or abstract class". So shouldn't my concrete >>>>>> class for >>>>>> "provides" be rejected by the compiler? And is it okay that both >>>>>> types >>>>>> were identical? >>>>>> >>>>>> Cheers, >>>>>> Paul >>>>>> >>>>>> On Tue, Mar 15, 2016 at 2:26 PM, Alex Buckley >>>>>> >>>>> > wrote: >>>>>> >>>>>> The first operand to 'provides' (the "service interface") is not >>>>>> constrained to be an interface by "Modules in the Java >>>>>> Language and >>>>>> JVM". This is because the spec of j.u.ServiceLoader ("a >>>>>> service is >>>>>> represented by a single type, that is, a single interface or >>>>>> abstract class"). >>>>>> >>>>>> The second operand to 'provides' (the "service >>>>>> implementation") is >>>>>> constrained not to be an interface or an abstract class by >>>>>> "Modules >>>>>> in the Java Language and JVM". This is also because of the >>>>>> spec of >>>>>> j.u.ServiceLoader ("provider classes must have a zero-argument >>>>>> constructor so that they can be instantiated during loading"). >>>>>> >>>>>> Bear in mind that the JCK team can easily set up abstract test >>>>>> cases >>>>>> like this. What they can't do is check whether YOUR >>>>>> application runs >>>>>> on JDK-9-with-Jigsaw, or whether arbitrary JARs on YOUR classpath >>>>>> work as automatic modules. >>>>>> >>>>>> Alex >>>>>> >>>>>> >>>>>> On 3/15/2016 12:07 PM, Paul Benedict wrote: >>>>>> >>>>>> module z { >>>>>> exports z; >>>>>> provides z.Main with z.Main; >>>>>> } >>>>>> >>>>>> The SOTM says "Service-provider declarations can be further >>>>>> interpreted to >>>>>> ensure that providers (e.g., com.mysql.jdbc.Driver) >>>>>> actually do >>>>>> implement >>>>>> their declared service interfaces" (section 4, para. 8). >>>>>> >>>>>> I see javac checking that they are related types, but >>>>>> javac is >>>>>> not checking >>>>>> that "provides" is an interface type. That is what I was >>>>>> expecting based on >>>>>> the reading material. >>>>>> >>>>>> The other unexpected outcome was that provides/with allows >>>>>> the >>>>>> identical >>>>>> type. I don't know if that's intended, but please advise. >>>>>> >>>>>> PS: I did go through the open tickets this time (thanks Alan) >>>>>> and do not >>>>>> see any similar reports. If I missed it, I apologize; just >>>>>> trying not to >>>>>> waste your time by reporting a duplicate. >>>>>> >>>>>> Cheers, >>>>>> Paul >>>>>> >>>>>> >>>> >>>> >> >> > From pbenedict at apache.org Thu Mar 17 18:49:19 2016 From: pbenedict at apache.org (Paul Benedict) Date: Thu, 17 Mar 2016 13:49:19 -0500 Subject: Clarification on META-INF/services from SOTMS Message-ID: >From section 4 on Services: "The module system could identify service providers by scanning module artifacts for META-INF/services resource entries, as the ServiceLoader class does today. That a module provides an implementation of a particular service is equally fundamental" My question regards the use of "could" -- a word that indicates possibility, not certainty. It's peculiar wording. If the module system still uses META-INF/services, then "could" is misleading. So: 1) Is META-INF/services being planned to go away in the future? 2) What is the relationship between META-INF/services and provides/with keywords? Who wins in the presence of both? Cheers, Paul From alex.buckley at oracle.com Thu Mar 17 19:04:38 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 17 Mar 2016 12:04:38 -0700 Subject: Clarification on META-INF/services from SOTMS In-Reply-To: References: Message-ID: <56EAFFC6.1060901@oracle.com> On 3/17/2016 11:49 AM, Paul Benedict wrote: > From section 4 on Services: > "The module system could identify service providers by scanning module > artifacts for META-INF/services resource entries, as the ServiceLoader > class does today. That a module provides an implementation of a particular > service is equally fundamental" > > My question regards the use of "could" -- a word that indicates > possibility, not certainty. It's peculiar wording. If the module system > still uses META-INF/services, then "could" is misleading. The word "could" is setting up a strawman -- we could, technically, do something, but for philosophical reasons we are going to do something else. For an explicit named module, the uses/provides clauses are dominant -- nothing in the document suggests that META-INF/services files in explicit named modules are scanned. For an implicit named module (a.k.a. automatic module), the document does have a suggestion involving META-INF/services. For the unnamed module, the document is silent on how it offers service providers to named modules, and whether it can discover service providers from named modules. Interop between the unnamed module and named modules is a constant source of strife. > 1) Is META-INF/services being planned to go away in the future? No. > 2) What is the relationship between META-INF/services and provides/with > keywords? Who wins in the presence of both? Good question, which the cleanup of the ServiceLoader API spec will have to address. Alex From Alan.Bateman at oracle.com Thu Mar 17 19:47:10 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 17 Mar 2016 19:47:10 +0000 Subject: jigsaw/m3 Message-ID: <56EB09BE.2010401@oracle.com> As I mentioned in a recent mail [1], we've created jigsaw/m3 as a staging forest to stage the changesets that we hope will be pushed to JDK 9 next week. We're going to take a snapshot of what is in jigsaw/jake and push it to staging forest today, one (collapsed) changeset per repo. Mandy will probably do the push. The quality/test team in Oracle are going to test the builds of the staging forest and we'll decide on Tuesday (March 22) on whether to push to jdk9/jdk9 or not. For those tracking FX then you'll have seen the mails from Kevin Rushforth with the changes for openjfx/9/rt, including the packager. The FX team are working to the same plan so that they integrate into FX 9 at the same time that the JDK changes are integrated. All going well, the EA build of jdk-9+111 on the java.net download site will have the FX modules linked into the runtime image, as we have been doing with the JDK 9 EA builds with Project Jigsaw. -Alan. [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-March/006899.html From rfscholte at apache.org Thu Mar 17 19:51:32 2016 From: rfscholte at apache.org (Robert Scholte) Date: Thu, 17 Mar 2016 20:51:32 +0100 Subject: modulepath and classpath mixture In-Reply-To: <20160316135501.530460938eggemoggin.niobe.net> References: <56CBAD62.3010508@oracle.com> <20160316135501.530460938eggemoggin.niobe.net> Message-ID: Hi, it seems that simply adding -addmods ALL-MODULE-PATH isn't enough to compile the test-sources, and some already referred to it. Here's the compiler error: maven-builder-support/src/test/java/org/apache/maven/building/DefaultProblemTest.java:[1,1] package exists in another module: maven.builder.support Let me quote Alan from one of the first responses on this thread: "For the tests then I assume they are in the same packages as the sources under src/main/java, is that right? In that case I think you will want to compile the tests as if they are part of the module: javac -Xmodule:m -d testclasses/m -mp m.jar test/java/... where m is the module name and the module (with sources in src/main/java) has already been compiled and then packaged as m.jar. The -Xmodule: option tells the compiler that you compiling the test classes as if they are part of module m. There is no module-info.java in the test tree." To me it seems like the need for knowing the module name keeps returning. This increases the need for a proper implementation of the maven-compiler-plugin as a multirelease JAR. The pattern as shown during FOSDEM showed that the idea works, but it is not solid enough. And the next question would be: can Maven (or actually Plexus ClassWorld) handle this? I'll need to work out the things to be done and try to get more Maven developers involved. thanks, Robert On Wed, 16 Mar 2016 21:55:01 +0100, wrote: > 2016/2/27 3:25 -0800, rfscholte at apache.org: >> I noticed[1] that -addmods already has a special option: ALL-SYSTEM >> What I'm looking for is something like ALL-MP or ALL-MODULEPATH, which >> simply exposes all modules on the modulepath to the classpath. The set >> of >> moduleEntries on the modulePath are already chosen with care and are in >> the end all required to be able to compile the test-classes without the >> need of knowing the name of the module being used to compile with. > > We added a special ALL-MODULE-PATH token to the -addmods option, with > this description now in JEP 261 (http://openjdk.java.net/jeps/261): > > As a further special case, if `` is `ALL-MODULE-PATH` then all > observable modules found on module paths are added to the root set. > `ALL-MODULE-PATH` is valid at compile time when compiling classes in > the > unnamed module, and at run time when the main class of the application > is > loaded from the class path into the unnamed module. > > This change is in Jigsaw EA build #4647 (https://jdk9.java.net/jigsaw/). > Please try it out and let us know what you think. > > - Mark From Alan.Bateman at oracle.com Thu Mar 17 19:56:53 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 17 Mar 2016 19:56:53 +0000 Subject: Clarification on META-INF/services from SOTMS In-Reply-To: References: Message-ID: <56EB0C05.7050803@oracle.com> On 17/03/2016 18:49, Paul Benedict wrote: > From section 4 on Services: > "The module system could identify service providers by scanning module > artifacts for META-INF/services resource entries, as the ServiceLoader > class does today. That a module provides an implementation of a particular > service is equally fundamental" > > My question regards the use of "could" -- a word that indicates > possibility, not certainty. It's peculiar wording. If the module system > still uses META-INF/services, then "could" is misleading. So: > > 1) Is META-INF/services being planned to go away in the future? > 2) What is the relationship between META-INF/services and provides/with > keywords? Who wins in the presence of both? > Just to add to Alex's comment. If an explicit module on the module path has a META-INF/services configuration file then it is ignored. The `provides` clauses in the module declaration is the only way to declare the service providers. There is wording in ServiceLoader javadoc on this but it needs further work, as Alex points out. It may be that a JAR file has both a module-info.java and service configuration files. This might arise for libraries that are capable of being deployed as both modules and regular JAR files on the class path (say with JDK 8). For automatic modules then the service configuration files is used to derive the list of service providers in the module. There is wording in the ModuleFinder javadoc on that. -Alan From mandy.chung at oracle.com Thu Mar 17 20:00:53 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 17 Mar 2016 20:00:53 +0000 Subject: hg: jigsaw/m3: 8142968: Module System implementation Message-ID: <201603172000.u2HK0rjb005163@aojmv0008.oracle.com> Changeset: f900d5afd9c8 Author: alanb Date: 2016-03-17 19:03 +0000 URL: http://hg.openjdk.java.net/jigsaw/m3/rev/f900d5afd9c8 8142968: Module System implementation Summary: Initial integration of JEP 200, JEP 260, JEP 261, and JEP 282 Reviewed-by: alanb, mchung, tbell Contributed-by: alan.bateman at oracle.com, alex.buckley at oracle.com, jonathan.gibbons at oracle.com, karen.kinnear at oracle.com, mandy.chung at oracle.com, mark.reinhold at oracle.com, erik.joelsson at oracle.com, chris.hegarty at oracle.com, christian.tornqvist at oracle.com, harold.seigel at oracle.com, igor.ignatyev at oracle.com, james.laskey at oracle.com, jean-francois.denise at oracle.com, sundararajan.athijegannathan at oracle.com ! common/autoconf/basics.m4 ! common/autoconf/boot-jdk.m4 ! common/autoconf/bootcycle-spec.gmk.in + common/autoconf/buildjdk-spec.gmk.in ! common/autoconf/configure.ac ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 ! common/autoconf/platform.m4 ! common/autoconf/source-dirs.m4 ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 ! common/bin/compare.sh ! common/conf/jib-profiles.js - make/CheckModules.gmk ! make/CompileJavaModules.gmk + make/CopyImportModules.gmk + make/CreateBuildJdkCopy.gmk + make/CreateJmods.gmk - make/GenerateModuleDeps.gmk + make/GensrcModuleInfo.gmk ! make/HotspotWrapper.gmk ! make/Images.gmk ! make/Javadoc.gmk ! make/Jprt.gmk ! make/JrtfsJar.gmk ! make/Main.gmk ! make/MainSupport.gmk ! make/StripBinaries.gmk ! make/common/CORE_PKGS.gmk ! make/common/JavaCompilation.gmk ! make/common/MakeBase.gmk ! make/common/Modules.gmk ! make/common/NativeCompilation.gmk ! make/common/SetupJavaCompilers.gmk - modules.xml ! test/lib/sun/hotspot/WhiteBox.java From mandy.chung at oracle.com Thu Mar 17 20:01:06 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 17 Mar 2016 20:01:06 +0000 Subject: hg: jigsaw/m3/corba: 8142968: Module System implementation Message-ID: <201603172001.u2HK16H7005280@aojmv0008.oracle.com> Changeset: 2bb92dd44275 Author: alanb Date: 2016-03-17 19:03 +0000 URL: http://hg.openjdk.java.net/jigsaw/m3/corba/rev/2bb92dd44275 8142968: Module System implementation Summary: Initial integration of JEP 200, JEP 260, JEP 261, and JEP 282 Reviewed-by: alanb, mchung Contributed-by: alan.bateman at oracle.com, alex.buckley at oracle.com, jonathan.gibbons at oracle.com, karen.kinnear at oracle.com, mandy.chung at oracle.com, mark.reinhold at oracle.com, daniel.fuchs at oracle.com, erik.joelsson at oracle.com ! make/gensrc/Gensrc-java.corba.gmk + src/java.corba/share/classes/module-info.java From mandy.chung at oracle.com Thu Mar 17 20:01:24 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 17 Mar 2016 20:01:24 +0000 Subject: hg: jigsaw/m3/hotspot: 8142968: Module System implementation Message-ID: <201603172001.u2HK1OpU005658@aojmv0008.oracle.com> Changeset: c558850fac57 Author: alanb Date: 2016-03-17 19:04 +0000 URL: http://hg.openjdk.java.net/jigsaw/m3/hotspot/rev/c558850fac57 8142968: Module System implementation Summary: Initial integration of JEP 200, JEP 260, JEP 261, and JEP 282 Reviewed-by: acorn, ccheung, coleenp, ctornqvi, dholmes, dsimms, gtriantafill, iklam, jiangli, mgronlun, mseledtsov, cjplummer, sspitsyn, stefank, twisti, hseigel, lfoltan, alanb, mchung, dfazunen Contributed-by: alan.bateman at oracle.com, alex.buckley at oracle.com, jonathan.gibbons at oracle.com, karen.kinnear at oracle.com, mandy.chung at oracle.com, mark.reinhold at oracle.com, harold.seigel at oracle.com, lois.foltan at oracle.com, calvin.cheung at oracle.com, christian.tornqvist at oracle.com, erik.joelsson at oracle.com, george.triantafillou at oracle.com, igor.ignatyev at oracle.com, ioi.lam at oracle.com, james.laskey at oracle.com, jean-francois.denise at oracle.com, jiangli.zhou at oracle.com, markus.gronlund at oracle.com, serguei.spitsyn at oracle.com, staffan.larsen at oracle.com, sundararajan.athijegannathan at oracle.com ! make/share/makefiles/mapfile-vers ! make/test/JtregNative.gmk + src/jdk.hotspot.agent/share/classes/module-info.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/ClassLoaderStats.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/FinalizerInfo.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/HeapDumper.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/JInfo.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/JStack.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/ObjectHistogram.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/PMap.java - src/jdk.vm.ci/share/classes/META-INF/services/jdk.vm.ci.hotspot.HotSpotJVMCIBackendFactory + src/jdk.vm.ci/share/classes/module-info.java ! src/os/posix/dtrace/hotspot_jni.d ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoader.hpp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/classfile/classLoaderExt.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/javaClasses.inline.hpp ! src/share/vm/classfile/jimage.hpp ! src/share/vm/classfile/klassFactory.cpp + src/share/vm/classfile/moduleEntry.cpp + src/share/vm/classfile/moduleEntry.hpp + src/share/vm/classfile/modules.cpp + src/share/vm/classfile/modules.hpp + src/share/vm/classfile/packageEntry.cpp + src/share/vm/classfile/packageEntry.hpp ! src/share/vm/classfile/sharedPathsMiscInfo.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/systemDictionaryShared.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/jvmci/jvmciEnv.cpp ! src/share/vm/logging/logTag.hpp ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/filemap.hpp ! src/share/vm/memory/metaspaceShared.cpp ! src/share/vm/memory/metaspaceShared.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/arrayKlass.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/typeArrayKlass.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/precompiled/precompiled.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jni.h ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/jvmti.xml ! src/share/vm/prims/jvmti.xsl ! src/share/vm/prims/jvmtiEnter.xsl ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiEnvBase.hpp ! src/share/vm/prims/jvmtiEventController.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiH.xsl ! src/share/vm/prims/jvmtiLib.xsl ! src/share/vm/prims/jvmtiManageCapabilities.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/jniHandles.cpp ! src/share/vm/runtime/jniHandles.hpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/reflection.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/statSampler.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/services/jmm.h ! src/share/vm/services/management.cpp + src/share/vm/trace/traceBackend.cpp ! src/share/vm/trace/traceDataTypes.hpp ! src/share/vm/trace/traceMacros.hpp ! src/share/vm/trace/tracetypes.xml ! src/share/vm/utilities/dtrace_disabled.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/utf8.cpp ! src/share/vm/utilities/utf8.hpp ! test/TEST.ROOT ! test/compiler/dependencies/MonomorphicObjectCall/TestMonomorphicObjectCall.java ! test/compiler/jsr292/CallSiteDepContextTest.java ! test/compiler/jsr292/NonInlinedCall/Agent.java ! test/compiler/jsr292/NonInlinedCall/GCTest.java ! test/compiler/jsr292/NonInlinedCall/InvokeTest.java - test/compiler/jsr292/NonInlinedCall/NonInlinedReinvoker.java ! test/compiler/jsr292/NonInlinedCall/RedefineTest.java + test/compiler/jsr292/patches/java.base/java/lang/invoke/MethodHandleHelper.java ! test/compiler/jvmci/SecurityRestrictionsTest.java ! test/compiler/jvmci/code/DataPatchTest.java ! test/compiler/jvmci/code/SimpleCodeInstallationTest.java ! test/compiler/jvmci/code/SimpleDebugInfoTest.java ! test/compiler/jvmci/code/VirtualObjectDebugInfoTest.java ! test/compiler/jvmci/common/CTVMUtilities.java - test/compiler/jvmci/common/CompilerToVMHelper.java - test/compiler/jvmci/common/PublicMetaspaceWrapperObject.java + test/compiler/jvmci/common/patches/jdk.vm.ci/jdk/vm/ci/hotspot/CompilerToVMHelper.java + test/compiler/jvmci/common/patches/jdk.vm.ci/jdk/vm/ci/hotspot/MetaAccessWrapper.java + test/compiler/jvmci/common/patches/jdk.vm.ci/jdk/vm/ci/hotspot/PublicMetaspaceWrapperObject.java ! test/compiler/jvmci/compilerToVM/AllocateCompileIdTest.java ! test/compiler/jvmci/compilerToVM/CanInlineMethodTest.java ! test/compiler/jvmci/compilerToVM/CollectCountersTest.java ! test/compiler/jvmci/compilerToVM/DebugOutputTest.java ! test/compiler/jvmci/compilerToVM/DisassembleCodeBlobTest.java ! test/compiler/jvmci/compilerToVM/DoNotInlineOrCompileTest.java ! test/compiler/jvmci/compilerToVM/ExecuteInstalledCodeTest.java ! test/compiler/jvmci/compilerToVM/FindUniqueConcreteMethodTest.java ! test/compiler/jvmci/compilerToVM/GetBytecodeTest.java ! test/compiler/jvmci/compilerToVM/GetClassInitializerTest.java ! test/compiler/jvmci/compilerToVM/GetConstantPoolTest.java ! test/compiler/jvmci/compilerToVM/GetExceptionTableTest.java ! test/compiler/jvmci/compilerToVM/GetImplementorTest.java ! test/compiler/jvmci/compilerToVM/GetLineNumberTableTest.java ! test/compiler/jvmci/compilerToVM/GetLocalVariableTableTest.java ! test/compiler/jvmci/compilerToVM/GetMaxCallTargetOffsetTest.java ! test/compiler/jvmci/compilerToVM/GetNextStackFrameTest.java ! test/compiler/jvmci/compilerToVM/GetResolvedJavaMethodAtSlotTest.java ! test/compiler/jvmci/compilerToVM/GetResolvedJavaMethodTest.java ! test/compiler/jvmci/compilerToVM/GetResolvedJavaTypeTest.java ! test/compiler/jvmci/compilerToVM/GetStackTraceElementTest.java ! test/compiler/jvmci/compilerToVM/GetSymbolTest.java ! test/compiler/jvmci/compilerToVM/GetVtableIndexForInterfaceTest.java ! test/compiler/jvmci/compilerToVM/HasCompiledCodeForOSRTest.java ! test/compiler/jvmci/compilerToVM/HasFinalizableSubclassTest.java ! test/compiler/jvmci/compilerToVM/InitializeConfigurationTest.java ! test/compiler/jvmci/compilerToVM/InvalidateInstalledCodeTest.java ! test/compiler/jvmci/compilerToVM/IsMatureTest.java ! test/compiler/jvmci/compilerToVM/LookupKlassInPoolTest.java ! test/compiler/jvmci/compilerToVM/LookupKlassRefIndexInPoolTest.java ! test/compiler/jvmci/compilerToVM/LookupMethodInPoolTest.java ! test/compiler/jvmci/compilerToVM/LookupNameAndTypeRefIndexInPoolTest.java ! test/compiler/jvmci/compilerToVM/LookupNameInPoolTest.java ! test/compiler/jvmci/compilerToVM/LookupSignatureInPoolTest.java ! test/compiler/jvmci/compilerToVM/LookupTypeTest.java ! test/compiler/jvmci/compilerToVM/MaterializeVirtualObjectTest.java ! test/compiler/jvmci/compilerToVM/MethodIsIgnoredBySecurityStackWalkTest.java ! test/compiler/jvmci/compilerToVM/ReadUncompressedOopTest.java ! test/compiler/jvmci/compilerToVM/ReprofileTest.java ! test/compiler/jvmci/compilerToVM/ResolveConstantInPoolTest.java ! test/compiler/jvmci/compilerToVM/ResolveFieldInPoolTest.java ! test/compiler/jvmci/compilerToVM/ResolveMethodTest.java ! test/compiler/jvmci/compilerToVM/ResolvePossiblyCachedConstantInPoolTest.java ! test/compiler/jvmci/compilerToVM/ResolveTypeInPoolTest.java ! test/compiler/jvmci/compilerToVM/ShouldDebugNonSafepointsTest.java ! test/compiler/jvmci/compilerToVM/ShouldInlineMethodTest.java ! test/compiler/jvmci/events/JvmciCreateMetaAccessContextTest.java ! test/compiler/jvmci/events/JvmciNotifyInstallEventTest.java - test/compiler/jvmci/events/MetaAccessWrapper.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/ConstantTest.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/RedefineClassTest.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestConstantReflectionProvider.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestJavaField.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestJavaMethod.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestJavaType.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestMetaAccessProvider.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaField.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaMethod.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java ! test/compiler/stable/StableConfiguration.java ! test/compiler/stable/TestStableBoolean.java ! test/compiler/stable/TestStableByte.java ! test/compiler/stable/TestStableChar.java ! test/compiler/stable/TestStableDouble.java ! test/compiler/stable/TestStableFloat.java ! test/compiler/stable/TestStableInt.java ! test/compiler/stable/TestStableLong.java ! test/compiler/stable/TestStableMemoryBarrier.java ! test/compiler/stable/TestStableObject.java ! test/compiler/stable/TestStableShort.java ! test/compiler/unsafe/UnsafeGetConstantField.java ! test/gc/TestSmallHeap.java + test/gc/metaspace/PerfCounter.java + test/gc/metaspace/PerfCounters.java ! test/runtime/BadObjectClass/BootstrapRedefine.java - test/runtime/BadObjectClass/Object.java + test/runtime/BootClassAppendProp/BootClassPathAppend.java + test/runtime/BootClassAppendProp/BootClassPathAppendProp.java + test/runtime/BootClassAppendProp/SunBootClassPath.java ! test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java ! test/runtime/CommandLine/OptionsValidation/TestOptionsWithRangesDynamic.java ! test/runtime/SharedArchiveFile/BasicJarBuilder.java + test/runtime/SharedArchiveFile/BootAppendTests.java + test/runtime/SharedArchiveFile/LoadClass.java ! test/runtime/SharedArchiveFile/PrintSharedArchiveAndExit.java ! test/runtime/SharedArchiveFile/SharedStrings.java + test/runtime/SharedArchiveFile/javax/sound/sampled/MyClass.jasm + test/runtime/SharedArchiveFile/nonjdk/myPackage/MyClass.java + test/runtime/SharedArchiveFile/org/omg/CORBA/Context.jasm + test/runtime/getSysPackage/GetSysPkgTest.java + test/runtime/logging/ModulesTest.java + test/runtime/modules/AccModuleTest.java + test/runtime/modules/AccessCheck/CheckRead.java + test/runtime/modules/AccessCheck/DiffCL_CheckRead.java + test/runtime/modules/AccessCheck/DiffCL_ExpQualOther.java + test/runtime/modules/AccessCheck/DiffCL_ExpQualToM1.java + test/runtime/modules/AccessCheck/DiffCL_ExpUnqual.java + test/runtime/modules/AccessCheck/DiffCL_PkgNotExp.java + test/runtime/modules/AccessCheck/DiffCL_Umod.java + test/runtime/modules/AccessCheck/DiffCL_UmodUpkg.java + test/runtime/modules/AccessCheck/ExpQualOther.java + test/runtime/modules/AccessCheck/ExpQualToM1.java + test/runtime/modules/AccessCheck/ExpUnqual.java + test/runtime/modules/AccessCheck/ExportAllUnnamed.java + test/runtime/modules/AccessCheck/ModuleLibrary.java + test/runtime/modules/AccessCheck/PkgNotExp.java + test/runtime/modules/AccessCheck/Umod.java + test/runtime/modules/AccessCheck/UmodDiffCL_ExpQualOther.java + test/runtime/modules/AccessCheck/UmodDiffCL_ExpUnqual.java + test/runtime/modules/AccessCheck/UmodDiffCL_PkgNotExp.java + test/runtime/modules/AccessCheck/UmodDiffCL_Umod.java + test/runtime/modules/AccessCheck/UmodDiffCL_UmodUpkg.java + test/runtime/modules/AccessCheck/UmodUPkg.java + test/runtime/modules/AccessCheck/UmodUpkgDiffCL_ExpQualOther.java + test/runtime/modules/AccessCheck/UmodUpkgDiffCL_NotExp.java + test/runtime/modules/AccessCheck/UmodUpkgDiffCL_Umod.java + test/runtime/modules/AccessCheck/UmodUpkg_ExpQualOther.java + test/runtime/modules/AccessCheck/UmodUpkg_NotExp.java + test/runtime/modules/AccessCheck/UmodUpkg_Umod.java + test/runtime/modules/AccessCheck/Umod_ExpQualOther.java + test/runtime/modules/AccessCheck/Umod_ExpUnqual.java + test/runtime/modules/AccessCheck/Umod_PkgNotExp.java + test/runtime/modules/AccessCheck/Umod_UmodUpkg.java + test/runtime/modules/AccessCheck/c4.java + test/runtime/modules/AccessCheck/c5.java + test/runtime/modules/AccessCheck/myloaders/MyDiffClassLoader.java + test/runtime/modules/AccessCheck/myloaders/MySameClassLoader.java + test/runtime/modules/AccessCheck/p1/c1.java + test/runtime/modules/AccessCheck/p1/c1Loose.java + test/runtime/modules/AccessCheck/p1/c1ReadEdge.java + test/runtime/modules/AccessCheck/p1/c1ReadEdgeDiffLoader.java + test/runtime/modules/AccessCheck/p2/c2.java + test/runtime/modules/AccessCheck/p3/c3.jcod + test/runtime/modules/AccessCheck/p3/c3ReadEdge.jcod + test/runtime/modules/AccessCheck/p3/c3ReadEdgeDiffLoader.jcod + test/runtime/modules/AccessCheck/p6/c6.java + test/runtime/modules/AccessCheckAllUnnamed.java + test/runtime/modules/AccessCheckExp.java + test/runtime/modules/AccessCheckJavaBase.java + test/runtime/modules/AccessCheckRead.java + test/runtime/modules/AccessCheckSuper.java + test/runtime/modules/AccessCheckUnnamed.java + test/runtime/modules/AccessCheckWorks.java + test/runtime/modules/CCE_module_msg.java + test/runtime/modules/ExportTwice.java + test/runtime/modules/JVMAddModuleExportToAllUnnamed.java + test/runtime/modules/JVMAddModuleExports.java + test/runtime/modules/JVMAddModuleExportsToAll.java + test/runtime/modules/JVMAddModulePackage.java + test/runtime/modules/JVMAddReadsModule.java + test/runtime/modules/JVMCanReadModule.java + test/runtime/modules/JVMDefineModule.java + test/runtime/modules/JVMGetModuleByPkgName.java + test/runtime/modules/JVMIsExportedToModule.java + test/runtime/modules/LoadUnloadModuleStress.java + test/runtime/modules/ModuleHelper.java + test/runtime/modules/Visibility/XbootcpNoVisibility.java + test/runtime/modules/Visibility/XbootcpVisibility.java + test/runtime/modules/Visibility/XpatchVisibility.java + test/runtime/modules/Xpatch/Xpatch2Dirs.java + test/runtime/modules/Xpatch/Xpatch2DirsMain.java + test/runtime/modules/Xpatch/XpatchMain.java + test/runtime/modules/Xpatch/XpatchTest.java + test/runtime/modules/Xpatch/XpatchTraceCL.java + test/runtime/modules/XpatchCDS.java + test/runtime/modules/acc_module.jcod + test/runtime/modules/getModuleJNI/GetModule.java + test/runtime/modules/getModuleJNI/libGetModule.c + test/runtime/modules/java.base/java/lang/reflect/ModuleHelper.java + test/runtime/modules/p1/c1.java + test/runtime/modules/p2/c2.java + test/runtime/modules/p3/c3.java ! test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java ! test/testlibrary/ClassFileInstaller.java ! test/testlibrary/jdk/test/lib/InMemoryJavaCompiler.java - test/testlibrary/jdk/test/lib/PerfCounter.java - test/testlibrary/jdk/test/lib/PerfCounters.java ! test/testlibrary/jdk/test/lib/cli/CommandLineOptionTest.java + test/testlibrary/whitebox/sun/hotspot/WhiteBox.java From mandy.chung at oracle.com Thu Mar 17 20:02:23 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 17 Mar 2016 20:02:23 +0000 Subject: hg: jigsaw/m3/jaxp: 8142968: Module System implementation Message-ID: <201603172002.u2HK2NER006474@aojmv0008.oracle.com> Changeset: 27a3d65e1580 Author: alanb Date: 2016-03-17 19:04 +0000 URL: http://hg.openjdk.java.net/jigsaw/m3/jaxp/rev/27a3d65e1580 8142968: Module System implementation Summary: Initial integration of JEP 200, JEP 260, JEP 261, and JEP 282 Reviewed-by: alanb, mchung, joehw Contributed-by: alan.bateman at oracle.com, alex.buckley at oracle.com, jonathan.gibbons at oracle.com, karen.kinnear at oracle.com, mandy.chung at oracle.com, mark.reinhold at oracle.com, daniel.fuchs at oracle.com, erik.joelsson at oracle.com ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Constants.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/XSLTC.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/compiler/FunctionTable.java + src/java.xml/share/classes/module-info.java + src/jdk.xml.dom/share/classes/module-info.java ! test/TEST.ROOT ! test/javax/xml/jaxp/unittest/TEST.properties From mandy.chung at oracle.com Thu Mar 17 20:02:26 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 17 Mar 2016 20:02:26 +0000 Subject: hg: jigsaw/m3/jaxws: 8142968: Module System implementation Message-ID: <201603172002.u2HK2Qcs006526@aojmv0008.oracle.com> Changeset: 4d5296e0920a Author: alanb Date: 2016-03-17 19:04 +0000 URL: http://hg.openjdk.java.net/jigsaw/m3/jaxws/rev/4d5296e0920a 8142968: Module System implementation Summary: Initial integration of JEP 200, JEP 260, JEP 261, and JEP 282 Reviewed-by: lancea, mchung Contributed-by: alan.bateman at oracle.com, alex.buckley at oracle.com, jonathan.gibbons at oracle.com, karen.kinnear at oracle.com, mandy.chung at oracle.com, mark.reinhold at oracle.com, miroslav.kos at oracle.com, erik.joelsson at oracle.com ! src/java.activation/share/classes/javax/activation/DataContentHandler.java ! src/java.activation/share/classes/javax/activation/MailcapCommandMap.java + src/java.activation/share/classes/module-info.java + src/java.annotations.common/share/classes/module-info.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/ClassFactory.java + src/java.xml.bind/share/classes/module-info.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/transport/http/server/EndpointImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/util/HandlerAnnotationProcessor.java + src/java.xml.ws/share/classes/module-info.java ! src/jdk.xml.bind/share/classes/com/sun/codemodel/internal/fmt/JStaticJavaFile.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/generator/bean/BeanGenerator.java + src/jdk.xml.bind/share/classes/module-info.java + src/jdk.xml.ws/share/classes/module-info.java From mandy.chung at oracle.com Thu Mar 17 20:02:33 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 17 Mar 2016 20:02:33 +0000 Subject: hg: jigsaw/m3/jdk: 8142968: Module System implementation Message-ID: <201603172002.u2HK2XRH006581@aojmv0008.oracle.com> Changeset: b2a69d66dc65 Author: alanb Date: 2016-03-17 19:04 +0000 URL: http://hg.openjdk.java.net/jigsaw/m3/jdk/rev/b2a69d66dc65 8142968: Module System implementation Summary: Initial integration of JEP 200, JEP 260, JEP 261, and JEP 282 Reviewed-by: alanb, mchung, naoto, rriggs, psandoz, plevart, mullan, ascarpino, vinnie, prr, sherman, dfuchs, mhaupt Contributed-by: alan.bateman at oracle.com, alex.buckley at oracle.com, jonathan.gibbons at oracle.com, karen.kinnear at oracle.com, mandy.chung at oracle.com, mark.reinhold at oracle.com, chris.hegarty at oracle.com, alexandr.scherbatiy at oracle.com, amy.lu at oracle.com, calvin.cheung at oracle.com, daniel.fuchs at oracle.com, erik.joelsson at oracle.com, harold.seigel at oracle.com, jaroslav.bachorik at oracle.com, jean-francois.denise at oracle.com, jan.lahoda at oracle.com, james.laskey at oracle.com, lois.foltan at oracle.com, miroslav.kos at oracle.com, huaming.li at oracle.com, sean.mullan at oracle.com, naoto.sato at oracle.com, masayoshi.okutsu at oracle.com, peter.levart at gmail.com, philip.race at oracle.com, claes.redestad at oracle.com, sergey.bylokhov at oracle.com, alexandre.iline at oracle.com, volker.simonis at gmail.com, staffan.larsen at oracle.com, stuart.marks at oracle.com, semyon.sadetsky at oracle.com, serguei.spitsyn at oracle.com, sundararajan.athijegannathan at oracle.com, valerie.peng at oracle.com, vincent.x.ryan at oracle.com, weijun.wang at oracle.co! m, yuri.nesterenko at oracle.com, yekaterina.kantserova at oracle.com, alexander.kulyakhtin at oracle.com, felix.yang at oracle.com, andrei.eremeev at oracle.com, frank.yuan at oracle.com, sergei.pikalev at oracle.com, sibabrata.sahoo at oracle.com, tiantian.du at oracle.com, sha.jiang at oracle.com ! make/CompileInterimRmic.gmk ! make/CompileTools.gmk + make/GenerateModuleSummary.gmk + make/ModuleTools.gmk ! make/Tools.gmk ! make/copy/Copy-java.base.gmk ! make/data/jdwp/jdwp.spec - make/gendata/Gendata-jdk.jdeps.gmk ! make/gendata/GendataBreakIterator.gmk ! make/gensrc/Gensrc-java.base.gmk - make/gensrc/Gensrc-jdk.dev.gmk ! make/gensrc/Gensrc-jdk.jdi.gmk + make/gensrc/Gensrc-jdk.jlink.gmk - make/gensrc/Gensrc-jdk.jvmstat.gmk ! make/gensrc/GensrcLocaleData.gmk + make/gensrc/GensrcModuleLoaderMap.gmk ! make/launcher/Launcher-java.desktop.gmk - make/launcher/Launcher-jdk.dev.gmk + make/launcher/Launcher-jdk.jlink.gmk ! make/launcher/Launcher-jdk.pack200.gmk ! make/launcher/Launcher-jdk.rmic.gmk ! make/launcher/LauncherCommon.gmk ! make/lib/CoreLibraries.gmk ! make/lib/Lib-java.instrument.gmk ! make/mapfiles/libjava/mapfile-vers ! make/mapfiles/libjimage/mapfile-vers ! make/rmic/Rmic-java.management.gmk ! make/rmic/RmicCommon.gmk - make/scripts/localelist.sh ! make/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java ! make/src/classes/build/tools/generatebreakiteratordata/GenerateBreakIteratorData.java + make/src/classes/build/tools/jdwpgen/ModuleTypeNode.java ! make/src/classes/build/tools/jdwpgen/Parse.java + make/src/classes/build/tools/jigsaw/GenGraphs.java + make/src/classes/build/tools/jigsaw/Graph.java + make/src/classes/build/tools/jigsaw/ModuleSummary.java + make/src/classes/build/tools/jigsaw/technology-summary.html - make/src/classes/build/tools/module/GenJdepsModulesXml.java + make/src/classes/build/tools/module/GenModuleInfoSource.java + make/src/classes/build/tools/module/GenModuleLoaderMap.java - make/src/classes/build/tools/module/GenModulesList.java - make/src/classes/build/tools/module/ImageBuilder.java ! make/src/classes/build/tools/module/Module.java - make/src/classes/build/tools/module/ModuleArchive.java + make/src/classes/build/tools/module/ModuleInfoReader.java - make/src/classes/build/tools/module/boot.modules - make/src/classes/build/tools/module/ext.modules ! src/demo/share/java2d/J2DBench/src/j2dbench/ResultSet.java + src/java.base/macosx/classes/module-info.java.extra ! src/java.base/share/classes/com/sun/java/util/jar/pack/intrinsic.properties ! src/java.base/share/classes/java/io/ObjectInputStream.java ! 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/NamedPackage.java ! src/java.base/share/classes/java/lang/Package.java ! src/java.base/share/classes/java/lang/StackFrameInfo.java ! src/java.base/share/classes/java/lang/StackTraceElement.java ! src/java.base/share/classes/java/lang/StackWalker.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/java.base/share/classes/java/lang/invoke/MemberName.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java + src/java.base/share/classes/java/lang/module/Configuration.java + src/java.base/share/classes/java/lang/module/Dependence.java + src/java.base/share/classes/java/lang/module/FindException.java + src/java.base/share/classes/java/lang/module/InvalidModuleDescriptorException.java + src/java.base/share/classes/java/lang/module/ModuleDescriptor.java + src/java.base/share/classes/java/lang/module/ModuleFinder.java + src/java.base/share/classes/java/lang/module/ModuleInfo.java + src/java.base/share/classes/java/lang/module/ModulePath.java + src/java.base/share/classes/java/lang/module/ModuleReader.java + src/java.base/share/classes/java/lang/module/ModuleReference.java + src/java.base/share/classes/java/lang/module/ModuleReferences.java + src/java.base/share/classes/java/lang/module/ResolutionException.java + src/java.base/share/classes/java/lang/module/ResolvedModule.java + src/java.base/share/classes/java/lang/module/Resolver.java + src/java.base/share/classes/java/lang/module/SystemModuleFinder.java + src/java.base/share/classes/java/lang/module/package-info.java ! src/java.base/share/classes/java/lang/ref/Finalizer.java ! src/java.base/share/classes/java/lang/reflect/AccessibleObject.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/InaccessibleObjectException.java + src/java.base/share/classes/java/lang/reflect/Layer.java + src/java.base/share/classes/java/lang/reflect/LayerInstantiationException.java ! src/java.base/share/classes/java/lang/reflect/Method.java + src/java.base/share/classes/java/lang/reflect/Module.java ! src/java.base/share/classes/java/lang/reflect/Proxy.java ! src/java.base/share/classes/java/lang/reflect/package-info.java ! src/java.base/share/classes/java/net/URL.java ! src/java.base/share/classes/java/net/URLClassLoader.java ! src/java.base/share/classes/java/nio/Bits.java ! src/java.base/share/classes/java/nio/file/FileSystems.java ! src/java.base/share/classes/java/nio/file/Files.java ! src/java.base/share/classes/java/util/ResourceBundle.java ! src/java.base/share/classes/java/util/ServiceLoader.java + src/java.base/share/classes/java/util/spi/AbstractResourceBundleProvider.java ! src/java.base/share/classes/java/util/spi/ResourceBundleControlProvider.java + src/java.base/share/classes/java/util/spi/ResourceBundleProvider.java ! src/java.base/share/classes/javax/crypto/JceSecurity.java ! src/java.base/share/classes/javax/crypto/SealedObject.java - src/java.base/share/classes/jdk/internal/jimage/Archive.java ! src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java - src/java.base/share/classes/jdk/internal/jimage/BasicImageWriter.java - src/java.base/share/classes/jdk/internal/jimage/ExternalFilesWriter.java ! src/java.base/share/classes/jdk/internal/jimage/ImageBufferCache.java - src/java.base/share/classes/jdk/internal/jimage/ImageFileCreator.java ! src/java.base/share/classes/jdk/internal/jimage/ImageHeader.java - src/java.base/share/classes/jdk/internal/jimage/ImageJavaSubstrate.java ! src/java.base/share/classes/jdk/internal/jimage/ImageLocation.java - src/java.base/share/classes/jdk/internal/jimage/ImageLocationBase.java - src/java.base/share/classes/jdk/internal/jimage/ImageLocationWriter.java - src/java.base/share/classes/jdk/internal/jimage/ImageModuleData.java - src/java.base/share/classes/jdk/internal/jimage/ImageModuleDataWriter.java - src/java.base/share/classes/jdk/internal/jimage/ImageNativeSubstrate.java ! src/java.base/share/classes/jdk/internal/jimage/ImageReader.java ! src/java.base/share/classes/jdk/internal/jimage/ImageReaderFactory.java - src/java.base/share/classes/jdk/internal/jimage/ImageResourcesTree.java ! src/java.base/share/classes/jdk/internal/jimage/ImageStream.java ! src/java.base/share/classes/jdk/internal/jimage/ImageStrings.java ! src/java.base/share/classes/jdk/internal/jimage/ImageStringsReader.java - src/java.base/share/classes/jdk/internal/jimage/ImageStringsWriter.java - src/java.base/share/classes/jdk/internal/jimage/ImageSubstrate.java + src/java.base/share/classes/jdk/internal/jimage/NativeImageBuffer.java - src/java.base/share/classes/jdk/internal/jimage/PerfectHashBuilder.java - src/java.base/share/classes/jdk/internal/jimage/ResourcePool.java - src/java.base/share/classes/jdk/internal/jimage/ResourcePoolImpl.java - src/java.base/share/classes/jdk/internal/jimage/StringTable.java - src/java.base/share/classes/jdk/internal/jimage/UTF8String.java + src/java.base/share/classes/jdk/internal/jimage/decompressor/CompressIndexes.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/CompressedResourceHeader.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/Decompressor.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/ResourceDecompressor.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/ResourceDecompressorFactory.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/ResourceDecompressorRepository.java + src/java.base/share/classes/jdk/internal/jimage/decompressor/SignatureParser.java + src/java.base/share/classes/jdk/internal/jimage/decompressor/StringSharingDecompressor.java + src/java.base/share/classes/jdk/internal/jimage/decompressor/StringSharingDecompressorFactory.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/ZipDecompressor.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/ZipDecompressorFactory.java + src/java.base/share/classes/jdk/internal/jrtfs/AbstractJrtFileAttributes.java + src/java.base/share/classes/jdk/internal/jrtfs/AbstractJrtFileSystem.java + src/java.base/share/classes/jdk/internal/jrtfs/AbstractJrtPath.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtDirectoryStream.java + src/java.base/share/classes/jdk/internal/jrtfs/JrtExplodedFileAttributes.java + src/java.base/share/classes/jdk/internal/jrtfs/JrtExplodedFileSystem.java + src/java.base/share/classes/jdk/internal/jrtfs/JrtExplodedPath.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtFileAttributeView.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtFileAttributes.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtFileStore.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtFileSystem.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtFileSystemProvider.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtPath.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtUtils.java ! src/java.base/share/classes/jdk/internal/jrtfs/SystemImages.java ! src/java.base/share/classes/jdk/internal/jrtfs/jrtfsviewer.js ! src/java.base/share/classes/jdk/internal/jrtfs/jrtls.js + src/java.base/share/classes/jdk/internal/loader/BootLoader.java + src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java + src/java.base/share/classes/jdk/internal/loader/ClassLoaders.java + src/java.base/share/classes/jdk/internal/loader/Loader.java + src/java.base/share/classes/jdk/internal/loader/LoaderPool.java ! src/java.base/share/classes/jdk/internal/misc/JavaLangAccess.java + src/java.base/share/classes/jdk/internal/misc/JavaLangModuleAccess.java + src/java.base/share/classes/jdk/internal/misc/JavaLangReflectModuleAccess.java + src/java.base/share/classes/jdk/internal/misc/JavaUtilResourceBundleAccess.java ! src/java.base/share/classes/jdk/internal/misc/SharedSecrets.java ! src/java.base/share/classes/jdk/internal/misc/VM.java + src/java.base/share/classes/jdk/internal/module/Builder.java + src/java.base/share/classes/jdk/internal/module/Checks.java + src/java.base/share/classes/jdk/internal/module/ClassFileAttributes.java + src/java.base/share/classes/jdk/internal/module/ClassFileConstants.java + src/java.base/share/classes/jdk/internal/module/ConfigurableModuleFinder.java + src/java.base/share/classes/jdk/internal/module/Hasher.java + src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java + src/java.base/share/classes/jdk/internal/module/ModuleInfoExtender.java + src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java + src/java.base/share/classes/jdk/internal/module/ModuleLoaderMap.java + src/java.base/share/classes/jdk/internal/module/ModulePatcher.java + src/java.base/share/classes/jdk/internal/module/Modules.java + src/java.base/share/classes/jdk/internal/module/ServicesCatalog.java + src/java.base/share/classes/jdk/internal/module/SystemModules.java ! src/java.base/share/classes/jdk/internal/perf/PerfCounter.java + src/java.base/share/classes/jdk/internal/vm/cds/resources/ModuleLoaderMap.dat + src/java.base/share/classes/module-info.java ! src/java.base/share/classes/sun/invoke/util/VerifyAccess.java ! src/java.base/share/classes/sun/launcher/LauncherHelper.java ! src/java.base/share/classes/sun/launcher/resources/launcher.properties - src/java.base/share/classes/sun/misc/Launcher.java ! src/java.base/share/classes/sun/misc/URLClassPath.java + src/java.base/share/classes/sun/net/www/protocol/jmod/Handler.java ! src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java ! src/java.base/share/classes/sun/reflect/Reflection.java ! src/java.base/share/classes/sun/reflect/misc/MethodUtil.java ! src/java.base/share/classes/sun/reflect/misc/ReflectUtil.java ! src/java.base/share/classes/sun/security/jca/ProviderList.java ! src/java.base/share/classes/sun/security/jca/Providers.java ! src/java.base/share/classes/sun/security/provider/PolicyFile.java ! src/java.base/share/classes/sun/security/util/SecurityConstants.java + src/java.base/share/classes/sun/text/resources/BreakIteratorInfoProvider.java + src/java.base/share/classes/sun/text/resources/BreakIteratorRulesProvider.java + src/java.base/share/classes/sun/text/resources/CollationDataProvider.java + src/java.base/share/classes/sun/text/resources/FormatDataProvider.java + src/java.base/share/classes/sun/text/resources/JavaTimeSupplementaryProvider.java + src/java.base/share/classes/sun/text/resources/cldr/FormatDataProvider.java - src/java.base/share/classes/sun/util/CoreResourceBundleControl-XLocales.java.template ! src/java.base/share/classes/sun/util/locale/provider/BreakDictionary.java ! src/java.base/share/classes/sun/util/locale/provider/BreakIteratorProviderImpl.java ! src/java.base/share/classes/sun/util/locale/provider/DictionaryBasedBreakIterator.java ! src/java.base/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java ! src/java.base/share/classes/sun/util/locale/provider/LocaleResources.java + src/java.base/share/classes/sun/util/locale/provider/ResourceBundleProviderSupport.java ! src/java.base/share/classes/sun/util/locale/provider/RuleBasedBreakIterator.java + src/java.base/share/classes/sun/util/resources/Bundles.java + src/java.base/share/classes/sun/util/resources/CalendarDataProvider.java + src/java.base/share/classes/sun/util/resources/CurrencyNamesProvider.java ! src/java.base/share/classes/sun/util/resources/LocaleData.java + src/java.base/share/classes/sun/util/resources/LocaleDataProvider.java + src/java.base/share/classes/sun/util/resources/LocaleNamesProvider.java + src/java.base/share/classes/sun/util/resources/TimeZoneNamesProvider.java + src/java.base/share/classes/sun/util/resources/cldr/CalendarDataProvider.java + src/java.base/share/classes/sun/util/resources/cldr/CurrencyNamesProvider.java + src/java.base/share/classes/sun/util/resources/cldr/LocaleNamesProvider.java + src/java.base/share/classes/sun/util/resources/cldr/TimeZoneNamesProvider.java ! src/java.base/share/conf/security/java.policy ! src/java.base/share/conf/security/java.security ! src/java.base/share/native/include/jni.h ! src/java.base/share/native/include/jvm.h ! src/java.base/share/native/include/jvmti.h ! src/java.base/share/native/launcher/defines.h ! src/java.base/share/native/launcher/main.c + src/java.base/share/native/libjava/BootLoader.c + src/java.base/share/native/libjava/Module.c - src/java.base/share/native/libjava/Package.c - src/java.base/share/native/libjava/Proxy.c ! src/java.base/share/native/libjava/Reflection.c - src/java.base/share/native/libjimage/ImageNativeSubstrate.cpp + src/java.base/share/native/libjimage/NativeImageBuffer.cpp ! src/java.base/share/native/libjimage/imageDecompressor.cpp ! src/java.base/share/native/libjimage/imageDecompressor.hpp ! src/java.base/share/native/libjimage/imageFile.cpp ! src/java.base/share/native/libjimage/imageFile.hpp ! src/java.base/share/native/libjimage/jimage.cpp ! src/java.base/share/native/libjimage/jimage.hpp ! src/java.base/share/native/libjli/args.c ! src/java.base/share/native/libjli/emessages.h ! src/java.base/share/native/libjli/java.c ! src/java.base/share/native/libjli/java.h + src/java.base/solaris/classes/module-info.java.extra + src/java.base/windows/classes/module-info.java.extra + src/java.compact1/share/classes/module-info.java + src/java.compact2/share/classes/module-info.java + src/java.compact3/share/classes/module-info.java + src/java.datatransfer/share/classes/module-info.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaUtils.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/LWCToolkit.java - src/java.desktop/share/classes/META-INF/services/java.net.ContentHandlerFactory - src/java.desktop/share/classes/META-INF/services/javax.print.PrintServiceLookup - src/java.desktop/share/classes/META-INF/services/javax.print.StreamPrintServiceFactory - src/java.desktop/share/classes/META-INF/services/javax.sound.midi.spi.MidiDeviceProvider - src/java.desktop/share/classes/META-INF/services/javax.sound.midi.spi.MidiFileReader - src/java.desktop/share/classes/META-INF/services/javax.sound.midi.spi.MidiFileWriter - src/java.desktop/share/classes/META-INF/services/javax.sound.midi.spi.SoundbankReader - src/java.desktop/share/classes/META-INF/services/javax.sound.sampled.spi.AudioFileReader - src/java.desktop/share/classes/META-INF/services/javax.sound.sampled.spi.AudioFileWriter - src/java.desktop/share/classes/META-INF/services/javax.sound.sampled.spi.FormatConversionProvider - src/java.desktop/share/classes/META-INF/services/javax.sound.sampled.spi.MixerProvider - src/java.desktop/share/classes/META-INF/services/sun.datatransfer.DesktopDatatransferService ! src/java.desktop/share/classes/com/sun/beans/finder/ConstructorFinder.java ! src/java.desktop/share/classes/com/sun/beans/finder/FieldFinder.java + src/java.desktop/share/classes/com/sun/beans/finder/FinderUtils.java ! src/java.desktop/share/classes/com/sun/beans/finder/MethodFinder.java ! src/java.desktop/share/classes/com/sun/media/sound/JARSoundbankReader.java ! src/java.desktop/share/classes/java/awt/Component.java ! src/java.desktop/share/classes/java/awt/Toolkit.java ! src/java.desktop/share/classes/java/awt/Window.java ! src/java.desktop/share/classes/javax/imageio/ImageReader.java ! src/java.desktop/share/classes/javax/imageio/ImageWriter.java ! src/java.desktop/share/classes/javax/imageio/metadata/IIOMetadata.java ! src/java.desktop/share/classes/javax/imageio/metadata/IIOMetadataFormat.java ! src/java.desktop/share/classes/javax/imageio/metadata/IIOMetadataFormatImpl.java ! src/java.desktop/share/classes/javax/imageio/spi/ImageReaderWriterSpi.java ! src/java.desktop/share/classes/javax/swing/UIDefaults.java ! src/java.desktop/share/classes/javax/swing/text/DefaultFormatter.java ! src/java.desktop/share/classes/javax/swing/text/html/ObjectView.java + src/java.desktop/share/classes/module-info.java ! src/java.desktop/share/classes/sun/applet/AppletSecurity.java ! src/java.desktop/share/classes/sun/awt/datatransfer/TransferableProxy.java + src/java.httpclient/share/classes/module-info.java ! src/java.instrument/share/classes/java/lang/instrument/ClassFileTransformer.java ! src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java ! src/java.instrument/share/classes/java/lang/instrument/package.html + src/java.instrument/share/classes/module-info.java ! src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java ! src/java.instrument/share/classes/sun/instrument/TransformerManager.java ! src/java.instrument/share/native/libinstrument/JPLISAgent.c ! src/java.instrument/share/native/libinstrument/JPLISAgent.h - src/java.logging/share/classes/META-INF/services/jdk.internal.logger.DefaultLoggerFinder ! src/java.logging/share/classes/java/util/logging/Level.java ! src/java.logging/share/classes/java/util/logging/Logger.java + src/java.logging/share/classes/module-info.java ! src/java.management/share/classes/javax/management/remote/rmi/RMIConnector.java + src/java.management/share/classes/module-info.java ! src/java.management/share/classes/sun/management/RuntimeImpl.java ! src/java.management/share/classes/sun/management/StackTraceElementCompositeData.java ! src/java.management/share/classes/sun/management/ThreadInfoCompositeData.java + src/java.management/share/classes/sun/management/TypeVersionMapper.java ! src/java.management/share/classes/sun/management/VMManagementImpl.java ! src/java.management/share/native/include/jmm.h ! src/java.management/share/native/libmanagement/VMManagementImpl.c ! src/java.naming/share/classes/com/sun/jndi/ldap/Obj.java ! src/java.naming/share/classes/com/sun/naming/internal/VersionHelper.java ! src/java.naming/share/classes/javax/naming/ldap/ControlFactory.java ! src/java.naming/share/classes/javax/naming/spi/NamingManager.java ! src/java.naming/share/classes/javax/naming/spi/ObjectFactory.java ! src/java.naming/share/classes/javax/naming/spi/StateFactory.java + src/java.naming/share/classes/module-info.java ! src/java.naming/share/classes/sun/security/provider/certpath/ldap/LDAPCertStoreImpl.java + src/java.prefs/share/classes/module-info.java ! src/java.rmi/share/classes/java/rmi/activation/ActivationID.java + src/java.rmi/share/classes/module-info.java ! src/java.scripting/share/classes/com/sun/tools/script/shell/Main.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.security.jgss/share/classes/META-INF/services/sun.security.ssl.ClientKeyExchangeService + 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/com/sun/rowset/CachedRowSetImpl.java ! src/java.sql.rowset/share/classes/com/sun/rowset/JdbcRowSetResourceBundle.java ! src/java.sql.rowset/share/classes/com/sun/rowset/internal/CachedRowSetWriter.java ! src/java.sql.rowset/share/classes/javax/sql/rowset/RowSetProvider.java ! src/java.sql.rowset/share/classes/javax/sql/rowset/serial/SQLInputImpl.java ! src/java.sql.rowset/share/classes/javax/sql/rowset/spi/SyncFactory.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.accessibility/windows/classes/META-INF/services/javax.accessibility.AccessibilityProvider + src/jdk.accessibility/windows/classes/module-info.java.extra - src/jdk.attach/share/classes/META-INF/services/com.sun.tools.attach.spi.AttachProvider + src/jdk.attach/share/classes/module-info.java - src/jdk.charsets/share/classes/META-INF/services/java.nio.charset.spi.CharsetProvider + src/jdk.charsets/share/classes/module-info.java ! src/jdk.compiler/share/classes/sun/tools/serialver/SerialVer.java + src/jdk.crypto.ec/share/classes/module-info.java + src/jdk.crypto.mscapi/windows/classes/module-info.java ! src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/RSAKeyPairGenerator.java + src/jdk.crypto.pkcs11/share/classes/module-info.java ! src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/SunPKCS11.java + src/jdk.crypto.ucrypto/solaris/classes/module-info.java + src/jdk.deploy.osx/macosx/classes/module-info.java - src/jdk.dev/share/classes/jdk/tools/jimage/ExtractedImage.java - src/jdk.dev/share/classes/jdk/tools/jimage/JImageTask.java - src/jdk.dev/share/classes/jdk/tools/jimage/Main.java - src/jdk.dev/share/classes/jdk/tools/jimage/TaskHelper.java - src/jdk.dev/share/classes/jdk/tools/jimage/resources/jimage.properties + src/jdk.httpserver/share/classes/module-info.java + src/jdk.internal.le/share/classes/module-info.java + src/jdk.internal.opt/share/classes/module-info.java + src/jdk.jartool/share/classes/module-info.java + src/jdk.jartool/share/classes/sun/tools/jar/GNUStyleOptions.java ! src/jdk.jartool/share/classes/sun/tools/jar/Main.java ! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties + src/jdk.jcmd/share/classes/jdk/internal/vm/agent/spi/ToolProvider.java + src/jdk.jcmd/share/classes/jdk/internal/vm/agent/spi/ToolProviderFinder.java + src/jdk.jcmd/share/classes/module-info.java ! src/jdk.jcmd/share/classes/sun/tools/jinfo/JInfo.java ! src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java ! src/jdk.jcmd/share/classes/sun/tools/jstack/JStack.java + src/jdk.jconsole/share/classes/module-info.java - src/jdk.jdi/share/classes/META-INF/services/com.sun.jdi.connect.Connector - src/jdk.jdi/share/classes/META-INF/services/com.sun.jdi.connect.spi.TransportService + src/jdk.jdi/share/classes/com/sun/jdi/InvalidModuleException.java + src/jdk.jdi/share/classes/com/sun/jdi/ModuleReference.java ! src/jdk.jdi/share/classes/com/sun/jdi/ReferenceType.java ! src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/JDWPException.java + src/jdk.jdi/share/classes/com/sun/tools/jdi/ModuleReferenceImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/PacketStream.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ReferenceTypeImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java + src/jdk.jdi/share/classes/module-info.java + src/jdk.jdi/windows/classes/module-info.java.extra + src/jdk.jdwp.agent/share/classes/module-info.java ! src/jdk.jdwp.agent/share/native/libjdwp/JDWP.h + src/jdk.jdwp.agent/share/native/libjdwp/ModuleReferenceImpl.c + src/jdk.jdwp.agent/share/native/libjdwp/ModuleReferenceImpl.h ! src/jdk.jdwp.agent/share/native/libjdwp/ReferenceTypeImpl.c ! src/jdk.jdwp.agent/share/native/libjdwp/VirtualMachineImpl.c ! src/jdk.jdwp.agent/share/native/libjdwp/debugDispatch.c ! src/jdk.jdwp.agent/share/native/libjdwp/inStream.c ! src/jdk.jdwp.agent/share/native/libjdwp/inStream.h ! src/jdk.jdwp.agent/share/native/libjdwp/outStream.c ! src/jdk.jdwp.agent/share/native/libjdwp/outStream.h ! src/jdk.jdwp.agent/share/native/libjdwp/util.c ! src/jdk.jdwp.agent/share/native/libjdwp/util.h + src/jdk.jlink/share/classes/jdk/tools/jimage/ExtractedImage.java + src/jdk.jlink/share/classes/jdk/tools/jimage/JImageTask.java + src/jdk.jlink/share/classes/jdk/tools/jimage/Main.java + src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage.properties + src/jdk.jlink/share/classes/jdk/tools/jlink/Jlink.java + src/jdk.jlink/share/classes/jdk/tools/jlink/JlinkPermission.java + src/jdk.jlink/share/classes/jdk/tools/jlink/builder/DefaultImageBuilder.java + src/jdk.jlink/share/classes/jdk/tools/jlink/builder/ImageBuilder.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Archive.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/BasicImageWriter.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/DirArchive.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageFileCreator.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageLocationWriter.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginConfiguration.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginStack.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageResourcesTree.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageStringsWriter.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JarArchive.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JmodArchive.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Main.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ModularJarArchive.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/PerfectHashBuilder.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/PluginContextImpl.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/PluginOrderingGraph.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/PluginRepository.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/PoolImpl.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ResourcePrevisitor.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/StringTable.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Utils.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/DefaultCompressPlugin.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ExcludeFilesPlugin.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ExcludePlugin.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ExcludeVMPlugin.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/FileCopierPlugin.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/IncludeLocalesPlugin.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/OptimizationPlugin.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/PluginsResourceBundle.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ReleaseInfoPlugin.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ResourceFilter.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SortResourcesPlugin.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/StringSharingPlugin.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/StripDebugPlugin.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/StripNativeCommandsPlugin.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModuleDescriptorPlugin.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ZipPlugin.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/asm/AsmGlobalPool.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/asm/AsmModulePool.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/asm/AsmPlugin.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/asm/AsmPool.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/asm/AsmPoolImpl.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/asm/AsmPools.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/optim/ControlFlow.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/optim/ForNameFolding.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/optim/ReflectionOptimizer.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/optim/Utils.java + src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/ExecutableImage.java + src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/Plugin.java + src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/PluginContext.java + src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/PluginException.java + src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/Pool.java + src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/PostProcessorPlugin.java + src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/TransformerPlugin.java + src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties + src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties + src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java + src/jdk.jlink/share/classes/jdk/tools/jmod/Main.java + src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod.properties + src/jdk.jlink/share/classes/module-info.java + src/jdk.jsobject/share/classes/module-info.java - src/jdk.jvmstat.rmi/share/classes/META-INF/services/sun.jvmstat.monitor.MonitoredHostService + src/jdk.jvmstat.rmi/share/classes/module-info.java - src/jdk.jvmstat/share/classes/META-INF/services/sun.jvmstat.monitor.MonitoredHostService + src/jdk.jvmstat/share/classes/module-info.java - src/jdk.localedata/share/classes/META-INF/services/sun.util.locale.provider.LocaleDataMetaInfo + src/jdk.localedata/share/classes/module-info.java + src/jdk.localedata/share/classes/sun/util/resources/provider/LocaleDataProvider.java + src/jdk.localedata/share/classes/sun/util/resources/provider/SupplementaryLocaleDataProvider.java - src/jdk.management/share/classes/META-INF/services/sun.management.spi.PlatformMBeanProvider + src/jdk.management/share/classes/module-info.java - src/jdk.naming.dns/share/classes/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor + src/jdk.naming.dns/share/classes/module-info.java + src/jdk.naming.rmi/share/classes/module-info.java + src/jdk.pack200/share/classes/module-info.java + src/jdk.policytool/share/classes/module-info.java + src/jdk.rmic/share/classes/jdk/rmi/rmic/Main.java + src/jdk.rmic/share/classes/module-info.java ! src/jdk.rmic/share/classes/sun/rmi/rmic/BatchEnvironment.java ! src/jdk.rmic/share/classes/sun/tools/java/ClassPath.java + src/jdk.sctp/share/classes/module-info.java ! src/jdk.security.auth/share/classes/com/sun/security/auth/SolarisNumericGroupPrincipal.java ! src/jdk.security.auth/share/classes/com/sun/security/auth/SolarisNumericUserPrincipal.java ! src/jdk.security.auth/share/classes/com/sun/security/auth/SolarisPrincipal.java ! src/jdk.security.auth/share/classes/com/sun/security/auth/X500Principal.java ! src/jdk.security.auth/share/classes/com/sun/security/auth/module/JndiLoginModule.java ! src/jdk.security.auth/share/classes/com/sun/security/auth/module/KeyStoreLoginModule.java ! src/jdk.security.auth/share/classes/com/sun/security/auth/module/Krb5LoginModule.java ! src/jdk.security.auth/share/classes/com/sun/security/auth/module/LdapLoginModule.java + src/jdk.security.auth/share/classes/module-info.java + src/jdk.security.jgss/share/classes/module-info.java - src/jdk.zipfs/share/classes/META-INF/services/java.nio.file.spi.FileSystemProvider + src/jdk.zipfs/share/classes/module-info.java ! test/Makefile ! test/ProblemList.txt ! test/TEST.ROOT ! test/TEST.groups ! test/com/sun/jdi/EarlyReturnNegativeTest.java ! test/com/sun/jdi/EarlyReturnTest.java ! test/com/sun/jdi/ImmutableResourceTest.sh ! test/com/sun/jdi/MethodExitReturnValuesTest.java + test/com/sun/jdi/ModulesTest.java ! test/com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java ! test/java/awt/Focus/AutoRequestFocusTest/AutoRequestFocusToFrontTest.java ! test/java/awt/Focus/FocusEmbeddedFrameTest/FocusEmbeddedFrameTest.java ! test/java/awt/Mixing/AWT_Mixing/JButtonInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JButtonOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JColorChooserOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JEditorPaneInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JEditorPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JLabelInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JLabelOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JListInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JListOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JPanelInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JPanelOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JProgressBarInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JProgressBarOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JScrollBarInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JScrollBarOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JSliderInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JSliderOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JSpinnerInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JSpinnerOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JTableInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JTableOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JTextAreaInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JTextAreaOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JTextFieldInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JTextFieldOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JToggleButtonInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JToggleButtonOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/MixingFrameResizing.java ! test/java/awt/Mixing/AWT_Mixing/OverlappingTestBase.java ! test/java/awt/Toolkit/Headless/WrappedToolkitTest/WrappedToolkitTest.sh ! test/java/awt/TrayIcon/ActionCommand/ActionCommand.java ! test/java/awt/TrayIcon/ActionEventMask/ActionEventMask.java ! test/java/awt/TrayIcon/ModalityTest/ModalityTest.java ! test/java/awt/TrayIcon/MouseEventMask/MouseEventMaskTest.java ! test/java/awt/TrayIcon/SecurityCheck/FunctionalityCheck/FunctionalityCheck.java ! test/java/awt/TrayIcon/SystemTrayIconHelper.java ! test/java/awt/TrayIcon/TrayIconEventModifiers/TrayIconEventModifiersTest.java ! test/java/awt/TrayIcon/TrayIconEvents/TrayIconEventsTest.java ! test/java/awt/TrayIcon/TrayIconMouseTest/TrayIconMouseTest.java ! test/java/awt/TrayIcon/TrayIconPopup/TrayIconPopupTest.java + test/java/awt/datatransfer/ConstructFlavoredObjectTest/ConstructFlavoredObjectTest.java + test/java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java ! test/java/awt/grab/EmbeddedFrameTest1/EmbeddedFrameTest1.java + test/java/awt/patchlib/java.desktop/java/awt/Helper.java ! test/java/awt/regtesthelpers/Util.java ! test/java/awt/regtesthelpers/UtilInternal.java ! test/java/awt/xembed/server/TesterClient.java ! test/java/beans/XMLEncoder/sun_swing_PrintColorUIResource.java + test/java/lang/Class/Foo.java + test/java/lang/Class/GetModuleTest.java + test/java/lang/Class/GetPackageTest.java + test/java/lang/Class/forName/modules/TestDriver.java + test/java/lang/Class/forName/modules/TestLayer.java + test/java/lang/Class/forName/modules/TestMain.java + test/java/lang/Class/forName/modules/policy + test/java/lang/Class/forName/modules/policy.denied + test/java/lang/Class/forName/modules/src/m1/module-info.java + test/java/lang/Class/forName/modules/src/m1/p1/A.java + test/java/lang/Class/forName/modules/src/m1/p1/Initializer.java + test/java/lang/Class/forName/modules/src/m1/p1/internal/B.java + test/java/lang/Class/forName/modules/src/m2/module-info.java + test/java/lang/Class/forName/modules/src/m2/p2/C.java + test/java/lang/Class/forName/modules/src/m2/p2/test/Main.java + test/java/lang/Class/forName/modules/src/m3/module-info.java + test/java/lang/Class/forName/modules/src/m3/p3/NoAccess.java + test/java/lang/Class/forName/modules/src/m3/p3/NoGetClassLoaderAccess.java + test/java/lang/Class/forName/modules/src/m3/p3/internal/Foo.java ! test/java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java + test/java/lang/Class/getPackageName/Basic.java + test/java/lang/Class/getResource/Main.java + test/java/lang/Class/getResource/ResourcesTest.java + test/java/lang/Class/getResource/src/m1/module-info.java + test/java/lang/Class/getResource/src/m1/p1/Main.java + test/java/lang/Class/getResource/src/m2/module-info.java + test/java/lang/Class/getResource/src/m2/p2/Main.java + test/java/lang/Class/getResource/src/m3/module-info.java + test/java/lang/Class/getResource/src/m3/p3/Main.java ! test/java/lang/ClassLoader/GetSystemPackage.java ! test/java/lang/ClassLoader/findSystemClass/Loader.java ! test/java/lang/ClassLoader/getResource/GetResource.sh + test/java/lang/ClassLoader/getResource/modules/Main.java + test/java/lang/ClassLoader/getResource/modules/ResourcesTest.java + test/java/lang/ClassLoader/getResource/modules/src/m1/module-info.java + test/java/lang/ClassLoader/getResource/modules/src/m1/p1/Main.java + test/java/lang/ClassLoader/getResource/modules/src/m2/module-info.java + test/java/lang/ClassLoader/getResource/modules/src/m2/p2/Main.java + test/java/lang/ClassLoader/getResource/modules/src/m3/module-info.java + test/java/lang/ClassLoader/getResource/modules/src/m3/p3/Main.java + test/java/lang/ClassLoader/platformClassLoader/DefinePlatformClass.java + test/java/lang/ClassLoader/platformClassLoader/jdk.zipfs/java/fake/Fake.java + test/java/lang/Package/Foo.java + test/java/lang/Package/GetPackages.java + test/java/lang/Package/annotation/PackageInfoTest.java + test/java/lang/Package/annotation/jdk.xml.dom/org/w3c/dom/css/Fake.java + test/java/lang/Package/annotation/jdk.xml.dom/org/w3c/dom/css/FakePackage.java + test/java/lang/Package/annotation/jdk.xml.dom/org/w3c/dom/css/package-info.java + test/java/lang/Package/annotation/package-info.java + test/java/lang/Package/annotation/src/p/Bar.java + test/java/lang/Package/annotation/src/p/Duplicate.java + test/java/lang/Package/annotation/src/p/package-info.java ! test/java/lang/SecurityManager/RestrictedPackages.java + test/java/lang/SecurityManager/modules/CustomSecurityManager.sh + test/java/lang/SecurityManager/modules/Test.java + test/java/lang/SecurityManager/modules/m/module-info.java + test/java/lang/SecurityManager/modules/m/p/CustomSecurityManager.java + test/java/lang/SecurityManager/modules/test.policy + test/java/lang/StackTraceElement/ModuleFrames.java ! test/java/lang/StackTraceElement/PublicConstructor.java ! test/java/lang/StackWalker/VerifyStackTrace.java ! test/java/lang/instrument/ATransformerManagementTestCase.java ! test/java/lang/instrument/BootClassPath/Agent.java ! test/java/lang/instrument/MakeJAR2.sh ! test/java/lang/instrument/RedefineClassWithNativeMethodAgent.java ! test/java/lang/instrument/RetransformAgent.java ! test/java/lang/instrument/SimpleIdentityTransformer.java ! test/java/lang/invoke/AccessControlTest.java ! test/java/lang/invoke/CustomizedLambdaFormTest.java ! test/java/lang/invoke/MethodHandlesTest.java ! test/java/lang/invoke/VarargsArrayTest.java + test/java/lang/invoke/java.base/java/lang/invoke/MethodHandleHelper.java ! test/java/lang/invoke/lambda/LambdaAccessControlDoPrivilegedTest.java + test/java/lang/invoke/modules/ModuleAccessControlTest.java + test/java/lang/invoke/modules/src/m1/module-info.java + test/java/lang/invoke/modules/src/m1/p1/Main.java + test/java/lang/invoke/modules/src/m1/p1/Type1.java + test/java/lang/invoke/modules/src/m1/p2/Type2.java + test/java/lang/invoke/modules/src/m2/module-info.java + test/java/lang/invoke/modules/src/m2/q1/Type1.java + test/java/lang/invoke/modules/src/m2/q2/Type2.java ! test/java/lang/management/CompositeData/ThreadInfoCompositeData.java ! test/java/lang/management/MemoryMXBean/PendingAllGC.sh + test/java/lang/module/AutomaticModulesTest.java + test/java/lang/module/ConfigurationTest.java + test/java/lang/module/ModuleDescriptorTest.java + test/java/lang/module/ModuleFinderTest.java + test/java/lang/module/ModuleReader/ModuleReaderTest.java + test/java/lang/module/ModuleReader/src/m/module-info.java + test/java/lang/module/ModuleReader/src/m/p/Main.java + test/java/lang/module/ModuleReferenceTest.java + test/java/lang/module/VersionTest.java + test/java/lang/reflect/AccessibleObject/ModuleSetAccessibleTest.java + test/java/lang/reflect/Layer/BasicLayerTest.java + test/java/lang/reflect/Layer/LayerAndLoadersTest.java + test/java/lang/reflect/Layer/layertest/Test.java + test/java/lang/reflect/Layer/src/m1/module-info.java + test/java/lang/reflect/Layer/src/m1/p/Main.java + test/java/lang/reflect/Layer/src/m1/p/Service.java + test/java/lang/reflect/Layer/src/m2/module-info.java + test/java/lang/reflect/Layer/src/m2/q/Hello.java + test/java/lang/reflect/Layer/src/m3/module-info.java + test/java/lang/reflect/Layer/src/m3/w/Hello.java + test/java/lang/reflect/Layer/src/m4/impl/ServiceImpl.java + test/java/lang/reflect/Layer/src/m4/module-info.java + test/java/lang/reflect/Module/AddExportsTest.java + test/java/lang/reflect/Module/BasicModuleTest.java + test/java/lang/reflect/Module/access/AccessTest.java + test/java/lang/reflect/Module/access/src/target/module-info.java + test/java/lang/reflect/Module/access/src/target/p/Exported.java + test/java/lang/reflect/Module/access/src/target/p/Helper.java + test/java/lang/reflect/Module/access/src/target/q/Internal.java + test/java/lang/reflect/Module/access/src/test/module-info.java + test/java/lang/reflect/Module/access/src/test/test/Main.java ! test/java/lang/reflect/Proxy/Basic1.java ! test/java/lang/reflect/Proxy/NullClassLoader.java + test/java/lang/reflect/Proxy/ProxyClassAccessTest.java + test/java/lang/reflect/Proxy/ProxyForMethodHandle.java + test/java/lang/reflect/Proxy/ProxyLayerTest.java + test/java/lang/reflect/Proxy/ProxyModuleMapping.java + test/java/lang/reflect/Proxy/ProxyTest.java + test/java/lang/reflect/Proxy/q/NP.java + test/java/lang/reflect/Proxy/q/U.java + test/java/lang/reflect/Proxy/src/m1/module-info.java + test/java/lang/reflect/Proxy/src/m1/p/one/I.java + test/java/lang/reflect/Proxy/src/m1/p/one/internal/J.java + test/java/lang/reflect/Proxy/src/m2/module-info.java + test/java/lang/reflect/Proxy/src/m2/p/two/A.java + test/java/lang/reflect/Proxy/src/m2/p/two/B.java + test/java/lang/reflect/Proxy/src/m2/p/two/Bar.java + test/java/lang/reflect/Proxy/src/m2/p/two/internal/C.java + test/java/lang/reflect/Proxy/src/m3/module-info.java + test/java/lang/reflect/Proxy/src/m3/p/three/P.java + test/java/lang/reflect/Proxy/src/m3/p/three/internal/Q.java + test/java/lang/reflect/Proxy/src/test/jdk/test/Main.java + test/java/lang/reflect/Proxy/src/test/jdk/test/NP.java + test/java/lang/reflect/Proxy/src/test/jdk/test/ProxyClassAccess.java + test/java/lang/reflect/Proxy/src/test/jdk/test/ProxyTest.java + test/java/lang/reflect/Proxy/src/test/jdk/test/internal/R.java + test/java/lang/reflect/Proxy/src/test/jdk/test/internal/RImpl.java + test/java/lang/reflect/Proxy/src/test/jdk/test/internal/foo/Foo.java + test/java/lang/reflect/Proxy/src/test/jdk/test/internal/foo/FooException.java + test/java/lang/reflect/Proxy/src/test/module-info.java ! test/java/net/Authenticator/B4933582.sh ! test/java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.java - test/java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.sh + test/java/net/DatagramSocket/SetDatagramSocketImplFactory/java.base/java/net/MyDatagramSocketImplFactory.java - test/java/net/DatagramSocket/SetDatagramSocketImplFactory/java/net/MyDatagramSocketImplFactory.java ! test/java/net/NetworkInterface/NetworkInterfaceStreamTest.java ! test/java/net/URI/URItoURLTest.java ! test/java/net/URLPermission/nstest/lookup.sh + test/java/net/httpclient/whitebox/Driver.java - test/java/net/httpclient/whitebox/TEST.properties + test/java/net/httpclient/whitebox/java.httpclient/java/net/http/SelectorTest.java - test/java/net/httpclient/whitebox/java/net/http/SelectorTest.java ! test/java/nio/Buffer/LimitDirectMemory.sh ! test/java/nio/channels/spi/SelectorProvider/inheritedChannel/run_tests.sh ! test/java/nio/file/Files/StreamLinesTest.java ! test/java/nio/file/spi/SetDefaultProvider.java ! test/java/nio/file/spi/TestProvider.java ! test/java/rmi/activation/Activatable/extLoadedImpl/ext.sh ! test/java/rmi/activation/ActivationGroup/downloadActivationGroup/DownloadActivationGroup.java ! test/java/rmi/activation/ActivationSystem/stubClassesPermitted/StubClassesPermitted.java ! test/java/rmi/activation/ActivationSystem/stubClassesPermitted/rmid.security.policy ! test/java/rmi/activation/rmidViaInheritedChannel/InheritedChannelNotServerSocket.java ! test/java/rmi/activation/rmidViaInheritedChannel/RmidViaInheritedChannel.java ! test/java/rmi/dgc/dgcAckFailure/DGCAckFailure.java ! test/java/rmi/registry/readTest/readTest.sh ! test/java/rmi/reliability/benchmark/bench/HtmlReporter.java ! test/java/rmi/reliability/benchmark/bench/TextReporter.java ! test/java/rmi/testlibrary/JavaVM.java ! test/java/rmi/transport/checkFQDN/CheckFQDN.java ! test/java/rmi/transport/dgcDeadLock/DGCDeadLock.java ! test/java/security/PermissionCollection/PermissionCollectionStreamTest.java + test/java/security/Provider/DefaultProviderList.java + test/java/security/Provider/SecurityProviderModularTest.java + test/java/security/Provider/TestSecurityProvider.java + test/java/security/Provider/TestSecurityProviderClient.java ! test/java/security/cert/X509Certificate/EmptySubject.java + test/java/security/modules/ModularTest.java ! test/java/security/testlibrary/Proc.java ! test/java/util/Calendar/GenericTimeZoneNamesTest.sh ! test/java/util/Currency/CheckDataVersion.java ! test/java/util/Currency/CurrencyTest.java ! test/java/util/Formatter/Basic.sh ! test/java/util/Locale/LocaleProviders.sh ! test/java/util/PluggableLocale/ExecTest.sh ! test/java/util/PluggableLocale/ProviderTest.java ! test/java/util/ResourceBundle/Bug4168625Test.java ! test/java/util/ResourceBundle/Bug6299235Test.java ! test/java/util/ResourceBundle/Bug6299235Test.sh + test/java/util/ResourceBundle/modules/appbasic/src/asiabundles/jdk/test/resources/asia/MyResourcesAsia.java + test/java/util/ResourceBundle/modules/appbasic/src/asiabundles/jdk/test/resources/asia/MyResources_ja.properties + test/java/util/ResourceBundle/modules/appbasic/src/asiabundles/jdk/test/resources/asia/MyResources_zh.properties + test/java/util/ResourceBundle/modules/appbasic/src/asiabundles/jdk/test/resources/asia/MyResources_zh_TW.properties + 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/jdk/test/resources/eu/MyResources_de.java + test/java/util/ResourceBundle/modules/appbasic/src/eubundles/jdk/test/resources/eu/MyResources_fr.java + test/java/util/ResourceBundle/modules/appbasic/src/eubundles/module-info.java + test/java/util/ResourceBundle/modules/appbasic/src/test/jdk/test/Main.java + test/java/util/ResourceBundle/modules/appbasic/src/test/jdk/test/resources/MyControl.java + test/java/util/ResourceBundle/modules/appbasic/src/test/jdk/test/resources/MyResources.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/MyResources_en.java + test/java/util/ResourceBundle/modules/appbasic/src/test/module-info.java + test/java/util/ResourceBundle/modules/appbasic2/appbasic2.sh + test/java/util/ResourceBundle/modules/appbasic2/src/asiabundles/jdk/test/resources/asia/MyResourcesAsia.java + test/java/util/ResourceBundle/modules/appbasic2/src/asiabundles/jdk/test/resources/asia/MyResources_ja.properties + test/java/util/ResourceBundle/modules/appbasic2/src/asiabundles/jdk/test/resources/asia/MyResources_zh.properties + test/java/util/ResourceBundle/modules/appbasic2/src/asiabundles/jdk/test/resources/asia/MyResources_zh_TW.properties + 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/jdk/test/resources/eu/MyResources_de.java + test/java/util/ResourceBundle/modules/appbasic2/src/eubundles/jdk/test/resources/eu/MyResources_fr.java + test/java/util/ResourceBundle/modules/appbasic2/src/eubundles/module-info.java + test/java/util/ResourceBundle/modules/appbasic2/src/test/jdk/test/Main.java + test/java/util/ResourceBundle/modules/appbasic2/src/test/jdk/test/resources/MyResources.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/MyResources_en.java + test/java/util/ResourceBundle/modules/appbasic2/src/test/module-info.java + test/java/util/ResourceBundle/modules/basic/basic.sh + test/java/util/ResourceBundle/modules/basic/src/asiabundles/jdk/test/resources/MyResources_ja_JP.properties + test/java/util/ResourceBundle/modules/basic/src/asiabundles/jdk/test/resources/asia/MyResourcesAsia.java + test/java/util/ResourceBundle/modules/basic/src/asiabundles/jdk/test/resources/asia/MyResources_ja.properties + test/java/util/ResourceBundle/modules/basic/src/asiabundles/jdk/test/resources/asia/MyResources_zh.properties + test/java/util/ResourceBundle/modules/basic/src/asiabundles/jdk/test/resources/asia/MyResources_zh_TW.properties + 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/jdk/test/resources/eu/MyResources_de.java + test/java/util/ResourceBundle/modules/basic/src/eubundles/jdk/test/resources/eu/MyResources_fr.java + test/java/util/ResourceBundle/modules/basic/src/eubundles/module-info.java + test/java/util/ResourceBundle/modules/basic/src/extra/jdk/test/resources/asia/MyResources_vi.properties + test/java/util/ResourceBundle/modules/basic/src/extra/jdk/test/resources/eu/MyResources_es.java + test/java/util/ResourceBundle/modules/basic/src/mainbundles/jdk/test/resources/MyResources.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/MyResources_en.java + test/java/util/ResourceBundle/modules/basic/src/mainbundles/module-info.java + test/java/util/ResourceBundle/modules/basic/src/test/jdk/test/Main.java + test/java/util/ResourceBundle/modules/basic/src/test/module-info.java + test/java/util/ResourceBundle/modules/modlocal/modlocal.sh + test/java/util/ResourceBundle/modules/modlocal/src/extra/jdk/test/resources/MyResources_vi.properties + test/java/util/ResourceBundle/modules/modlocal/src/test/jdk/test/Main.java + test/java/util/ResourceBundle/modules/modlocal/src/test/jdk/test/resources/MyResources.java + test/java/util/ResourceBundle/modules/modlocal/src/test/jdk/test/resources/MyResources_de.java + test/java/util/ResourceBundle/modules/modlocal/src/test/jdk/test/resources/MyResources_en.java + test/java/util/ResourceBundle/modules/modlocal/src/test/jdk/test/resources/MyResources_fr.java + test/java/util/ResourceBundle/modules/modlocal/src/test/jdk/test/resources/MyResources_ja.properties + test/java/util/ResourceBundle/modules/modlocal/src/test/jdk/test/resources/MyResources_zh.properties + test/java/util/ResourceBundle/modules/modlocal/src/test/jdk/test/resources/MyResources_zh_TW.properties + test/java/util/ResourceBundle/modules/modlocal/src/test/module-info.java + test/java/util/ResourceBundle/modules/security/TestPermission.java + test/java/util/ResourceBundle/modules/security/src/m1/module-info.java + test/java/util/ResourceBundle/modules/security/src/m1/p1/Bundle.java + test/java/util/ResourceBundle/modules/security/src/m1/p1/resources/MyResources.java + test/java/util/ResourceBundle/modules/security/src/test/jdk/test/Main.java + test/java/util/ResourceBundle/modules/security/src/test/jdk/test/resources/TestResources.java + test/java/util/ResourceBundle/modules/security/src/test/module-info.java + test/java/util/ResourceBundle/modules/simple/simple.sh + test/java/util/ResourceBundle/modules/simple/src/bundles/jdk/test/resources/MyResources.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/MyResources_de.java + test/java/util/ResourceBundle/modules/simple/src/bundles/jdk/test/resources/MyResources_en.java + test/java/util/ResourceBundle/modules/simple/src/bundles/jdk/test/resources/MyResources_fr.java + test/java/util/ResourceBundle/modules/simple/src/bundles/jdk/test/resources/MyResources_ja.properties + test/java/util/ResourceBundle/modules/simple/src/bundles/jdk/test/resources/MyResources_zh.properties + test/java/util/ResourceBundle/modules/simple/src/bundles/jdk/test/resources/MyResources_zh_TW.properties + test/java/util/ResourceBundle/modules/simple/src/bundles/module-info.java + test/java/util/ResourceBundle/modules/simple/src/test/jdk/test/Main.java + test/java/util/ResourceBundle/modules/simple/src/test/module-info.java + test/java/util/ResourceBundle/modules/visibility/src/embargo/jdk/embargo/TestWithNoModuleArg.java + test/java/util/ResourceBundle/modules/visibility/src/embargo/jdk/embargo/TestWithUnnamedModuleArg.java + test/java/util/ResourceBundle/modules/visibility/src/embargo/module-info.java + test/java/util/ResourceBundle/modules/visibility/src/exported.named.bundles/jdk/test/resources/exported/classes/MyResources.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/props/MyResources.properties + 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/MyResources.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/MyResources.properties + test/java/util/ResourceBundle/modules/visibility/src/named.bundles/jdk/test/resources/props/MyResourcesProvider.java + test/java/util/ResourceBundle/modules/visibility/src/named.bundles/module-info.java + test/java/util/ResourceBundle/modules/visibility/src/pkg/jdk/pkg/resources/classes/MyResources.java + test/java/util/ResourceBundle/modules/visibility/src/pkg/jdk/pkg/resources/props/MyResources.properties + test/java/util/ResourceBundle/modules/visibility/src/pkg/jdk/pkg/test/Main.java + test/java/util/ResourceBundle/modules/visibility/src/test/jdk/test/TestWithNoModuleArg.java + test/java/util/ResourceBundle/modules/visibility/src/test/jdk/test/TestWithUnnamedModuleArg.java + test/java/util/ResourceBundle/modules/visibility/src/test/module-info.java + test/java/util/ResourceBundle/modules/visibility/visibility.sh + test/java/util/ResourceBundle/modules/xmlformat/src/bundles/jdk/test/resources/MyResources.xml + test/java/util/ResourceBundle/modules/xmlformat/src/bundles/jdk/test/resources/MyResourcesProvider.java + test/java/util/ResourceBundle/modules/xmlformat/src/bundles/jdk/test/resources/MyResources_de.xml + test/java/util/ResourceBundle/modules/xmlformat/src/bundles/jdk/test/resources/MyResources_en.xml + test/java/util/ResourceBundle/modules/xmlformat/src/bundles/jdk/test/resources/MyResources_fr.xml + test/java/util/ResourceBundle/modules/xmlformat/src/bundles/jdk/test/resources/MyResources_ja.xml + test/java/util/ResourceBundle/modules/xmlformat/src/bundles/jdk/test/resources/MyResources_zh.xml + test/java/util/ResourceBundle/modules/xmlformat/src/bundles/jdk/test/resources/MyResources_zh_TW.xml + test/java/util/ResourceBundle/modules/xmlformat/src/bundles/module-info.java + test/java/util/ResourceBundle/modules/xmlformat/src/test/jdk/test/Main.java + test/java/util/ResourceBundle/modules/xmlformat/src/test/module-info.java + test/java/util/ResourceBundle/modules/xmlformat/xmlformat.sh ! test/java/util/Scanner/ScannerStreamTest.java + test/java/util/ServiceLoader/TwoIterators.java + test/java/util/ServiceLoader/modules/BasicTest.java + test/java/util/ServiceLoader/modules/ServicesTest.java + test/java/util/ServiceLoader/modules/src/bananascript/module-info.java + test/java/util/ServiceLoader/modules/src/bananascript/org/banana/BananaScript.java + test/java/util/ServiceLoader/modules/src/bananascript/org/banana/BananaScriptEngineFactory.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/src/test/module-info.java + test/java/util/ServiceLoader/modules/src/test/test/Main.java ! test/java/util/logging/LocalizedLevelName.java + test/java/util/logging/modules/GetResourceBundleTest.java + test/java/util/logging/modules/pkgs/p3/resource/ClassResource.java + test/java/util/logging/modules/pkgs/p3/resource/p.properties + test/java/util/logging/modules/pkgs/p3/test/ResourceBundleTest.java + test/java/util/logging/modules/src/m1/module-info.java + test/java/util/logging/modules/src/m1/p1/resource/ClassResource.java + test/java/util/logging/modules/src/m1/p1/resource/p.properties + test/java/util/logging/modules/src/m2/module-info.java + test/java/util/logging/modules/src/m2/p2/resource/ClassResource.java + test/java/util/logging/modules/src/m2/p2/resource/p.properties + test/java/util/logging/modules/src/m2/p2/test/ModuleLoggerAccess.java ! test/java/util/regex/PatternStreamTest.java - test/java/util/stream/bootlib/TEST.properties ! test/java/util/stream/boottest/TEST.properties ! test/java/util/stream/test/TEST.properties ! test/javax/crypto/NullCipher/TestWithoutInit.java + test/javax/imageio/plugins/external_plugin_tests/TestClassPathPlugin.sh + test/javax/imageio/plugins/external_plugin_tests/src/simp/META-INF/services/javax.imageio.spi.ImageReaderSpi + test/javax/imageio/plugins/external_plugin_tests/src/simp/SIMPImageReader.java + test/javax/imageio/plugins/external_plugin_tests/src/simp/SIMPImageReaderSpi.java + test/javax/imageio/plugins/external_plugin_tests/src/simp/SIMPMetadata.java + test/javax/imageio/plugins/external_plugin_tests/src/simp/SIMPMetadataFormat.java + test/javax/imageio/plugins/external_plugin_tests/src/simp/module-info.java + test/javax/imageio/plugins/external_plugin_tests/src/simptest/TestSIMPPlugin.java ! test/javax/imageio/stream/StreamCloserLeak/run_test.sh ! test/javax/management/MBeanInfo/NotificationInfoTest.java + test/javax/naming/module/basic.sh + test/javax/naming/module/src/authz/module-info.java + test/javax/naming/module/src/authz/org/example/authz/AuthzIdRequestControl.java + test/javax/naming/module/src/authz/org/example/authz/AuthzIdResponseControl.java + test/javax/naming/module/src/authz/org/example/authz/AuthzIdResponseControlFactory.java + test/javax/naming/module/src/foo/module-info.java + test/javax/naming/module/src/foo/org/example/foo/FooControl.java + test/javax/naming/module/src/fruit/module-info.java + test/javax/naming/module/src/fruit/org/example/fruit/Fruit.java + test/javax/naming/module/src/fruit/org/example/fruit/FruitFactory.java + test/javax/naming/module/src/hello/module-info.java + test/javax/naming/module/src/hello/org/example/hello/Hello.java + test/javax/naming/module/src/hello/org/example/hello/HelloImpl.java + test/javax/naming/module/src/ldapv4/module-info.java + test/javax/naming/module/src/ldapv4/org/example/ldapv4/ldapv4URLContext.java + test/javax/naming/module/src/ldapv4/org/example/ldapv4/ldapv4URLContextFactory.java + test/javax/naming/module/src/person/module-info.java + test/javax/naming/module/src/person/org/example/person/Person.java + test/javax/naming/module/src/person/org/example/person/PersonFactory.java + test/javax/naming/module/src/test/module-info.java + test/javax/naming/module/src/test/test/ConnectWithAuthzId.java + test/javax/naming/module/src/test/test/ConnectWithAuthzId.ldap + test/javax/naming/module/src/test/test/ConnectWithFoo.java + test/javax/naming/module/src/test/test/ConnectWithFoo.ldap + test/javax/naming/module/src/test/test/LDAPServer.java + test/javax/naming/module/src/test/test/ReadByUrl.java + test/javax/naming/module/src/test/test/ReadByUrl.ldap + test/javax/naming/module/src/test/test/StoreFruit.java + test/javax/naming/module/src/test/test/StoreFruit.ldap + test/javax/naming/module/src/test/test/StoreObject.java + test/javax/naming/module/src/test/test/StoreObject.ldap + test/javax/naming/module/src/test/test/StorePerson.java + test/javax/naming/module/src/test/test/StorePerson.ldap + test/javax/naming/module/src/test/test/StoreRemote.java + test/javax/naming/module/src/test/test/StoreRemote.ldap + test/javax/net/ssl/Stapling/TEST.properties + test/javax/security/auth/login/modules/JaasClient.java + test/javax/security/auth/login/modules/JaasModularClientTest.java + test/javax/security/auth/login/modules/TEST.properties + test/javax/security/auth/login/modules/TestLoginModule.java + test/javax/security/auth/login/modules/jaas.conf + test/javax/swing/JComboBox/8080972/TestBasicComboBoxEditor.java + test/javax/swing/JEditorPane/8080972/TestJEditor.java + test/javax/swing/JFormattedTextField/8080972/TestDefaultFormatter.java + test/javax/swing/JTable/8080972/TestJTableCellEditor.java + test/javax/swing/UIDefaults/8080972/TestProxyLazyValue.java + test/javax/swing/dnd/8080972/TestTransferHandler.java + test/javax/swing/plaf/nimbus/8080972/TestAbstractRegionPainter.java + test/javax/swing/text/View/8080972/TestObjectView.java ! test/javax/xml/jaxp/Encodings/CheckEncodingPropertiesFile.java ! test/javax/xml/jaxp/common/8035437/run.sh + test/javax/xml/soap/XmlTest.java ! test/jdk/asm/AsmSanity.java - test/jdk/internal/jimage/ExecutableTest.java ! test/jdk/internal/jimage/JImageReadTest.java - test/jdk/internal/jimage/JImageTest.java + test/jdk/internal/jimage/TEST.properties - test/jdk/internal/jimage/VerifyJimage.java ! test/jdk/internal/jrtfs/Basic.java ! test/jdk/internal/ref/Cleaner/ExitOnThrow.java + test/jdk/modules/etc/VerifyModuleDelegation.java + test/jdk/modules/scenarios/automaticmodules/RunWithAutomaticModules.java + test/jdk/modules/scenarios/automaticmodules/src/bananascript/META-INF/services/javax.script.ScriptEngineFactory + test/jdk/modules/scenarios/automaticmodules/src/bananascript/org/banana/BananaScript.java + test/jdk/modules/scenarios/automaticmodules/src/bananascript/org/banana/BananaScriptEngineFactory.java + test/jdk/modules/scenarios/automaticmodules/src/basictest/module-info.java + test/jdk/modules/scenarios/automaticmodules/src/basictest/test/Main.java + test/jdk/modules/scenarios/automaticmodules/src/httpserver/http/HttpServer.java + test/jdk/modules/scenarios/automaticmodules/src/httpserver/http/spi/HttpServerProvider.java + test/jdk/modules/scenarios/automaticmodules/src/logging/logging/Logger.java + test/jdk/modules/scenarios/automaticmodules/src/sptest/module-info.java + test/jdk/modules/scenarios/automaticmodules/src/sptest/test/Main.java + test/jdk/modules/scenarios/container/ContainerTest.java + test/jdk/modules/scenarios/container/src/app1/app1/Main.java + test/jdk/modules/scenarios/container/src/app1/module-info.java + test/jdk/modules/scenarios/container/src/app2/app2/Main.java + test/jdk/modules/scenarios/container/src/app2/module-info.java + test/jdk/modules/scenarios/container/src/container/container/Main.java + test/jdk/modules/scenarios/container/src/container/module-info.java + test/jdk/modules/scenarios/container/src/java.ws.rs/javax/ws/rs/Client.java + test/jdk/modules/scenarios/container/src/java.ws.rs/module-info.java + test/jdk/modules/scenarios/container/src/java.xml.ws/javax/xml/ws/WebService.java + test/jdk/modules/scenarios/container/src/java.xml.ws/module-info.java + test/jdk/modules/scenarios/overlappingpackages/OverlappingPackagesTest.java + test/jdk/modules/scenarios/overlappingpackages/src/m1/module-info.java + test/jdk/modules/scenarios/overlappingpackages/src/m1/p/C1.java + test/jdk/modules/scenarios/overlappingpackages/src/m2/module-info.java + test/jdk/modules/scenarios/overlappingpackages/src/m2/p/C2.java + test/jdk/modules/scenarios/overlappingpackages/src/misc/module-info.java + test/jdk/modules/scenarios/overlappingpackages/src/misc/sun/misc/Unsafe.java + test/jdk/modules/scenarios/overlappingpackages/src/test/module-info.java + test/jdk/modules/scenarios/overlappingpackages/src/test/test/Main.java + test/lib/testlibrary/CompilerUtils.java + test/lib/testlibrary/JarUtils.java + test/lib/testlibrary/ModuleUtils.java ! test/lib/testlibrary/jdk/testlibrary/OutputAnalyzer.java ! test/lib/testlibrary/jdk/testlibrary/ProcessTools.java ! test/sun/awt/shell/ShellFolderMemoryLeak.java + test/sun/management/StackTraceElementCompositeData/CompatibilityTest.java ! test/sun/management/jmxremote/bootstrap/CustomLauncherTest.java ! test/sun/management/jmxremote/bootstrap/LocalManagementTest.java ! test/sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh ! test/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh ! test/sun/management/jmxremote/bootstrap/RmiSslNoKeyStoreTest.sh ! test/sun/management/jmxremote/startstop/JMXStatusPerfCountersTest.java ! test/sun/net/idn/TestStringPrep.java ! test/sun/net/util/IPAddressUtilTest.java ! test/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh ! test/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxyWithAuth.sh ! test/sun/net/www/protocol/jrt/Basic.java + test/sun/net/www/protocol/jrt/OtherResources.java ! test/sun/net/www/protocol/jrt/WithSecurityManager.java + test/sun/net/www/protocol/jrt/other_resources.sh ! test/sun/reflect/Reflection/GetCallerClassTest.sh ! test/sun/reflect/constantPool/ConstantPoolTest.java ! test/sun/rmi/runtime/Log/6409194/NoConsoleOutput.java ! test/sun/security/krb5/auto/HttpNegotiateServer.java ! test/sun/security/krb5/config/ConfPlusProp.java ! test/sun/security/krb5/config/DNS.java - test/sun/security/krb5/config/NamingManager.java - test/sun/security/krb5/config/dns.sh + test/sun/security/krb5/config/java.naming/javax/naming/spi/NamingManager.java ! test/sun/security/krb5/tools/ktcheck.sh ! test/sun/security/mscapi/IsSunMSCAPIAvailable.java - test/sun/security/mscapi/IsSunMSCAPIAvailable.sh ! test/sun/security/mscapi/PublicKeyInterop.sh ! test/sun/security/mscapi/ShortRSAKey1024.sh ! test/sun/security/pkcs11/KeyStore/ClientAuth.sh ! test/sun/security/pkcs11/Provider/Login.policy + test/sun/security/provider/PolicyFile/Modules.java + test/sun/security/provider/PolicyFile/modules.policy ! test/sun/security/provider/certpath/OCSP/OCSPSingleExtensions.java - test/sun/security/ssl/StatusStapling/BogusStatusRequest.java - test/sun/security/ssl/StatusStapling/CertStatusReqExtensionTests.java - test/sun/security/ssl/StatusStapling/CertStatusReqItemV2Tests.java - test/sun/security/ssl/StatusStapling/CertStatusReqListV2ExtensionTests.java - test/sun/security/ssl/StatusStapling/OCSPStatusRequestTests.java - test/sun/security/ssl/StatusStapling/StatusResponseManagerTests.java ! test/sun/security/ssl/StatusStapling/TEST.properties - test/sun/security/ssl/StatusStapling/TestCase.java + test/sun/security/ssl/StatusStapling/TestRun.java - test/sun/security/ssl/StatusStapling/TestUtils.java + test/sun/security/ssl/StatusStapling/java.base/sun/security/ssl/BogusStatusRequest.java + test/sun/security/ssl/StatusStapling/java.base/sun/security/ssl/CertStatusReqExtensionTests.java + test/sun/security/ssl/StatusStapling/java.base/sun/security/ssl/CertStatusReqItemV2Tests.java + test/sun/security/ssl/StatusStapling/java.base/sun/security/ssl/CertStatusReqListV2ExtensionTests.java + test/sun/security/ssl/StatusStapling/java.base/sun/security/ssl/OCSPStatusRequestTests.java + test/sun/security/ssl/StatusStapling/java.base/sun/security/ssl/StatusResponseManagerTests.java + test/sun/security/ssl/StatusStapling/java.base/sun/security/ssl/TestCase.java + test/sun/security/ssl/StatusStapling/java.base/sun/security/ssl/TestUtils.java ! test/sun/security/tools/jarsigner/ts.sh ! test/sun/security/tools/keytool/autotest.sh ! test/sun/security/tools/keytool/standard.sh ! test/sun/security/util/Oid/OidEquals.java ! test/sun/security/validator/certreplace.sh ! test/sun/security/validator/samedn.sh ! test/sun/security/x509/URICertStore/ExtensionsWithLDAP.java ! test/sun/tools/jconsole/ResourceCheckTest.java ! test/sun/tools/jhsdb/SAGetoptTest.java ! test/sun/util/resources/TimeZone/Bug4640234.java + test/tools/jar/compat/CLICompatibility.java + test/tools/jar/modularJar/Basic.java + test/tools/jar/modularJar/src/bar/jdk/test/bar/Bar.java + test/tools/jar/modularJar/src/bar/jdk/test/bar/internal/Message.java + test/tools/jar/modularJar/src/bar/module-info.java + test/tools/jar/modularJar/src/baz/jdk/test/baz/BazService.java + test/tools/jar/modularJar/src/baz/jdk/test/baz/internal/BazServiceImpl.java + test/tools/jar/modularJar/src/baz/module-info.java + test/tools/jar/modularJar/src/foo/jdk/test/foo/Foo.java + test/tools/jar/modularJar/src/foo/jdk/test/foo/internal/Message.java + test/tools/jar/modularJar/src/foo/module-info.java + test/tools/jimage/JImageTest.java + test/tools/jimage/JImageToolTest.java + test/tools/jimage/VerifyJimage.java + test/tools/jlink/CheckExecutable.java + test/tools/jlink/CustomPluginTest.java + test/tools/jlink/DefaultProviderTest.java + test/tools/jlink/ImageFileCreatorTest.java + test/tools/jlink/ImageFilePoolTest.java + test/tools/jlink/IntegrationTest.java + test/tools/jlink/JLink2Test.java + test/tools/jlink/JLinkNegativeTest.java + test/tools/jlink/JLinkOptimTest.java + test/tools/jlink/JLinkOptionsTest.java + test/tools/jlink/JLinkPluginsTest.java + test/tools/jlink/JLinkPostProcessingTest.java + test/tools/jlink/JLinkTest.java + test/tools/jlink/NativeTest.java + test/tools/jlink/ResourcePoolTest.java + test/tools/jlink/SecurityTest.java + test/tools/jlink/asmplugin/AddForgetResourcesTest.java + test/tools/jlink/asmplugin/AsmPluginTestBase.java + test/tools/jlink/asmplugin/BasicTest.java + test/tools/jlink/asmplugin/IdentityPluginTest.java + test/tools/jlink/asmplugin/NegativeTest.java + test/tools/jlink/asmplugin/PackageMappingTest.java + test/tools/jlink/asmplugin/SortingTest.java + test/tools/jlink/asmplugin/VisitorTest.java + test/tools/jlink/basic/BasicTest.java + test/tools/jlink/basic/src/test/jdk/test/Test.java + test/tools/jlink/basic/src/test/module-info.java + test/tools/jlink/customplugin/module-info.java + test/tools/jlink/customplugin/plugin/CustomPlugin.java + test/tools/jlink/customplugin/plugin/HelloPlugin.java + test/tools/jlink/hashes/HashesTest.java + test/tools/jlink/hashes/newsrc/m2/module-info.java + test/tools/jlink/hashes/newsrc/m2/org/m2/Util.java + test/tools/jlink/hashes/newsrc/not_matched/module-info.java + test/tools/jlink/hashes/newsrc/not_matched/org/not_matched/Name.java + test/tools/jlink/hashes/src/m1/module-info.java + test/tools/jlink/hashes/src/m1/org/m1/Main.java + test/tools/jlink/hashes/src/m2/module-info.java + test/tools/jlink/hashes/src/m2/org/m2/Util.java + test/tools/jlink/hashes/src/not_matched/module-info.java + test/tools/jlink/hashes/src/not_matched/org/not_matched/Name.java + test/tools/jlink/optimplugin/module-info.java + test/tools/jlink/optimplugin/optim/AType.java + test/tools/jlink/optimplugin/optim/ForNameTestCase.java + test/tools/jlink/plugins/CompressIndexesTest.java + test/tools/jlink/plugins/CompressorPluginTest.java + test/tools/jlink/plugins/ExcludeFilesPluginTest.java + test/tools/jlink/plugins/ExcludePluginTest.java + test/tools/jlink/plugins/ExcludeVMPluginTest.java + test/tools/jlink/plugins/FileCopierPluginTest.java + test/tools/jlink/plugins/GetAvailableLocales.java + test/tools/jlink/plugins/IncludeLocalesPluginTest.java + test/tools/jlink/plugins/InstalledModuleDescriptors/InstalledModulesTest.java + test/tools/jlink/plugins/InstalledModuleDescriptors/UserModuleTest.java + test/tools/jlink/plugins/InstalledModuleDescriptors/src/m1/module-info.java + test/tools/jlink/plugins/InstalledModuleDescriptors/src/m1/p1/Main.java + test/tools/jlink/plugins/InstalledModuleDescriptors/src/m1/p2/T.java + test/tools/jlink/plugins/InstalledModuleDescriptors/src/m2/module-info.java + test/tools/jlink/plugins/InstalledModuleDescriptors/src/m2/q/S1.java + test/tools/jlink/plugins/InstalledModuleDescriptors/src/m2/q/S2.java + test/tools/jlink/plugins/InstalledModuleDescriptors/src/m3/module-info.java + test/tools/jlink/plugins/LastSorterTest.java + test/tools/jlink/plugins/PluginOrderTest.java + test/tools/jlink/plugins/PluginsNegativeTest.java + test/tools/jlink/plugins/PrevisitorTest.java + test/tools/jlink/plugins/ResourceFilterTest.java + test/tools/jlink/plugins/SignatureParserTest.java + test/tools/jlink/plugins/SorterPluginTest.java + test/tools/jlink/plugins/StringSharingPluginTest.java + test/tools/jlink/plugins/StripDebugPluginTest.java + test/tools/jmod/JmodNegativeTest.java + test/tools/jmod/JmodTest.java + test/tools/jmod/src/foo/jdk/test/foo/Foo.java + test/tools/jmod/src/foo/jdk/test/foo/internal/Message.java + test/tools/jmod/src/foo/module-info.java ! test/tools/launcher/MiscTests.java ! test/tools/launcher/ToolsOpts.java ! test/tools/launcher/VersionCheck.java + test/tools/launcher/modules/addexports/AddExportsTest.java + test/tools/launcher/modules/addexports/src/java.transaction/javax/transaction/Transaction.java + test/tools/launcher/modules/addexports/src/java.transaction/javax/transaction/internal/Helper.java + test/tools/launcher/modules/addexports/src/java.transaction/module-info.java + test/tools/launcher/modules/addexports/src/m1/jdk/test1/Main.java + test/tools/launcher/modules/addexports/src/m1/module-info.java + test/tools/launcher/modules/addexports/src/m2/jdk/test2/Main.java + test/tools/launcher/modules/addexports/src/m2/module-info.java + test/tools/launcher/modules/addexports/src/m3/jdk/test3/Main.java + test/tools/launcher/modules/addexports/src/m3/module-info.java + test/tools/launcher/modules/addexports/src/m4/jdk/test4/Type.java + test/tools/launcher/modules/addexports/src/m4/module-info.java + test/tools/launcher/modules/addmods/AddModsTest.java + test/tools/launcher/modules/addmods/src/app/Main.java + test/tools/launcher/modules/addmods/src/lib/jdk/lib/Util.java + test/tools/launcher/modules/addmods/src/lib/module-info.java + test/tools/launcher/modules/addreads/AddReadsTest.java + test/tools/launcher/modules/addreads/src/junit/org/junit/Assert.java + test/tools/launcher/modules/addreads/src/m1/module-info.java + test/tools/launcher/modules/addreads/src/m1/p/Main.java + test/tools/launcher/modules/basic/BasicTest.java + test/tools/launcher/modules/basic/src/test/jdk/test/Main.java + test/tools/launcher/modules/basic/src/test/module-info.java + test/tools/launcher/modules/limitmods/LimitModsTest.java + test/tools/launcher/modules/limitmods/src/test/jdk/test/UseAWT.java + test/tools/launcher/modules/limitmods/src/test/module-info.java + test/tools/launcher/modules/listmods/ListModsTest.java + test/tools/launcher/modules/listmods/src/java.transaction/javax/transaction/Transaction.java + test/tools/launcher/modules/listmods/src/java.transaction/javax/transaction/atomic/Atomic.java + test/tools/launcher/modules/listmods/src/java.transaction/module-info.java + test/tools/launcher/modules/listmods/src/m1/module-info.java + test/tools/launcher/modules/patch/PatchTest.java + test/tools/launcher/modules/patch/src/test/jdk/test/Main.java + test/tools/launcher/modules/patch/src/test/module-info.java + test/tools/launcher/modules/patch/src1/java.base/java/text/Annotation.java + test/tools/launcher/modules/patch/src1/java.base/java/text/AnnotationBuddy.java + test/tools/launcher/modules/patch/src1/jdk.compiler/com/sun/tools/javac/Main.java + test/tools/launcher/modules/patch/src1/jdk.compiler/com/sun/tools/javac/MainBuddy.java + test/tools/launcher/modules/patch/src1/jdk.naming.dns/com/sun/jndi/dns/DnsClient.java + test/tools/launcher/modules/patch/src1/jdk.naming.dns/com/sun/jndi/dns/DnsClientBuddy.java + test/tools/launcher/modules/patch/src2/java.base/java/lang2/Object.java + test/tools/launcher/modules/patch/src2/jdk.compiler/com/sun/tools/javac2/Main.java + test/tools/launcher/modules/patch/src2/jdk.naming.dns/com/sun/jndi/dns2/Zone.java + test/tools/launcher/modules/upgrademodulepath/UpgradeModulePathTest.java + test/tools/launcher/modules/upgrademodulepath/src/java.enterprise/javax/enterprise/context/Scope.java + test/tools/launcher/modules/upgrademodulepath/src/java.enterprise/module-info.java + test/tools/launcher/modules/upgrademodulepath/src/java.transaction/javax/transaction/Transaction.java + test/tools/launcher/modules/upgrademodulepath/src/java.transaction/module-info.java + test/tools/launcher/modules/upgrademodulepath/src/test/jdk/test/Main.java + test/tools/launcher/modules/upgrademodulepath/src/test/module-info.java + test/tools/lib/tests/Helper.java + test/tools/lib/tests/JImageGenerator.java + test/tools/lib/tests/JImageValidator.java + test/tools/lib/tests/Result.java + test/tools/pack200/ModuleAttributes.java ! test/tools/pack200/Utils.java ! test/tools/pack200/pack200-verifier/make/build.xml ! test/tools/pack200/pack200-verifier/src/xmlkit/ClassReader.java From mandy.chung at oracle.com Thu Mar 17 20:02:58 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 17 Mar 2016 20:02:58 +0000 Subject: hg: jigsaw/m3/langtools: 8142968: Module System implementation Message-ID: <201603172002.u2HK2wai006673@aojmv0008.oracle.com> Changeset: 9adfb22ff08f Author: alanb Date: 2016-03-17 19:04 +0000 URL: http://hg.openjdk.java.net/jigsaw/m3/langtools/rev/9adfb22ff08f 8142968: Module System implementation Summary: Initial integration of JEP 200, JEP 260, JEP 261, and JEP 282 Reviewed-by: jjg, jlahoda, vromero, mcimadamore, bpatel, ksrini, darcy, anazarov, dfuchs Contributed-by: alan.bateman at oracle.com, alex.buckley at oracle.com, jonathan.gibbons at oracle.com, karen.kinnear at oracle.com, mandy.chung at oracle.com, mark.reinhold at oracle.com, jan.lahoda at oracle.com, vicente.romero at oracle.com, andreas.lundblad at oracle.com, andrey.x.nazarov at oracle.com, chris.hegarty at oracle.com, erik.joelsson at oracle.com, kumar.x.srinivasan at oracle.com, sundararajan.athijegannathan at oracle.com ! make/CompileInterim.gmk ! make/build.properties ! make/build.xml ! make/gendata/Gendata-jdk.compiler.gmk ! make/intellij/ant.xml ! make/intellij/build.xml ! make/intellij/langtools.iml ! make/intellij/src/idea/LangtoolsIdeaAntLogger.java ! make/intellij/workspace.xml ! make/launcher.sh-template ! make/netbeans/langtools/build.xml ! make/netbeans/langtools/nbproject/project.xml ! make/tools/anttasks/SelectToolTask.java ! make/tools/crules/CodingRulesAnalyzerPlugin.java ! make/tools/propertiesparser/parser/MessageType.java ! src/java.compiler/share/classes/javax/lang/model/element/Element.java ! src/java.compiler/share/classes/javax/lang/model/element/ElementKind.java ! src/java.compiler/share/classes/javax/lang/model/element/ElementVisitor.java + 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/javax/lang/model/type/TypeKind.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor6.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor9.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementFilter.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor9.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementScanner9.java ! src/java.compiler/share/classes/javax/lang/model/util/Elements.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor9.java ! src/java.compiler/share/classes/javax/tools/ForwardingJavaFileManager.java ! src/java.compiler/share/classes/javax/tools/JavaFileManager.java ! src/java.compiler/share/classes/javax/tools/StandardLocation.java ! src/java.compiler/share/classes/javax/tools/ToolProvider.java + src/java.compiler/share/classes/module-info.java + src/jdk.compiler/share/classes/com/sun/source/tree/DirectiveTree.java + src/jdk.compiler/share/classes/com/sun/source/tree/ExportsTree.java + src/jdk.compiler/share/classes/com/sun/source/tree/ModuleTree.java + src/jdk.compiler/share/classes/com/sun/source/tree/ProvidesTree.java + src/jdk.compiler/share/classes/com/sun/source/tree/RequiresTree.java ! src/jdk.compiler/share/classes/com/sun/source/tree/Tree.java ! src/jdk.compiler/share/classes/com/sun/source/tree/TreeVisitor.java + src/jdk.compiler/share/classes/com/sun/source/tree/UsesTree.java ! src/jdk.compiler/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java ! src/jdk.compiler/share/classes/com/sun/tools/doclint/DocLint.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/BasicJavacTask.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/ClientCodeWrapper.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTool.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/ClassFinder.java + src/jdk.compiler/share/classes/com/sun/tools/javac/code/Directive.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Kinds.java + src/jdk.compiler/share/classes/com/sun/tools/javac/code/ModuleFinder.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Printer.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeTag.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java + src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/BaseFileManager.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/JRTIndex.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java + src/jdk.compiler/share/classes/com/sun/tools/javac/file/ModuleNameReader.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassFile.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/JNIWriter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Arguments.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Main.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/model/JavacElements.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties - src/jdk.compiler/share/classes/com/sun/tools/javac/sym/CreateSymbols.java - src/jdk.compiler/share/classes/com/sun/tools/javac/sym/Profiles.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeScanner.java + src/jdk.compiler/share/classes/com/sun/tools/javac/util/ModuleHelper.java + src/jdk.compiler/share/classes/com/sun/tools/javac/util/ModuleWrappers.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Name.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java - src/jdk.compiler/share/classes/com/sun/tools/javac/util/ServiceLoader.java ! src/jdk.compiler/share/classes/com/sun/tools/javah/JavahTask.java ! src/jdk.compiler/share/classes/com/sun/tools/javah/resources/l10n.properties ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/PubApiExtractor.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/Source.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/SjavacImpl.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/SmartFileManager.java + src/jdk.compiler/share/classes/module-info.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/AbstractPackageIndexWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/AbstractProfileIndexWriter.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfileIndexFrameWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageFrameWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageIndexFrameWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageWriterImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfileWriterImpl.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/WriterFactoryImpl.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlConstants.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlStyle.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/ProfilePackageSummaryWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/ProfileSummaryWriter.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/WriterFactory.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractBuilder.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/builders/BuilderFactory.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ProfilePackageSummaryBuilder.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ProfileSummaryBuilder.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclet.xml ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets.properties ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFileFactory.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPaths.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/util/MetaKeywords.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/util/StandardDocFileFactory.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/util/Utils.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/util/VisibleMemberMap.java ! src/jdk.javadoc/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/jdk.javadoc/share/classes/com/sun/tools/javadoc/DocEnv.java ! src/jdk.javadoc/share/classes/com/sun/tools/javadoc/DocletInvoker.java ! src/jdk.javadoc/share/classes/com/sun/tools/javadoc/JavadocTool.java ! src/jdk.javadoc/share/classes/com/sun/tools/javadoc/PackageDocImpl.java ! src/jdk.javadoc/share/classes/com/sun/tools/javadoc/Start.java ! src/jdk.javadoc/share/classes/com/sun/tools/javadoc/ToolOption.java ! src/jdk.javadoc/share/classes/com/sun/tools/javadoc/resources/javadoc.properties + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractModuleIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractPackageIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConfigurationImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleIndexFrameWriter.java + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModulePackageIndexFrameWriter.java + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageIndexFrameWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/WriterFactoryImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlConstants.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/AbstractDoclet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/Configuration.java + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/ModuleSummaryWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/WorkArounds.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/WriterFactory.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/BuilderFactory.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ConstantsSummaryBuilder.java + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ModuleSummaryBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclet.xml ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletManager.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocPaths.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/MetaKeywords.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/StandardDocFileFactory.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/DocEnv.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/JavadocClassFinder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/JavadocTool.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ToolOption.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/resources/javadoc.properties + src/jdk.javadoc/share/classes/module-info.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/AccessFlags.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/Attribute.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/ClassWriter.java + src/jdk.jdeps/share/classes/com/sun/tools/classfile/ConcealedPackages_attribute.java + src/jdk.jdeps/share/classes/com/sun/tools/classfile/Hashes_attribute.java + src/jdk.jdeps/share/classes/com/sun/tools/classfile/MainClass_attribute.java + src/jdk.jdeps/share/classes/com/sun/tools/classfile/Module_attribute.java + src/jdk.jdeps/share/classes/com/sun/tools/classfile/TargetPlatform_attribute.java + src/jdk.jdeps/share/classes/com/sun/tools/classfile/Version_attribute.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/JavapTask.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/Options.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap.properties ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Analyzer.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Archive.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ClassFileReader.java + src/jdk.jdeps/share/classes/com/sun/tools/jdeps/DependencyFinder.java + src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsFilter.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsTask.java + src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsWriter.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Module.java + src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleAnalyzer.java + src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleInfoBuilder.java + src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModulePaths.java - src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModulesXmlReader.java - src/jdk.jdeps/share/classes/com/sun/tools/jdeps/PlatformClassPath.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Profile.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps.properties ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdkinternals.properties + src/jdk.jdeps/share/classes/module-info.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/remote/RemoteAgent.java ! src/jdk.jshell/share/classes/jdk/jshell/ExecutionControl.java ! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java ! src/jdk.jshell/share/classes/jdk/jshell/TaskFactory.java + src/jdk.jshell/share/classes/module-info.java ! test/Makefile ! test/ProblemList.txt ! test/TEST.ROOT ! test/com/sun/javadoc/testCustomTag/TestCustomTag.java ! test/com/sun/javadoc/testCustomTag/taglets/CustomTag.java ! test/com/sun/javadoc/testHtmlVersion/TestHtmlVersion.java ! test/com/sun/javadoc/testLinkOption/TestLinkOption.java + test/com/sun/javadoc/testLinkOption/extra/StringBuilder.java - test/com/sun/javadoc/testLinkOption/java/lang/StringBuilderChild.java + test/com/sun/javadoc/testLinkOption/jdk/package-list + test/com/sun/javadoc/testLinkOption/mylib/lang/StringBuilderChild.java - test/com/sun/javadoc/testLinkOption/package-list ! test/com/sun/javadoc/testNavigation/TestNavigation.java ! test/com/sun/javadoc/testNestedInlineTag/TestNestedInlineTag.java ! test/com/sun/javadoc/testNestedInlineTag/testtaglets/BoldTaglet.java ! test/com/sun/javadoc/testNestedInlineTag/testtaglets/GreenTaglet.java ! test/com/sun/javadoc/testNestedInlineTag/testtaglets/UnderlineTaglet.java - test/com/sun/javadoc/testProfiles/TestProfiles.java - test/com/sun/javadoc/testProfiles/TestProfilesConfiguration.java - test/com/sun/javadoc/testProfiles/pkg1/Class1Pkg1.java - test/com/sun/javadoc/testProfiles/pkg1/Class2Pkg1.java - test/com/sun/javadoc/testProfiles/pkg1/Class3Pkg1.java - test/com/sun/javadoc/testProfiles/pkg1/Interface1Pkg1.java - test/com/sun/javadoc/testProfiles/pkg2/Anno1Pkg2.java - test/com/sun/javadoc/testProfiles/pkg2/Anno2Pkg2.java - test/com/sun/javadoc/testProfiles/pkg2/Class1Pkg2.java - test/com/sun/javadoc/testProfiles/pkg2/ClassError.java - test/com/sun/javadoc/testProfiles/pkg2/ClassException.java - test/com/sun/javadoc/testProfiles/pkg3/Class1Pkg3.java - test/com/sun/javadoc/testProfiles/pkg3/Class2Pkg3.java - test/com/sun/javadoc/testProfiles/pkg3/Interface1Pkg3.java - test/com/sun/javadoc/testProfiles/pkg4/Anno1Pkg4.java - test/com/sun/javadoc/testProfiles/pkg4/Class1Pkg4.java - test/com/sun/javadoc/testProfiles/pkg5/Class1Pkg5.java - test/com/sun/javadoc/testProfiles/pkg5/Interface1Pkg5.java - test/com/sun/javadoc/testProfiles/pkgDeprecated/Class1PkgDeprecated.java - test/com/sun/javadoc/testProfiles/pkgDeprecated/package-info.java - test/com/sun/javadoc/testProfiles/profile-rtjar-includes-nopkgs.txt - test/com/sun/javadoc/testProfiles/profile-rtjar-includes.txt ! test/com/sun/javadoc/testSubTitle/TestSubTitle.java ! test/com/sun/javadoc/testTaglets/TestTaglets.java ! test/com/sun/javadoc/testTaglets/taglets/Foo.java ! test/jdk/javadoc/doclet/5093723/T5093723.java ! test/jdk/javadoc/doclet/AccessAsciiArt/AccessAsciiArt.java ! test/jdk/javadoc/doclet/AccessFrameTitle/AccessFrameTitle.java ! test/jdk/javadoc/doclet/AccessH1/AccessH1.java ! test/jdk/javadoc/doclet/AccessSkipNav/AccessSkipNav.java ! test/jdk/javadoc/doclet/AccessSummary/AccessSummary.java ! test/jdk/javadoc/doclet/AuthorDD/AuthorDD.java ! test/jdk/javadoc/doclet/DocRootSlash/DocRootSlash.java ! test/jdk/javadoc/doclet/InheritDocForUserTags/DocTest.java ! test/jdk/javadoc/doclet/JavascriptWinTitle/JavascriptWinTitle.java ! test/jdk/javadoc/doclet/MetaTag/MetaTag.java ! test/jdk/javadoc/doclet/PackagesHeader/PackagesHeader.java ! test/jdk/javadoc/doclet/T6735320/T6735320.java ! test/jdk/javadoc/doclet/ValidHtml/ValidHtml.java ! test/jdk/javadoc/doclet/VersionNumber/VersionNumber.java ! test/jdk/javadoc/doclet/WindowTitles/WindowTitles.java ! test/jdk/javadoc/doclet/constantValues/TestConstantValuesDriver.java ! test/jdk/javadoc/doclet/dupThrowsTags/TestDupThrowsTags.java ! test/jdk/javadoc/doclet/testAbsLinkPath/TestAbsLinkPath.java ! test/jdk/javadoc/doclet/testAbstractMethod/TestAbstractMethod.java ! test/jdk/javadoc/doclet/testAnchorNames/TestAnchorNames.java ! test/jdk/javadoc/doclet/testAnnotationOptional/TestAnnotationOptional.java ! test/jdk/javadoc/doclet/testAnnotationTypes/TestAnnotationTypes.java ! test/jdk/javadoc/doclet/testBackSlashInLink/TestBackSlashInLink.java ! test/jdk/javadoc/doclet/testBadPackageFileInJar/TestBadPackageFileInJar.java ! test/jdk/javadoc/doclet/testBadSourceFile/TestBadSourceFile.java ! test/jdk/javadoc/doclet/testBaseClass/TestBaseClass.java ! test/jdk/javadoc/doclet/testBreakIterator/TestBreakIterator.java ! test/jdk/javadoc/doclet/testCRLineSeparator/TestCRLineSeparator.java ! test/jdk/javadoc/doclet/testCharset/TestCharset.java ! test/jdk/javadoc/doclet/testClassCrossReferences/TestClassCrossReferences.java ! test/jdk/javadoc/doclet/testClassTree/TestClassTree.java ! test/jdk/javadoc/doclet/testCmndLineClass/TestCmndLineClass.java ! test/jdk/javadoc/doclet/testCompletionFailure/TestCompletionFailure.java ! test/jdk/javadoc/doclet/testConstantValuesPage/TestConstantValuesPage.java ! test/jdk/javadoc/doclet/testConstructorIndent/TestConstructorIndent.java ! test/jdk/javadoc/doclet/testConstructors/TestConstructors.java ! test/jdk/javadoc/doclet/testDeprecatedDocs/TestDeprecatedDocs.java ! test/jdk/javadoc/doclet/testDocEncoding/TestDocEncoding.java ! test/jdk/javadoc/doclet/testDocErrorReporter/TestDocErrorReporter.java ! test/jdk/javadoc/doclet/testDocFileDir/TestDocFileDir.java ! test/jdk/javadoc/doclet/testDocFiles/TestDocFiles.java ! test/jdk/javadoc/doclet/testDocRootInlineTag/TestDocRootInlineTag.java ! test/jdk/javadoc/doclet/testDocRootLink/TestDocRootLink.java ! test/jdk/javadoc/doclet/testDupParamWarn/TestDupParamWarn.java ! test/jdk/javadoc/doclet/testEmptyClass/TestEmptyClass.java ! test/jdk/javadoc/doclet/testEnclosingClass/TestEnclosingClass.java ! test/jdk/javadoc/doclet/testEncoding/TestEncoding.java ! test/jdk/javadoc/doclet/testExternalOverridenMethod/TestExternalOverridenMethod.java ! test/jdk/javadoc/doclet/testGeneratedBy/TestGeneratedBy.java ! test/jdk/javadoc/doclet/testGroupOption/TestGroupOption.java ! test/jdk/javadoc/doclet/testHeadings/TestHeadings.java ! test/jdk/javadoc/doclet/testHelpFile/TestHelpFile.java ! test/jdk/javadoc/doclet/testHelpOption/TestHelpOption.java ! test/jdk/javadoc/doclet/testHiddenMembers/TestHiddenMembers.java ! test/jdk/javadoc/doclet/testHref/TestHref.java ! test/jdk/javadoc/doclet/testHrefInDocComment/TestHrefInDocComment.java ! test/jdk/javadoc/doclet/testHtmlComments/TestHtmlComments.java ! test/jdk/javadoc/doclet/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java ! test/jdk/javadoc/doclet/testHtmlDocument/TestHtmlDocument.java ! test/jdk/javadoc/doclet/testHtmlStrongTag/TestHtmlStrongTag.java ! test/jdk/javadoc/doclet/testHtmlTableStyles/TestHtmlTableStyles.java ! test/jdk/javadoc/doclet/testHtmlTableTags/TestHtmlTableTags.java ! test/jdk/javadoc/doclet/testHtmlTag/TestHtmlTag.java ! test/jdk/javadoc/doclet/testHtmlVersion/TestHtmlVersion.java ! test/jdk/javadoc/doclet/testIndentation/TestIndentation.java ! test/jdk/javadoc/doclet/testIndex/TestIndex.java ! test/jdk/javadoc/doclet/testInlineLinkLabel/TestInlineLinkLabel.java ! test/jdk/javadoc/doclet/testInterface/TestInterface.java ! test/jdk/javadoc/doclet/testJavaFX/TestJavaFX.java ! test/jdk/javadoc/doclet/testJavascript/TestJavascript.java ! test/jdk/javadoc/doclet/testLambdaFeature/TestLambdaFeature.java ! test/jdk/javadoc/doclet/testLeadingSpaces/LeadingSpaces.java ! test/jdk/javadoc/doclet/testLegacyTaglet/TestLegacyTaglet.java ! test/jdk/javadoc/doclet/testLinkOption/TestBadLinkOption.java ! test/jdk/javadoc/doclet/testLinkOption/TestLinkOption.java ! test/jdk/javadoc/doclet/testLinkOption/TestNewLineInLink.java + test/jdk/javadoc/doclet/testLinkOption/extra/StringBuilder.java - test/jdk/javadoc/doclet/testLinkOption/java/lang/StringBuilderChild.java + test/jdk/javadoc/doclet/testLinkOption/jdk/package-list + test/jdk/javadoc/doclet/testLinkOption/mylib/lang/StringBuilderChild.java - test/jdk/javadoc/doclet/testLinkOption/package-list ! test/jdk/javadoc/doclet/testLinkTaglet/TestLinkTaglet.java ! test/jdk/javadoc/doclet/testLinkToSerialForm/TestLinkToSerialForm.java ! test/jdk/javadoc/doclet/testLiteralCodeInPre/TestLiteralCodeInPre.java ! test/jdk/javadoc/doclet/testMemberInheritence/TestMemberInheritence.java ! test/jdk/javadoc/doclet/testMemberSummary/TestMemberSummary.java ! test/jdk/javadoc/doclet/testMethodTypes/TestMethodTypes.java ! test/jdk/javadoc/doclet/testModifierEx/TestModifierEx.java ! test/jdk/javadoc/doclet/testNavigation/TestNavigation.java ! test/jdk/javadoc/doclet/testNestedGenerics/TestNestedGenerics.java ! test/jdk/javadoc/doclet/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/jdk/javadoc/doclet/testNoPackagesFile/TestNoPackagesFile.java ! test/jdk/javadoc/doclet/testNotifications/TestNotifications.java ! test/jdk/javadoc/doclet/testOptions/TestOptions.java ! test/jdk/javadoc/doclet/testOrdering/TestOrdering.java ! test/jdk/javadoc/doclet/testOverridenMethods/TestMultiInheritence.java ! test/jdk/javadoc/doclet/testOverridenMethods/TestOverridenMethodDocCopy.java ! test/jdk/javadoc/doclet/testOverridenMethods/TestOverridenPrivateMethods.java ! test/jdk/javadoc/doclet/testOverridenMethods/TestOverridenPrivateMethodsWithPackageFlag.java ! test/jdk/javadoc/doclet/testOverridenMethods/TestOverridenPrivateMethodsWithPrivateFlag.java ! test/jdk/javadoc/doclet/testPackageDeprecation/TestPackageDeprecation.java ! test/jdk/javadoc/doclet/testPackagePage/TestPackagePage.java ! test/jdk/javadoc/doclet/testParamTaglet/TestParamTaglet.java ! test/jdk/javadoc/doclet/testPrivateClasses/TestPrivateClasses.java ! test/jdk/javadoc/doclet/testRecurseSubPackages/TestRecurseSubPackages.java ! test/jdk/javadoc/doclet/testRelativeLinks/TestRelativeLinks.java ! test/jdk/javadoc/doclet/testRepeatedAnnotations/TestRepeatedAnnotations.java ! test/jdk/javadoc/doclet/testReturnTag/TestReturnTag.java ! test/jdk/javadoc/doclet/testSearch/TestSearch.java ! test/jdk/javadoc/doclet/testSeeTag/TestSeeTag.java ! test/jdk/javadoc/doclet/testSerialVersionUID/TestSerialVersionUID.java ! test/jdk/javadoc/doclet/testSerializedForm/TestSerializedForm.java ! test/jdk/javadoc/doclet/testSerializedFormDeprecationInfo/TestSerializedFormDeprecationInfo.java ! test/jdk/javadoc/doclet/testSimpleTag/TestSimpleTag.java ! test/jdk/javadoc/doclet/testSimpleTagExclude/TestSimpleTagExclude.java ! test/jdk/javadoc/doclet/testSimpleTagInherit/TestSimpleTagInherit.java ! test/jdk/javadoc/doclet/testSinceTag/TestSinceTag.java ! test/jdk/javadoc/doclet/testSingleQuotedLink/TestSingleQuotedLink.java ! test/jdk/javadoc/doclet/testSourceTab/TestSourceTab.java ! test/jdk/javadoc/doclet/testStylesheet/TestStylesheet.java ! test/jdk/javadoc/doclet/testSubTitle/TestSubTitle.java ! test/jdk/javadoc/doclet/testSummaryHeading/TestSummaryHeading.java ! test/jdk/javadoc/doclet/testSuperclassInSerialForm/TestSuperClassInSerialForm.java ! test/jdk/javadoc/doclet/testSupplementary/TestSupplementary.java ! test/jdk/javadoc/doclet/testTagInheritence/TestTagInheritence.java ! test/jdk/javadoc/doclet/testTagMisuse/TestTagMisuse.java ! test/jdk/javadoc/doclet/testTagOutput/TestTagOutput.java ! test/jdk/javadoc/doclet/testThrowsHead/TestThrowsHead.java ! test/jdk/javadoc/doclet/testThrowsInheritence/TestThrowsTagInheritence.java ! test/jdk/javadoc/doclet/testThrowsTag/TestThrowsTag.java ! test/jdk/javadoc/doclet/testTitleInHref/TestTitleInHref.java ! test/jdk/javadoc/doclet/testTopOption/TestTopOption.java ! test/jdk/javadoc/doclet/testTypeAnnotations/TestTypeAnnotations.java ! test/jdk/javadoc/doclet/testTypeParams/TestTypeParameters.java ! test/jdk/javadoc/doclet/testUnnamedPackage/TestUnnamedPackage.java ! test/jdk/javadoc/doclet/testUseOption/TestUseOption.java ! test/jdk/javadoc/doclet/testValueTag/TestValueTag.java ! test/jdk/javadoc/doclet/testWarnBadParamNames/TestWarnBadParamNames.java ! test/jdk/javadoc/doclet/testWindowTitle/TestWindowTitle.java ! test/jdk/javadoc/doclet/testXOption/TestXOption.java ! test/jdk/javadoc/doclet/typeAnnotations/smoke/TestSmoke.java ! test/jdk/javadoc/tool/6227454/Test.java ! test/jdk/javadoc/tool/6942366/T6942366.java ! test/jdk/javadoc/tool/6958836/Test.java ! test/jdk/javadoc/tool/6964914/Test.java ! test/jdk/javadoc/tool/6964914/TestStdDoclet.java ! test/jdk/javadoc/tool/6964914/TestUserDoclet.java ! test/jdk/javadoc/tool/BreakIteratorWarning.java ! test/jdk/javadoc/tool/CheckResourceKeys.java ! test/jdk/javadoc/tool/EnsureNewOldDoclet.java ! test/jdk/javadoc/tool/FlagsTooEarly.java ! test/jdk/javadoc/tool/MaxWarns.java ! test/jdk/javadoc/tool/NoStar.java ! test/jdk/javadoc/tool/QuietOption.java ! test/jdk/javadoc/tool/ReleaseOption.java ! test/jdk/javadoc/tool/T4994049/T4994049.java ! test/jdk/javadoc/tool/T6551367.java ! test/jdk/javadoc/tool/T6968833.java ! test/jdk/javadoc/tool/VerifyLocale.java ! test/jdk/javadoc/tool/XWerror.java ! test/jdk/javadoc/tool/api/basic/JavadocTaskImplTest.java ! test/jdk/javadoc/tool/completionFailure/CompletionFailure.java ! test/jdk/javadoc/tool/doclint/DocLintTest.java ! test/jdk/javadoc/tool/doclint/ImplicitHeadersTest.java ! test/jdk/javadoc/tool/dupOk/DupOk.java ! test/jdk/javadoc/tool/nonConstExprs/Test.java ! test/jdk/javadoc/tool/outputRedirect/Test.java ! test/jdk/javadoc/tool/parser/7091528/T7091528.java ! test/jdk/jshell/ClassPathTest.java ! test/jdk/jshell/CommandCompletionTest.java ! test/jdk/jshell/CompletionSuggestionTest.java ! test/jdk/jshell/ComputeFQNsTest.java ! test/jdk/jshell/ErrorTranslationTest.java ! test/jdk/jshell/ImportTest.java ! test/jdk/jshell/InferTypeTest.java ! test/jdk/jshell/StartOptionTest.java ! test/jdk/jshell/T8146368/JShellToolTest8146368.java ! test/jdk/jshell/ToolFormatTest.java ! test/jdk/jshell/ToolReloadTest.java ! test/lib/annotations/annotations/classfile/ClassfileInspector.java ! test/tools/all/RunCodingRules.java ! test/tools/doclint/tool/PathsTest.java ! test/tools/javac/4846262/CheckEBCDICLocaleTest.java ! test/tools/javac/6302184/HiddenOptionsShouldUseGivenEncodingTest.java ! test/tools/javac/6330997/T6330997.java ! test/tools/javac/6403424/T6403424.java ! test/tools/javac/6508981/TestInferBinaryName.java ! test/tools/javac/6589361/T6589361.java ! test/tools/javac/6627362/T6627362.java ! test/tools/javac/6889255/T6889255.java ! test/tools/javac/AnonymousSubclassTest.java ! test/tools/javac/ClassPathTest/ClassPathTest.java ! test/tools/javac/ConstFoldTest.java ! test/tools/javac/Diagnostics/6769027/T6769027.java ! test/tools/javac/ExtDirs/ExtDirTest.java ! test/tools/javac/IncorrectInheritance/IncorrectInheritanceTest.java ! test/tools/javac/MethodParameters/AttributeVisitor.java ! test/tools/javac/MethodParametersTest.java ! test/tools/javac/MissingInclude/MissingIncludeTest.java - test/tools/javac/Object1.java - test/tools/javac/Object1.out - test/tools/javac/Object2.java - test/tools/javac/Object2.out ! test/tools/javac/Paths/AbsolutePathTest.java ! test/tools/javac/Paths/Diagnostics.sh ! test/tools/javac/ProtectedInnerClass/ProtectedInnerClassesTest.java ! test/tools/javac/T4093617/T4093617.java ! test/tools/javac/T4093617/T4093617.out + test/tools/javac/T4093617/java.base/Object.java ! test/tools/javac/T4965689/ClassLiteralWastesByteTest.java ! test/tools/javac/T5053846/MethodRefDupInConstantPoolTest.java ! test/tools/javac/T5090006/AssertionFailureTest.java ! test/tools/javac/T6181889/EmptyFinallyTest.java ! test/tools/javac/T6358024.java ! test/tools/javac/T6358166.java ! test/tools/javac/T6403466.java ! test/tools/javac/T6405099.java ! test/tools/javac/T6406771.java ! test/tools/javac/T6435291/T6435291.java ! test/tools/javac/T6558476.java ! test/tools/javac/T6725036.java ! test/tools/javac/T6942649.java ! test/tools/javac/T6970173/DebugPointerAtBadPositionTest.java ! test/tools/javac/T6972327.java ! test/tools/javac/T6985181.java ! test/tools/javac/T6993301.java ! test/tools/javac/T7008643/InlinedFinallyConfuseDebuggersTest.java ! test/tools/javac/T7040592/T7040592.java ! test/tools/javac/T8003967/DetectMutableStaticFields.java ! test/tools/javac/T8009640/CheckRejectProfileBCPOptionsIfUsedTogetherTest.java ! test/tools/javac/T8010659/CompilerCrashWhenMixingBinariesAndSourcesTest.java ! test/tools/javac/T8010737/ParameterNamesAreNotCopiedToAnonymousInitTest.java ! test/tools/javac/T8013394/CompileErrorWithIteratorTest.java ! test/tools/javac/T8019486/WrongLNTForLambdaTest.java ! test/tools/javac/T8022162/IncorrectSignatureDeterminationForInnerClassesTest.java ! test/tools/javac/T8024039/NoDeadCodeGenerationOnTrySmtTest.java ! test/tools/javac/T8024437/ExceptionInferenceFromClassFileTest.java ! test/tools/javac/TryWithResources/TwrForVariable3.out ! test/tools/javac/VersionOpt.java ! test/tools/javac/annotations/SyntheticParameters.java ! test/tools/javac/annotations/typeAnnotations/TypeProcOnly.java ! test/tools/javac/annotations/typeAnnotations/classfile/NestedLambdasCastedTest.java ! test/tools/javac/annotations/typeAnnotations/packageanno/PackageProcessor.java ! test/tools/javac/api/6400303/T6400303.java ! test/tools/javac/api/6412656/T6412656.java ! test/tools/javac/api/6418694/T6418694.java ! test/tools/javac/api/6440528/T6440528.java ! test/tools/javac/api/6557752/T6557752.java ! test/tools/javac/api/6852595/T6852595.java ! test/tools/javac/api/T6358786.java ! test/tools/javac/api/T6397104.java ! test/tools/javac/api/T6412669.java ! test/tools/javac/api/TestClientCodeWrapper.java ! test/tools/javac/api/TestGetElementReference.java ! test/tools/javac/api/TestJavacTask.java ! test/tools/javac/api/TestJavacTaskScanner.java ! test/tools/javac/api/TestResolveError.java ! test/tools/javac/api/TestResolveIdent.java ! test/tools/javac/api/TestSearchPaths.java ! test/tools/javac/api/TestTrees.java ! test/tools/javac/api/ToolProvider/HelloWorldTest.java ! test/tools/javac/api/ToolProvider/ToolProviderTest1.java ! test/tools/javac/api/ToolProvider/ToolProviderTest2.java + test/tools/javac/api/mod/api/pkg/Api.java + test/tools/javac/api/mod/module-info.java ! test/tools/javac/api/taskListeners/CompileEvent.java ! test/tools/javac/boxing/IncrementBoxedAndAccess.java ! test/tools/javac/cast/intersection/model/Model01.java ! test/tools/javac/cast/intersection/model/ModelChecker.java ! test/tools/javac/classfiles/InnerClasses/T8068517.java ! test/tools/javac/classfiles/attributes/AnnotationDefault/AnnotationDefaultTest.java ! test/tools/javac/classfiles/attributes/EnclosingMethod/EnclosingMethodTest.java ! test/tools/javac/classfiles/attributes/LineNumberTable/LineNumberTest.java ! test/tools/javac/classfiles/attributes/LocalVariableTable/LocalVariableTableTest.java ! test/tools/javac/classfiles/attributes/LocalVariableTable/LocalVariableTypeTableTest.java + test/tools/javac/classfiles/attributes/Module/ModuleFlagTest.java + test/tools/javac/classfiles/attributes/Module/ModuleTest.java + test/tools/javac/classfiles/attributes/Module/ModuleTestBase.java ! test/tools/javac/classfiles/attributes/Signature/ConstructorTest.java ! test/tools/javac/classfiles/attributes/Signature/EnumTest.java ! test/tools/javac/classfiles/attributes/Signature/ExceptionTest.java ! test/tools/javac/classfiles/attributes/Signature/FieldTest.java ! test/tools/javac/classfiles/attributes/Signature/InnerClassTest.java ! test/tools/javac/classfiles/attributes/Signature/MethodParameterTest.java ! test/tools/javac/classfiles/attributes/Signature/MethodTypeBoundTest.java ! test/tools/javac/classfiles/attributes/Signature/ReturnTypeTest.java ! test/tools/javac/classfiles/attributes/SourceFile/AnonymousClassTest.java ! test/tools/javac/classfiles/attributes/SourceFile/InnerClassTest.java ! test/tools/javac/classfiles/attributes/SourceFile/LocalClassTest.java ! test/tools/javac/classfiles/attributes/SourceFile/MixTest.java + test/tools/javac/classfiles/attributes/SourceFile/ModuleInfoTest.java ! test/tools/javac/classfiles/attributes/SourceFile/NoSourceFileAttribute.java ! test/tools/javac/classfiles/attributes/SourceFile/SourceFileTestBase.java ! test/tools/javac/classfiles/attributes/SourceFile/SyntheticClassTest.java ! test/tools/javac/classfiles/attributes/SourceFile/TopLevelClassesOneFileTest.java ! test/tools/javac/classfiles/attributes/Synthetic/AccessToPrivateInnerClassMembersTest.java ! test/tools/javac/classfiles/attributes/Synthetic/AccessToPrivateSiblingsTest.java ! test/tools/javac/classfiles/attributes/Synthetic/AssertFieldTest.java ! test/tools/javac/classfiles/attributes/Synthetic/BridgeMethodForGenericMethodTest.java ! test/tools/javac/classfiles/attributes/Synthetic/BridgeMethodsForLambdaTest.java ! test/tools/javac/classfiles/attributes/Synthetic/EnumTest.java ! test/tools/javac/classfiles/attributes/Synthetic/PackageInfoTest.java ! test/tools/javac/classfiles/attributes/Synthetic/ThisFieldTest.java ! test/tools/javac/classfiles/attributes/annotations/RuntimeAnnotationsForGenericMethodTest.java ! test/tools/javac/classfiles/attributes/annotations/RuntimeAnnotationsForInnerAnnotationTest.java ! test/tools/javac/classfiles/attributes/annotations/RuntimeAnnotationsForInnerClassTest.java ! test/tools/javac/classfiles/attributes/annotations/RuntimeAnnotationsForInnerEnumTest.java ! test/tools/javac/classfiles/attributes/annotations/RuntimeAnnotationsForInnerInterfaceTest.java ! test/tools/javac/classfiles/attributes/annotations/RuntimeAnnotationsForTopLevelClassTest.java ! test/tools/javac/classfiles/attributes/annotations/RuntimeParameterAnnotationsForGenericMethodTest.java ! test/tools/javac/classfiles/attributes/annotations/RuntimeParameterAnnotationsForLambdaTest.java ! test/tools/javac/classfiles/attributes/annotations/RuntimeParameterAnnotationsTest.java ! test/tools/javac/classfiles/attributes/deprecated/DeprecatedPackageTest.java ! test/tools/javac/classfiles/attributes/deprecated/DeprecatedTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerAnnotationsInInnerAnnotationTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerAnnotationsInInnerClassTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerAnnotationsInInnerEnumTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerAnnotationsInInnerInterfaceTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerClassesHierarchyTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerClassesInAnonymousClassTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerClassesInInnerAnnotationTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerClassesInInnerClassTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerClassesInInnerEnumTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerClassesInInnerInterfaceTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerClassesInLocalClassTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerClassesIndexTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerClassesTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerEnumInInnerAnnotationTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerEnumInInnerEnumTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerEnumInInnerInterfaceTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerEnumsInInnerClassTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerInterfacesInInnerAnnotationTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerInterfacesInInnerClassTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerInterfacesInInnerEnumTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerInterfacesInInnerInterfaceTest.java ! test/tools/javac/classfiles/attributes/innerclasses/NoInnerClassesTest.java ! test/tools/javac/classfiles/attributes/lib/TestResult.java ! test/tools/javac/code/ArrayClone.java ! test/tools/javac/defaultMethods/AssertionsTest.java ! test/tools/javac/defaultMethods/BadClassfile.java ! test/tools/javac/defaultMethodsVisibility/DefaultMethodsNotVisibleForSourceLessThan8Test.java ! test/tools/javac/diags/CheckExamples.java ! test/tools/javac/diags/CheckResourceKeys.java ! test/tools/javac/diags/DocCommentProcessor.java ! test/tools/javac/diags/Example.java ! test/tools/javac/diags/FileManager.java ! test/tools/javac/diags/examples.not-yet.txt ! test/tools/javac/diags/examples/DirPathElementNotFound.java ! test/tools/javac/diags/examples/InvalidDefaultInterface/InvalidDefaultInterface.java ! test/tools/javac/diags/examples/InvalidDefaultInterface/processors/CreateBadClassFile.java ! test/tools/javac/diags/examples/InvalidStaticInterface/InvalidStaticInterface.java ! test/tools/javac/diags/examples/InvalidStaticInterface/processors/CreateBadClassFile.java ! test/tools/javac/diags/examples/NoJavaLang.java ! test/tools/javac/diags/examples/NoSuperclass.java ! test/tools/javac/doctree/ReferenceTest.java ! test/tools/javac/fatalErrors/NoJavaLangTest.java ! test/tools/javac/file/ExplodedImage.java ! test/tools/javac/file/T7018098.java ! test/tools/javac/generics/diamond/neg/T8078473_2.java ! test/tools/javac/importscope/CompletionFailureDuringImport.java ! test/tools/javac/importscope/ImportDependenciesTest.java ! test/tools/javac/importscope/ImportMembersTest.java ! test/tools/javac/importscope/NegativeCyclicDependencyTest.java ! test/tools/javac/innerClassFile/InnerClassFileTest.java ! test/tools/javac/javazip/JavaZipTest.java ! test/tools/javac/lambda/AvoidInfiniteReattribution.java ! test/tools/javac/lambda/LambdaInnerTypeVarReflect.java ! test/tools/javac/lambda/T8129740/SourceToSourceTranslationTest.java ! test/tools/javac/lambda/TestBootstrapMethodsCount.java ! test/tools/javac/lambda/bridge/TestMetafactoryBridges.java ! test/tools/javac/lambda/bridge/template_tests/TEST.properties ! test/tools/javac/lambda/lambdaNaming/TestNonSerializableLambdaNameStability.java ! test/tools/javac/lambda/lambdaNaming/TestSerializedLambdaNameStability.java ! test/tools/javac/lambdaShapes/TEST.properties ! test/tools/javac/lib/DPrinter.java ! test/tools/javac/lib/JavacTestingAbstractProcessor.java ! test/tools/javac/lib/combo/ReusableContext.java ! test/tools/javac/limits/NumArgsTest.java ! test/tools/javac/links/LinksTest.java + test/tools/javac/modules/AbstractOrInnerClassServiceImplTest.java + test/tools/javac/modules/AddLimitMods.java + test/tools/javac/modules/AddReadsTest.java + test/tools/javac/modules/AnnotationProcessing.java + test/tools/javac/modules/AnnotationProcessorsInModulesTest.java + test/tools/javac/modules/AutomaticModules.java + test/tools/javac/modules/DoclintOtherModules.java + test/tools/javac/modules/DuplicateClassTest.java + test/tools/javac/modules/EdgeCases.java + test/tools/javac/modules/GraphsTest.java + test/tools/javac/modules/HelloWorldTest.java + test/tools/javac/modules/MOptionTest.java + test/tools/javac/modules/ModuleFinderTest.java + test/tools/javac/modules/ModuleInfoTest.java + test/tools/javac/modules/ModulePathTest.java + test/tools/javac/modules/ModuleSourcePathTest.java + test/tools/javac/modules/ModuleTestBase.java + test/tools/javac/modules/ModulesAndClassPathTest.java + test/tools/javac/modules/MultiModuleModeTest.java + test/tools/javac/modules/NPEEmptyFileTest.java + test/tools/javac/modules/OutputDirTest.java + test/tools/javac/modules/PackageConflictTest.java + test/tools/javac/modules/PackageMultipleModules.java + test/tools/javac/modules/PluginsInModulesTest.java + test/tools/javac/modules/ProvidesTest.java + test/tools/javac/modules/QueryBeforeEnter.java + test/tools/javac/modules/RepeatedUsesAndProvidesTest.java + test/tools/javac/modules/ReportNonExistentPackageTest.java + test/tools/javac/modules/RequiresPublicTest.java + test/tools/javac/modules/ResolveTest.java + test/tools/javac/modules/ServiceInStaticClassErrorTest.java + test/tools/javac/modules/ServiceProvidedButNotExportedOrUsedTest.java + test/tools/javac/modules/SingleModuleModeTest.java + test/tools/javac/modules/SubpackageTest.java + test/tools/javac/modules/UpgradeModulePathTest.java + test/tools/javac/modules/UsesTest.java + test/tools/javac/modules/XModuleTest.java ! test/tools/javac/newlines/NewLineTest.java ! test/tools/javac/options/modes/Tester.java ! test/tools/javac/options/xprefer/XPreferTest.java ! test/tools/javac/platform/PlatformProviderTest.java ! test/tools/javac/plugin/showtype/Test.java ! test/tools/javac/processing/T8142931.java ! test/tools/javac/processing/environment/ProcessingEnvAnnoDiscovery.java ! test/tools/javac/processing/errors/EnsureAnnotationTypeMismatchException/Processor.java ! test/tools/javac/processing/errors/EnsureAnnotationTypeMismatchException/Source.java ! test/tools/javac/processing/errors/EnsureMirroredTypeException/Processor.java ! test/tools/javac/processing/errors/EnsureMirroredTypeException/Source.java ! test/tools/javac/processing/errors/StopOnInapplicableAnnotations/GenerateFunctionalInterface.java ! test/tools/javac/processing/errors/StopOnInapplicableAnnotations/GenerateSuperInterfaceProcessor.java ! test/tools/javac/processing/errors/TestBadProcessor.java ! test/tools/javac/processing/loader/testClose/TestClose.java ! test/tools/javac/processing/loader/testClose/TestClose2.java ! test/tools/javac/processing/messager/MessagerDiags.java ! test/tools/javac/processing/model/TestSymtabItems.java ! test/tools/javac/processing/model/element/8009367/TestQualifiedNameUsed.java ! test/tools/javac/processing/model/element/TestEmptyContainer.java ! test/tools/javac/processing/model/element/TestMissingElement/TestMissingElement.java ! test/tools/javac/processing/model/element/TestNonInherited.java ! test/tools/javac/processing/model/inheritedByType/EnsureOrder.java ! test/tools/javac/processing/model/testgetallmembers/Main.java ! test/tools/javac/processing/model/type/BasicAnnoTests.java ! test/tools/javac/processing/model/type/BoundsTest.java ! test/tools/javac/processing/model/type/NoTypes.java ! test/tools/javac/processing/rounds/BaseClassesNotReRead.java ! test/tools/javac/processing/rounds/CompleteOnClosed.java ! test/tools/javac/processing/rounds/OverwriteBetweenCompilations.java - test/tools/javac/profiles/ProfileTest.java - test/tools/javac/proprietary/WarnClass.java - test/tools/javac/proprietary/WarnClass.out - test/tools/javac/proprietary/WarnImport.java - test/tools/javac/proprietary/WarnImport.out - test/tools/javac/proprietary/WarnMethod.java - test/tools/javac/proprietary/WarnMethod.out - test/tools/javac/proprietary/WarnStaticImport.java - test/tools/javac/proprietary/WarnStaticImport.out - test/tools/javac/proprietary/WarnVariable.java - test/tools/javac/proprietary/WarnVariable.out - test/tools/javac/proprietary/WarnWildcard.java - test/tools/javac/proprietary/WarnWildcard.out + test/tools/javac/redefineObject/Object1-test.java + test/tools/javac/redefineObject/Object1.out + test/tools/javac/redefineObject/Object2-test.java + test/tools/javac/redefineObject/Object2.out + test/tools/javac/redefineObject/java.base/Object1.java + test/tools/javac/redefineObject/java.base/Object2.java ! test/tools/javac/resolve/BitWiseOperators.java ! test/tools/javac/scope/DupUnsharedTest.java ! test/tools/javac/scope/HashCollisionTest.java ! test/tools/javac/scope/RemoveSymbolUnitTest.java ! test/tools/javac/scope/StarImportTest.java ! test/tools/javac/stackmap/StackMapTest.java ! test/tools/javac/sym/ElementStructureTest.java - test/tools/javac/synthesize/Boolean.java - test/tools/javac/synthesize/Byte.java - test/tools/javac/synthesize/Character.java - test/tools/javac/synthesize/Cloneable.java - test/tools/javac/synthesize/Double.java - test/tools/javac/synthesize/Float.java - test/tools/javac/synthesize/Integer.java - test/tools/javac/synthesize/Long.java ! test/tools/javac/synthesize/Main.java - test/tools/javac/synthesize/Number.java - test/tools/javac/synthesize/Object.java - test/tools/javac/synthesize/Serializable.java - test/tools/javac/synthesize/Short.java - test/tools/javac/synthesize/Test.java - test/tools/javac/synthesize/Void.java + test/tools/javac/synthesize/src/Boolean.java + test/tools/javac/synthesize/src/Byte.java + test/tools/javac/synthesize/src/Character.java + test/tools/javac/synthesize/src/Cloneable.java + test/tools/javac/synthesize/src/Double.java + test/tools/javac/synthesize/src/Float.java + test/tools/javac/synthesize/src/Integer.java + test/tools/javac/synthesize/src/Long.java + test/tools/javac/synthesize/src/Number.java + test/tools/javac/synthesize/src/Object.java + test/tools/javac/synthesize/src/Serializable.java + test/tools/javac/synthesize/src/Short.java + test/tools/javac/synthesize/src/Test.java + test/tools/javac/synthesize/src/Void.java + test/tools/javac/synthesize/src/module-info.java ! test/tools/javac/tree/8067914/NukeExtraCast.java ! test/tools/javac/tree/ArrayTypeToString.java ! test/tools/javac/tree/MakeTypeTest.java ! test/tools/javac/tree/ScopeTest.java ! test/tools/javac/treeannotests/AnnoTreeTests.java ! test/tools/javac/treeannotests/TestProcessor.java ! test/tools/javac/types/ScopeListenerTest.java ! test/tools/javac/types/TestComparisons.java ! test/tools/javac/util/T6597678.java ! test/tools/javac/warnings/6594914/T6594914b.out ! test/tools/javac/warnings/VerifyLintDescriptions.java ! test/tools/javadoc/6227454/Test.java ! test/tools/javadoc/6964914/Test.java ! test/tools/javadoc/6964914/TestStdDoclet.java ! test/tools/javadoc/6964914/TestUserDoclet.java ! test/tools/javadoc/CheckResourceKeys.java ! test/tools/javadoc/CompletionError.java ! test/tools/javadoc/api/basic/TagletPathTest.java ! test/tools/javah/6257087/T6257087.java + test/tools/javah/ModuleClass.java ! test/tools/javah/T4942232/MissingParamClassTest.java ! test/tools/javah/constMacroTest/ConstMacroTest.java ! test/tools/javap/4111861/T4111861.java ! test/tools/javap/4798312/JavapShouldLoadClassesFromRTJarTest.java ! test/tools/javap/4866831/PublicInterfaceTest.java ! test/tools/javap/4870651/T4870651.java ! test/tools/javap/6937244/T6937244.java ! test/tools/javap/6937244/T6937244A.java ! test/tools/javap/8006334/JavapTaskCtorFailWithNPE.java ! test/tools/javap/8007907/JavapReturns0AfterClassNotFoundTest.java ! test/tools/javap/AccessModifiers.java ! test/tools/javap/BadAttributeLength.java ! test/tools/javap/BoundsTypeVariableTest.java ! test/tools/javap/DescriptorTest.java ! test/tools/javap/ExtPath.java ! test/tools/javap/InvalidOptions.java ! test/tools/javap/MethodParameters.java ! test/tools/javap/StackMapTableTest.java ! test/tools/javap/T4075403.java ! test/tools/javap/T4459541.java ! test/tools/javap/T4501660.java ! test/tools/javap/T4501661.java ! test/tools/javap/T4777949.java ! test/tools/javap/T4876942.java ! test/tools/javap/T4880663.java ! test/tools/javap/T4880672.java ! test/tools/javap/T4884240.java ! test/tools/javap/T4975569.java ! test/tools/javap/T6271787.java ! test/tools/javap/T6474890.java ! test/tools/javap/T6587786.java ! test/tools/javap/T6622216.java ! test/tools/javap/T6622232.java ! test/tools/javap/T6622260.java ! test/tools/javap/T6715251.java ! test/tools/javap/T6715753.java ! test/tools/javap/T6715767.java ! test/tools/javap/T6729471.java ! test/tools/javap/T6824493.java ! test/tools/javap/T6863746.java ! test/tools/javap/T6866657.java ! test/tools/javap/T6868539.java ! test/tools/javap/T6879371.java ! test/tools/javap/T6980017.java ! test/tools/javap/T7004698.java ! test/tools/javap/T7186925.java ! test/tools/javap/T7190862.java ! test/tools/javap/T8032814.java ! test/tools/javap/T8032819.java ! test/tools/javap/T8033180.java ! test/tools/javap/T8033711.java ! test/tools/javap/T8035104.java ! test/tools/javap/T8038414.java ! test/tools/javap/TestSuperclass.java ! test/tools/javap/WhitespaceTest.java ! test/tools/javap/classfile/6888367/T6888367.java ! test/tools/javap/stackmap/StackmapTest.java ! test/tools/javap/typeAnnotations/T6855990.java ! test/tools/jdeps/APIDeps.java ! test/tools/jdeps/Basic.java + test/tools/jdeps/CompilerUtils.java ! test/tools/jdeps/DotFileTest.java ! test/tools/jdeps/VerboseFormat/JdepsDependencyClosure.java + test/tools/jdeps/VerboseFormat/use/indirect/DontUseJdkInternal2.java - test/tools/jdeps/VerboseFormat/use/indirect/DontUseUnsafe2.java + test/tools/jdeps/VerboseFormat/use/indirect/UseJdkInternalIndirectly.java - test/tools/jdeps/VerboseFormat/use/indirect/UseUnsafeIndirectly.java + test/tools/jdeps/VerboseFormat/use/indirect2/DontUseJdkInternal3.java - test/tools/jdeps/VerboseFormat/use/indirect2/DontUseUnsafe3.java + test/tools/jdeps/VerboseFormat/use/indirect2/UseJdkInternalIndirectly2.java - test/tools/jdeps/VerboseFormat/use/indirect2/UseUnsafeIndirectly2.java + test/tools/jdeps/VerboseFormat/use/internal/DontUseJdkInternal.java + test/tools/jdeps/VerboseFormat/use/internal/UseClassWithJdkInternal.java + test/tools/jdeps/VerboseFormat/use/internal/UseJdkInternalClass.java + test/tools/jdeps/VerboseFormat/use/internal/UseJdkInternalClass2.java - test/tools/jdeps/VerboseFormat/use/unsafe/DontUseUnsafe.java - test/tools/jdeps/VerboseFormat/use/unsafe/UseClassWithUnsafe.java - test/tools/jdeps/VerboseFormat/use/unsafe/UseUnsafeClass.java - test/tools/jdeps/VerboseFormat/use/unsafe/UseUnsafeClass2.java ! test/tools/jdeps/f/F.java - test/tools/jdeps/javax/activity/NotCompactProfile.java + test/tools/jdeps/jdk.unsupported/Foo.java + test/tools/jdeps/jdk.unsupported/JDKUnsupportedTest.java + test/tools/jdeps/modules/GenModuleInfo.java + test/tools/jdeps/modules/ModuleTest.java + test/tools/jdeps/modules/src/m1/module-info.java + test/tools/jdeps/modules/src/m1/p1/Goo.java + test/tools/jdeps/modules/src/m1/p1/Lib.java + test/tools/jdeps/modules/src/m1/p1/S.java + test/tools/jdeps/modules/src/m1/p1/internal/Impl.java + test/tools/jdeps/modules/src/m2/module-info.java + test/tools/jdeps/modules/src/m2/p2/Bar.java + test/tools/jdeps/modules/src/m2/p2/internal/T2.java + test/tools/jdeps/modules/src/m3/module-info.java + test/tools/jdeps/modules/src/m3/p3/Foo.java + test/tools/jdeps/modules/src/m3/p3/Main.java + test/tools/jdeps/modules/src/m4/module-info.java + test/tools/jdeps/modules/src/m4/p4/Lib.java + test/tools/jdeps/modules/src/m4/p4/internal/Impl.java + test/tools/jdeps/modules/src/unsupported/module-info.java + test/tools/jdeps/modules/src/unsupported/q/Counter.java ! test/tools/jdeps/p/Bar.java ! test/tools/lib/ToolBox.java ! test/tools/sjavac/ApiExtraction.java ! test/tools/sjavac/ClasspathDependencies.java ! test/tools/sjavac/CompileCircularSources.java ! test/tools/sjavac/CompileExcludingDependency.java ! test/tools/sjavac/CompileWithAtFile.java ! test/tools/sjavac/CompileWithInvisibleSources.java ! test/tools/sjavac/CompileWithOverrideSources.java ! test/tools/sjavac/HiddenFiles.java ! test/tools/sjavac/IncCompInheritance.java ! test/tools/sjavac/IncCompileChangeNative.java ! test/tools/sjavac/IncCompileDropClasses.java ! test/tools/sjavac/IncCompileFullyQualifiedRef.java ! test/tools/sjavac/IncCompileNoChanges.java ! test/tools/sjavac/IncCompileUpdateNative.java ! test/tools/sjavac/IncCompileWithChanges.java ! test/tools/sjavac/IncludeExcludePatterns.java ! test/tools/sjavac/NoState.java ! test/tools/sjavac/OverlappingSrcDst.java ! test/tools/sjavac/PackagePathMismatch.java ! test/tools/sjavac/ParallelCompilations.java ! test/tools/sjavac/PermittedArtifact.java ! test/tools/sjavac/StateDir.java From mandy.chung at oracle.com Thu Mar 17 20:03:01 2016 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 17 Mar 2016 20:03:01 +0000 Subject: hg: jigsaw/m3/nashorn: 8142968: Module System implementation Message-ID: <201603172003.u2HK31op006763@aojmv0008.oracle.com> Changeset: 133ea8746b37 Author: alanb Date: 2016-03-17 19:04 +0000 URL: http://hg.openjdk.java.net/jigsaw/m3/nashorn/rev/133ea8746b37 8142968: Module System implementation Summary: Initial integration of JEP 200, JEP 260, JEP 261, and JEP 282 Reviewed-by: mhaupt, hannesw Contributed-by: alan.bateman at oracle.com, alex.buckley at oracle.com, jonathan.gibbons at oracle.com, karen.kinnear at oracle.com, mandy.chung at oracle.com, mark.reinhold at oracle.com, sundararajan.athijegannathan at oracle.com, erik.joelsson at oracle.com ! buildtools/nasgen/build.xml ! buildtools/nasgen/project.properties ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ClassGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/MemberInfo.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/MethodGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInfo.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInfoCollector.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInstrumentor.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/StringConstants.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/Where.java ! make/BuildNashorn.gmk ! make/build-nasgen.xml ! make/build.xml ! make/nbproject/ide-targets.xml ! make/project.properties ! samples/test.js ! src/jdk.dynalink/share/classes/jdk/dynalink/DynamicLinkerFactory.java ! src/jdk.dynalink/share/classes/jdk/dynalink/beans/CallerSensitiveDynamicMethod.java ! src/jdk.dynalink/share/classes/jdk/dynalink/beans/CheckRestrictedPackage.java ! src/jdk.dynalink/share/classes/jdk/dynalink/linker/support/Lookup.java + src/jdk.dynalink/share/classes/module-info.java + src/jdk.scripting.nashorn.shell/share/classes/module-info.java - src/jdk.scripting.nashorn/share/classes/META-INF/MANIFEST.MF - src/jdk.scripting.nashorn/share/classes/META-INF/services/javax.script.ScriptEngineFactory ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/OptimisticTypesPersistence.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/NashornLoader.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptLoader.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Source.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/StructureLoader.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaAdapterClassLoader.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaAdapterServices.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java + src/jdk.scripting.nashorn/share/classes/module-info.java ! test/TEST.ROOT ! test/script/currently-failing/JDK-8055034.js ! test/script/nosecurity/JDK-8044798.js ! test/script/nosecurity/JDK-8044851.js ! test/script/nosecurity/JDK-8067215.js ! test/script/nosecurity/JDK-8078049.js ! test/script/trusted/classfilter_extends.js.EXPECTED ! test/script/trusted/classfilter_mozilla_compat.js.EXPECTED ! test/script/trusted/event_queue.js ! test/script/trusted/optimistic_recompilation.js ! test/src/jdk/nashorn/internal/runtime/doubleconv/test/BignumTest.java ! test/src/jdk/nashorn/internal/runtime/doubleconv/test/DiyFpTest.java ! test/src/jdk/nashorn/internal/runtime/regexp/joni/test/JoniTest.java ! test/src/jdk/nashorn/internal/runtime/regexp/test/JdkRegExpTest.java ! test/src/jdk/nashorn/internal/runtime/test/ConsStringTest.java ! test/src/jdk/nashorn/internal/runtime/test/ContextTest.java ! test/src/jdk/nashorn/internal/runtime/test/ExceptionsNotSerializable.java ! test/src/jdk/nashorn/internal/runtime/test/JDK_8078414_Test.java ! test/src/jdk/nashorn/internal/runtime/test/JSTypeTest.java ! test/src/jdk/nashorn/internal/test/framework/ScriptRunnable.java From Alan.Bateman at oracle.com Thu Mar 17 20:23:25 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 17 Mar 2016 20:23:25 +0000 Subject: modulepath and classpath mixture In-Reply-To: References: <56CBAD62.3010508@oracle.com> <20160316135501.530460938eggemoggin.niobe.net> Message-ID: <56EB123D.3060407@oracle.com> On 17/03/2016 19:51, Robert Scholte wrote: > : > > To me it seems like the need for knowing the module name keeps returning. > This increases the need for a proper implementation of the > maven-compiler-plugin as a multirelease JAR. > The pattern as shown during FOSDEM showed that the idea works, but it > is not solid enough. > And the next question would be: can Maven (or actually Plexus > ClassWorld) handle this? > > I'll need to work out the things to be done and try to get more Maven > developers involved. Would it you take it from the source module-info.class or the compiled module-info.class? The former would require a small parser. The latter is not difficult with ASM. -Alan From rfscholte at apache.org Fri Mar 18 07:56:00 2016 From: rfscholte at apache.org (Robert Scholte) Date: Fri, 18 Mar 2016 08:56:00 +0100 Subject: modulepath and classpath mixture In-Reply-To: <56EB123D.3060407@oracle.com> References: <56CBAD62.3010508@oracle.com> <20160316135501.530460938eggemoggin.niobe.net> <56EB123D.3060407@oracle.com> Message-ID: On Thu, 17 Mar 2016 21:23:25 +0100, Alan Bateman wrote: > > > On 17/03/2016 19:51, Robert Scholte wrote: >> : >> >> To me it seems like the need for knowing the module name keeps >> returning. >> This increases the need for a proper implementation of the >> maven-compiler-plugin as a multirelease JAR. >> The pattern as shown during FOSDEM showed that the idea works, but it >> is not solid enough. >> And the next question would be: can Maven (or actually Plexus >> ClassWorld) handle this? >> >> I'll need to work out the things to be done and try to get more Maven >> developers involved. > Would it you take it from the source module-info.class or the compiled > module-info.class? The former would require a small parser. The latter > is not difficult with ASM. > > -Alan I can do the former with QDox, for the latter I had JDK APIs in mind, but if ASM is an option too, that's an interesting option. Need to figure out how to do that. Robert From Alan.Bateman at oracle.com Fri Mar 18 08:29:40 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 18 Mar 2016 08:29:40 +0000 Subject: modulepath and classpath mixture In-Reply-To: References: <56CBAD62.3010508@oracle.com> <20160316135501.530460938eggemoggin.niobe.net> <56EB123D.3060407@oracle.com> Message-ID: <56EBBC74.3020204@oracle.com> On 18/03/2016 07:56, Robert Scholte wrote: > > I can do the former with QDox, for the latter I had JDK APIs in mind, > but if ASM is an option too, that's an interesting option. Need to > figure out how to do that. It should only be a few lines with ASM. If you have an input stream to the module-info.class then ASM's ClassReader will give you the class name in internal form and so easy to get the module name, this should do it: ClassReader reader = new ClassReader(in); String className = reader.getClassName(); int index = className.indexOf("/module-info"); if (index >= 1) { String moduleName = className.substring(0, index).replace('/', '.'); } Using the APIs will work too but if Maven is running on JDK 8 or older then it won't be able to make use of the new Java SE 9 APIs. -Alan. From huizhe.wang at oracle.com Sat Mar 19 23:14:53 2016 From: huizhe.wang at oracle.com (huizhe wang) Date: Sat, 19 Mar 2016 16:14:53 -0700 Subject: 8078820 -> Re: RFR: 8068938: Test deploying a XML parser as a module In-Reply-To: <56A8A593.80909@oracle.com> References: <01e401d14c1c$916b5220$b441f660$@oracle.com> <5694B4F3.1010002@oracle.com> <94E1094C-7ADB-4596-A9F8-4B64E97565E2@oracle.com> <56A7AD3A.5000601@oracle.com> <56A8A593.80909@oracle.com> Message-ID: <56EDDD6D.8050605@oracle.com> Saw Alan's update for JDK-8078820. 8078820 is the right id for this, isn't it? :-) 8068938 was a different issue that Sundar has already resolved. By the way, I just realized that the previous webrevs didn't include org.xml.sax.helpers.XMLReaderFactory. Would you want to add that too? Best, Joe On 1/27/2016 3:10 AM, Alan Bateman wrote: > > On 26/01/2016 17:30, huizhe wang wrote: >> Hi Felix, >> >> I would feel sorry for Frank since at the time we wanted all tests to >> be hosted in the JAXP repo. I understand the intention to consolidate >> repos as Alan suggested. However, if the JAXP repo is not hampering >> JDK development, I'd prefer an independent JAXP repo as is since it >> made JAXP dev much easier. That said, I have no objection to moving >> JAXP tests to JDK/test, that'll at least consolidate all of the tests >> and you may then take advantage of the JDK/test utilities for current >> and future test development. >> >> Alan, what would you think? > We're probably going a bit off-topic here but I don't see why we > persist with the jaxp repository. I think we should have moved the > code to the jdk repository a long time ago. In the short term then it > might be annoying to not have the revision history (hg log) but we've > been through this kinda of transition already. Also in the short term > then it might require you or others to do some adjustments to your IDE > setup but that shouldn't be a big deal, esp. with the source code > layout that we put in via the JEP 201 work. > > In any case, this all started with my comment about the tests being > split between the jdk and jaxp repo. What would it take to get the new > tests to be located with the existing jaxp tests? > > -Alan. From Alan.Bateman at oracle.com Mon Mar 21 09:09:12 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 21 Mar 2016 09:09:12 +0000 Subject: 8078820 -> Re: RFR: 8068938: Test deploying a XML parser as a module In-Reply-To: <56EDDD6D.8050605@oracle.com> References: <01e401d14c1c$916b5220$b441f660$@oracle.com> <5694B4F3.1010002@oracle.com> <94E1094C-7ADB-4596-A9F8-4B64E97565E2@oracle.com> <56A7AD3A.5000601@oracle.com> <56A8A593.80909@oracle.com> <56EDDD6D.8050605@oracle.com> Message-ID: <56EFBA38.2000201@oracle.com> On 19/03/2016 23:14, huizhe wang wrote: > Saw Alan's update for JDK-8078820. 8078820 is the right id for this, > isn't it? :-) 8068938 was a different issue that Sundar has already > resolved. > > By the way, I just realized that the previous webrevs didn't include > org.xml.sax.helpers.XMLReaderFactory. Would you want to add that too? Frank out the issue number is one of the previous mails, no big deal. Are you okay to work with him and figure out how to get these tests in jdk9/dev? Ideally all XML parsing tests would be in the same repo but that isn't something that we want to get tangled up in here. I think, as I've mentioned in this thread, is that we should get rid of the jaxp repo completely and just move the code and tests to the jdk repo. I don't thin this would be a huge effort. -Alan. From peter.levart at gmail.com Mon Mar 21 09:41:09 2016 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 21 Mar 2016 10:41:09 +0100 Subject: RFR: 8068938: Test deploying a XML parser as a module In-Reply-To: <56A8A593.80909@oracle.com> References: <01e401d14c1c$916b5220$b441f660$@oracle.com> <5694B4F3.1010002@oracle.com> <94E1094C-7ADB-4596-A9F8-4B64E97565E2@oracle.com> <56A7AD3A.5000601@oracle.com> <56A8A593.80909@oracle.com> Message-ID: <56EFC1B5.4000604@gmail.com> On 01/27/2016 12:10 PM, Alan Bateman wrote: > > On 26/01/2016 17:30, huizhe wang wrote: >> Hi Felix, >> >> I would feel sorry for Frank since at the time we wanted all tests to >> be hosted in the JAXP repo. I understand the intention to consolidate >> repos as Alan suggested. However, if the JAXP repo is not hampering >> JDK development, I'd prefer an independent JAXP repo as is since it >> made JAXP dev much easier. That said, I have no objection to moving >> JAXP tests to JDK/test, that'll at least consolidate all of the tests >> and you may then take advantage of the JDK/test utilities for current >> and future test development. >> >> Alan, what would you think? > We're probably going a bit off-topic here but I don't see why we > persist with the jaxp repository. I think we should have moved the > code to the jdk repository a long time ago. In the short term then it > might be annoying to not have the revision history (hg log) There might be a way to import jaxp repository into a subdirectory of jdk repository with all the history: http://stackoverflow.com/questions/3214717/how-can-i-import-a-mercurial-repo-including-history-into-another-mercurial-rep ...but I don't know if you'd want to do that. I haven't tried it, but I think this would look in jdk repo as though all changes in jaxp code were done at a particular point in history when you did the merge. And you'd end up with two unrelated histories for jaxp code - the one from jaxp repository and the other from jdk repository. The one in jdk repo would have different hashes. Old references from Jira would of course point to jaxp repo and would not be trivially convertible to corresponding changesets in jdk repo, but you would get an uninterrupted history of changes, which is sometimes useful. Regards, Peter > but we've been through this kinda of transition already. Also in the > short term then it might require you or others to do some adjustments > to your IDE setup but that shouldn't be a big deal, esp. with the > source code layout that we put in via the JEP 201 work. > > In any case, this all started with my comment about the tests being > split between the jdk and jaxp repo. What would it take to get the new > tests to be located with the existing jaxp tests? > > -Alan. From frank.yuan at oracle.com Mon Mar 21 09:44:07 2016 From: frank.yuan at oracle.com (Frank Yuan) Date: Mon, 21 Mar 2016 17:44:07 +0800 Subject: 8078820 -> Re: RFR: 8068938: Test deploying a XML parser as a module In-Reply-To: <56EDDD6D.8050605@oracle.com> References: <01e401d14c1c$916b5220$b441f660$@oracle.com> <5694B4F3.1010002@oracle.com> <94E1094C-7ADB-4596-A9F8-4B64E97565E2@oracle.com> <56A7AD3A.5000601@oracle.com> <56A8A593.80909@oracle.com> <56EDDD6D.8050605@oracle.com> Message-ID: <066501d18356$3b394490$b1abcdb0$@oracle.com> From: huizhe wang [mailto:huizhe.wang at oracle.com] Sent: Sunday, March 20, 2016 7:15 AM To: Frank Yuan Cc: Alan Bateman ; Felix Yang ; jigsaw-dev at openjdk.java.net Subject: 8078820 -> Re: RFR: 8068938: Test deploying a XML parser as a module Saw Alan's update for JDK-8078820. 8078820 is the right id for this, isn't it? :-) 8068938 was a different issue that Sundar has already resolved. Yes, 8078820 is right. By the way, I just realized that the previous webrevs didn't include org.xml.sax.helpers.XMLReaderFactory. Would you want to add that too? But module-info.java in module java.xml doesn't declare "uses org.xml.sax.helpers.XMLReaderFactory". Btw, I was always working on another JEP, will have an update for this task soon. Thanks Best, Joe On 1/27/2016 3:10 AM, Alan Bateman wrote: On 26/01/2016 17:30, huizhe wang wrote: Hi Felix, I would feel sorry for Frank since at the time we wanted all tests to be hosted in the JAXP repo. I understand the intention to consolidate repos as Alan suggested. However, if the JAXP repo is not hampering JDK development, I'd prefer an independent JAXP repo as is since it made JAXP dev much easier. That said, I have no objection to moving JAXP tests to JDK/test, that'll at least consolidate all of the tests and you may then take advantage of the JDK/test utilities for current and future test development. Alan, what would you think? We're probably going a bit off-topic here but I don't see why we persist with the jaxp repository. I think we should have moved the code to the jdk repository a long time ago. In the short term then it might be annoying to not have the revision history (hg log) but we've been through this kinda of transition already. Also in the short term then it might require you or others to do some adjustments to your IDE setup but that shouldn't be a big deal, esp. with the source code layout that we put in via the JEP 201 work. In any case, this all started with my comment about the tests being split between the jdk and jaxp repo. What would it take to get the new tests to be located with the existing jaxp tests? -Alan. From georgiy.rakov at oracle.com Mon Mar 21 13:44:31 2016 From: georgiy.rakov at oracle.com (Georgiy Rakov) Date: Mon, 21 Mar 2016 16:44:31 +0300 Subject: Package, import and type declarations are allowed now in module-info.java by spec In-Reply-To: <56E09D62.3060507@oracle.com> References: <56D07F37.1030806@oracle.com> <56D098BB.5070200@oracle.com> <56E021CE.3050801@oracle.com> <56E09D62.3060507@oracle.com> Message-ID: <56EFFABF.2000102@oracle.com> According to my understanding import or type declarations are *optionally* followed by a type declaration according to the CompilationUnit grammar rule. JLS 7.6 just conditionally allows compiler to restrict file names to be aligned with type declaration but the compile errors are produced even if the condition is not met. Thanks, Georgiy. On 10.03.2016 1:02, Alex Buckley wrote: > The JLS doesn't prevent javac from rejecting a package declaration or > an import declaration in a file called module-info.java. > > In fact, since a package declaration or import declaration must be > followed by a type declaration, and since a type declaration cannot > use a hyphen, javac is free to take the optional rule from JLS 7.6 -- > filename must align with type declaration -- and develop it further: > rejecting a package declaration or import declaration in > module-info.java because the filename cannot possibly align with any > type declaration. > > I can't speak to what a particular EA build of javac is doing with a > particular option. javac options are irrelevant to the JLS. If a > compiler accepts the Java language circa SE 9, then a module > declaration is a valid compilation unit. What's the name of the file > containing such a compilation unit? Anything the compiler likes. > > Alex > > On 3/9/2016 5:14 AM, Georgiy Rakov wrote: >> Hi Alex, >> >> if I understand correctly you mean about following assertions from >> JLS 7.6: >> >> If and only if packages are stored in a file system (?7.2 >> ), >> the host system may choose to enforce the restriction that it is a >> compile-time error if a type is not found in a file under a name >> composed of the type name plus an extension (such as |.java|or >> |.jav|) if either of the following is true: >> >> * >> >> The type is referred to by code in other compilation units of >> the package in which the type is declared. >> >> * >> >> The type is declared |public|(and therefore is potentially >> accessible from code in other packages). >> >> Literally these assertion doesn't make presented behavior corresponding >> to spec because the declared type is neither public nor being referred >> to from other sources being compiled. >> >> Nevertheless following sources doesn't compile either despite the fact >> that no types are declared there at all. >> Namely when only package is specified: >> >> mod\module-info.java: >> module mod { >> exports pkg; >> } >> >> mod\pkg\module-info.java: >> package pkg; >> >> then compiling it by following command line with javac from [2]: >> >> javac -modulesourcepath . mod\module-info.java >> mod\pkg\module-info.java >> >> causes following output: >> >> mod\pkg\module-info.java:1: error: expected 'module >> package pkg; >> ^ >> 1 error >> >> When only import statment is specified: >> >> mod\module-info.java: >> module mod { >> exports pkg; >> } >> >> mod\pkg\module-info.java: >> import java.util.List; >> >> then compiling it by following command line with javac from [2]: >> >> javac -modulesourcepath . mod\module-info.java >> mod\pkg\module-info.java >> >> causes following output: >> >> mod\pkg\module-info.java:1: error: expected 'module' >> import java.util.List; >> ^ >> 1 error >> >> Please see minimized test cases attached in tests23.zip. In order to >> reproduce, please: >> >> 1. Unzip the attached archive to some dir on Windows machined, say >> directory A; >> 2. Rename A\test2\test_bat to A\test2\test.bat and A\test3\test_bat to >> A\test3\test.bat; >> 3. Modify these two test.bat files by changing JDK_HOME variable to >> point to your jigsaw JDK 9 installation directory; >> 4. Run test.bat files in turn. >> >> BTW: javac behavior [2] currently differs depending on whether sources >> are compiled "in module" mode or not. By "module mode" I mean specifying >> modulesourcepath option. For instance without modulesourcepath option >> module declarations are not recognized as valid grammar while import >> declarations contained within module-info.java compile successfully. >> This can be seen by experimenting with test3 from the attached >> testcases. Now javac from [2] even can throw exception in "non-module" >> mode, please see https://bugs.openjdk.java.net/browse/JDK-8150733. >> >> Could you please tell if spec will specify somehow two modes of >> processing java-sources, now it [1] doesn't. >> >> [1] http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html >> [2] >> http://download.java.net/java/jigsaw/archive/106/binaries/jigsaw-jdk-9-ea+106_windows-x86_bin.zip >> >> >> Thanks, >> Georgiy. >> >> On 26.02.2016 21:26, Alex Buckley wrote: >>> On 2/26/2016 8:37 AM, Georgiy Rakov wrote: >>>> current spec [1] now contains following assertions related to grammar: >>>> >>>> A compilation unit (JLS 7.3) may contain a module declaration, in >>>> which case the filename of the compilation unit is typically >>>> |module-info.java|. >>>> >>>> CompilationUnit: >>>> [PackageDeclaration] {ImportDeclaration} {TypeDeclaration} >>>> ModuleDeclaration >>>> >>>> These assertions allows to specify any of import, package or type >>>> declarations in any compilation unit, for instance module-info.java is >>>> allowed to contain any of the mentioned declarations. However >>>> currently >>>> javac in the latest jigsaw build [2] reports an error on such cases >>>> provided they are compiled in module mode. For example if we have >>>> following directory structure: >>>> >>>> mod\module-info.java: >>>> module mod { >>>> exports pkg; >>>> } >>>> >>>> mod\pkg\module-info.java: >>>> package pkg; >>>> >>>> class C { >>>> } >>>> >>>> then compiling it by following command line with javac from [2]: >>>> >>>> javac -modulesourcepath . mod\module-info.java >>>> mod\pkg\module-info.java >>>> >>>> causes following output: >>>> >>>> mod\pkg\module-info.java:1: error: expected 'module' >>>> package pkg; >>>> ^ >>>> 1 error >>> >>> javac is merely choosing to implement the rule at the end of JLS 7.6 >>> that a type declaration (optionally preceded by package/import >>> declarations) must be provided in a suitably named file. >>> >>> Perhaps I should say "a variant of the rule" because 7.6 as written >>> concerns a public type and your example has a package-access type. >>> Still, bottom line, javac is free to require that a compilation unit >>> which starts with a package declaration _must not_ be in a file called >>> foo-bar.java -- the hyphen indicates a name that can't possibly align >>> with the type declared in the compilation unit. >>> >>> The error message for mod\pkg\module-info.java could be a bit more >>> helpful, but that's a quality-of-implementation detail. >>> >>> Conversely, a compilation unit that contains a module declaration >>> _may_ be in a file called module-info.java, or in a file called >>> foo-bar.java, or in a file called mod_decl.JAV. The "typically" in [1] >>> is meant to indicate that the sub-clause on filename is non-normative. >>> This is akin to how a compilation unit that contains a package-access >>> type declaration for class C _may_ be in a file D.java. >>> >>> Alex >> From huizhe.wang at oracle.com Mon Mar 21 16:49:37 2016 From: huizhe.wang at oracle.com (huizhe wang) Date: Mon, 21 Mar 2016 09:49:37 -0700 Subject: 8078820 -> Re: RFR: 8068938: Test deploying a XML parser as a module In-Reply-To: <066501d18356$3b394490$b1abcdb0$@oracle.com> References: <01e401d14c1c$916b5220$b441f660$@oracle.com> <5694B4F3.1010002@oracle.com> <94E1094C-7ADB-4596-A9F8-4B64E97565E2@oracle.com> <56A7AD3A.5000601@oracle.com> <56A8A593.80909@oracle.com> <56EDDD6D.8050605@oracle.com> <066501d18356$3b394490$b1abcdb0$@oracle.com> Message-ID: <56F02621.4020203@oracle.com> On 3/21/2016 2:44 AM, Frank Yuan wrote: > > By the way, I just realized that the previous webrevs didn't include > org.xml.sax.helpers.XMLReaderFactory. Would you want to add that too? > > But module-info.java in module java.xml doesn't declare "uses > org.xml.sax.helpers.XMLReaderFactory". Btw, I was always working on > another JEP, will have an update for this task soon. Thanks > Then the module-info.java needs to be fixed. XMLReaderFactory is supported along with SAX. Thanks, Joe From Alan.Bateman at oracle.com Mon Mar 21 16:56:10 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 21 Mar 2016 16:56:10 +0000 Subject: 8078820 -> Re: RFR: 8068938: Test deploying a XML parser as a module In-Reply-To: <56F02621.4020203@oracle.com> References: <01e401d14c1c$916b5220$b441f660$@oracle.com> <5694B4F3.1010002@oracle.com> <94E1094C-7ADB-4596-A9F8-4B64E97565E2@oracle.com> <56A7AD3A.5000601@oracle.com> <56A8A593.80909@oracle.com> <56EDDD6D.8050605@oracle.com> <066501d18356$3b394490$b1abcdb0$@oracle.com> <56F02621.4020203@oracle.com> Message-ID: <56F027AA.5010006@oracle.com> On 21/03/2016 16:49, huizhe wang wrote: > > Then the module-info.java needs to be fixed. XMLReaderFactory is > supported along with SAX. Are you sure this API is using ServiceLoader? I have a vague memory that we'd need the to update the endorsed SAX API for this. -Alan From huizhe.wang at oracle.com Mon Mar 21 17:02:43 2016 From: huizhe.wang at oracle.com (huizhe wang) Date: Mon, 21 Mar 2016 10:02:43 -0700 Subject: 8078820 -> Re: RFR: 8068938: Test deploying a XML parser as a module In-Reply-To: <56F027AA.5010006@oracle.com> References: <01e401d14c1c$916b5220$b441f660$@oracle.com> <5694B4F3.1010002@oracle.com> <94E1094C-7ADB-4596-A9F8-4B64E97565E2@oracle.com> <56A7AD3A.5000601@oracle.com> <56A8A593.80909@oracle.com> <56EDDD6D.8050605@oracle.com> <066501d18356$3b394490$b1abcdb0$@oracle.com> <56F02621.4020203@oracle.com> <56F027AA.5010006@oracle.com> Message-ID: <56F02933.5050008@oracle.com> On 3/21/2016 9:56 AM, Alan Bateman wrote: > > > On 21/03/2016 16:49, huizhe wang wrote: >> >> Then the module-info.java needs to be fixed. XMLReaderFactory is >> supported along with SAX. > Are you sure this API is using ServiceLoader? I have a vague memory > that we'd need the to update the endorsed SAX API for this. Let me take a look once I've done with my current work on hand. -Joe > > -Alan From daniel.fuchs at oracle.com Mon Mar 21 17:12:36 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 21 Mar 2016 18:12:36 +0100 Subject: 8078820 -> Re: RFR: 8068938: Test deploying a XML parser as a module In-Reply-To: <56F02933.5050008@oracle.com> References: <01e401d14c1c$916b5220$b441f660$@oracle.com> <5694B4F3.1010002@oracle.com> <94E1094C-7ADB-4596-A9F8-4B64E97565E2@oracle.com> <56A7AD3A.5000601@oracle.com> <56A8A593.80909@oracle.com> <56EDDD6D.8050605@oracle.com> <066501d18356$3b394490$b1abcdb0$@oracle.com> <56F02621.4020203@oracle.com> <56F027AA.5010006@oracle.com> <56F02933.5050008@oracle.com> Message-ID: <56F02B84.4080404@oracle.com> On 21/03/16 18:02, huizhe wang wrote: > > On 3/21/2016 9:56 AM, Alan Bateman wrote: >> >> >> On 21/03/2016 16:49, huizhe wang wrote: >>> >>> Then the module-info.java needs to be fixed. XMLReaderFactory is >>> supported along with SAX. >> Are you sure this API is using ServiceLoader? I have a vague memory >> that we'd need the to update the endorsed SAX API for this. > > Let me take a look once I've done with my current work on hand. FWIW this one doesn't use ServiceLoader. It looks for a class name under META-INF/services/org.xml.sax.driver, which means that it doesn't adhere to ServiceLoader specification. best, -- daniel > > -Joe > >> >> -Alan > From huizhe.wang at oracle.com Mon Mar 21 17:30:06 2016 From: huizhe.wang at oracle.com (huizhe wang) Date: Mon, 21 Mar 2016 10:30:06 -0700 Subject: 8078820 -> Re: RFR: 8068938: Test deploying a XML parser as a module In-Reply-To: <56EFBA38.2000201@oracle.com> References: <01e401d14c1c$916b5220$b441f660$@oracle.com> <5694B4F3.1010002@oracle.com> <94E1094C-7ADB-4596-A9F8-4B64E97565E2@oracle.com> <56A7AD3A.5000601@oracle.com> <56A8A593.80909@oracle.com> <56EDDD6D.8050605@oracle.com> <56EFBA38.2000201@oracle.com> Message-ID: <56F02F9E.3020302@oracle.com> On 3/21/2016 2:09 AM, Alan Bateman wrote: > > On 19/03/2016 23:14, huizhe wang wrote: >> Saw Alan's update for JDK-8078820. 8078820 is the right id for this, >> isn't it? :-) 8068938 was a different issue that Sundar has already >> resolved. >> >> By the way, I just realized that the previous webrevs didn't include >> org.xml.sax.helpers.XMLReaderFactory. Would you want to add that too? > Frank out the issue number is one of the previous mails, no big deal. > > Are you okay to work with him and figure out how to get these tests in > jdk9/dev? Ideally all XML parsing tests would be in the same repo but > that isn't something that we want to get tangled up in here. I think, > as I've mentioned in this thread, is that we should get rid of the > jaxp repo completely and just move the code and tests to the jdk repo. > I don't thin this would be a huge effort. As Peter mentioned in the other thread (8068938...), references to jaxp changes in JIRA would point to wrong links, that would be disruptive. Plus, we (people who have jaxp workplace configured using the JAXP standalone structure) would have to spend time re-configure yet again for another repo change/move. Given our busy schedule, it's just unnecessary, IMHO. At issue is test consolidation, we already have all jaxp test in the jaxp repo. For this particular test, I don't mind if we have to put it in the jdk repo in some kind of "module" category. But if you'd like it in the jaxp repo, Frank might need to investigate whether he wants find an alternative to the test libs he used or whether it's feasible to make a copy to the jaxp repo. -Joe > > -Alan. From mandy.chung at oracle.com Mon Mar 21 17:32:40 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 21 Mar 2016 10:32:40 -0700 Subject: Review Request 8152197: Single place to specify module-specific information for images build Message-ID: <06AF330D-151A-4063-9C61-0AD0A417EB04@oracle.com> Erik, This cleans up several makefiles and now have one single file (make/common/Modules.gmk) to specify the module-specific information for the build: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8152197/webrev.00/index.html Mandy From nipa at codefx.org Mon Mar 21 17:39:49 2016 From: nipa at codefx.org (Nicolai Parlog) Date: Mon, 21 Mar 2016 18:39:49 +0100 Subject: libraries that split packages Message-ID: <56F031E5.4010308@codefx.org> Hi! Are there any numbers on how severe the split package situation is, i.e. how many libraries split packages with the JDK or among themselves? I am also interested in concrete examples. I only know of xml-apis[1] and FindBugs-JSR305[2] but I am sure many more exist. Can anybody help me out? so long ... Nicolai [1] http://search.maven.org/#artifactdetails|xml-apis|xml-apis|2.0.2|jar [2] http://mvnrepository.com/artifact/com.google.code.findbugs/jsr305 -- PGP Key: http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509 Web: http://codefx.org a blog about software development http://do-foss.de Free and Open Source Software for the City of Dortmund Twitter: https://twitter.com/nipafx From huizhe.wang at oracle.com Mon Mar 21 18:05:19 2016 From: huizhe.wang at oracle.com (huizhe wang) Date: Mon, 21 Mar 2016 11:05:19 -0700 Subject: 8078820 -> Re: RFR: 8068938: Test deploying a XML parser as a module In-Reply-To: <56F02B84.4080404@oracle.com> References: <01e401d14c1c$916b5220$b441f660$@oracle.com> <5694B4F3.1010002@oracle.com> <94E1094C-7ADB-4596-A9F8-4B64E97565E2@oracle.com> <56A7AD3A.5000601@oracle.com> <56A8A593.80909@oracle.com> <56EDDD6D.8050605@oracle.com> <066501d18356$3b394490$b1abcdb0$@oracle.com> <56F02621.4020203@oracle.com> <56F027AA.5010006@oracle.com> <56F02933.5050008@oracle.com> <56F02B84.4080404@oracle.com> Message-ID: <56F037DF.2010406@oracle.com> On 3/21/2016 10:12 AM, Daniel Fuchs wrote: > On 21/03/16 18:02, huizhe wang wrote: >> >> On 3/21/2016 9:56 AM, Alan Bateman wrote: >>> >>> >>> On 21/03/2016 16:49, huizhe wang wrote: >>>> >>>> Then the module-info.java needs to be fixed. XMLReaderFactory is >>>> supported along with SAX. >>> Are you sure this API is using ServiceLoader? I have a vague memory >>> that we'd need the to update the endorsed SAX API for this. >> >> Let me take a look once I've done with my current work on hand. > > FWIW this one doesn't use ServiceLoader. > It looks for a class name under META-INF/services/org.xml.sax.driver, > which means that it doesn't adhere to ServiceLoader specification. We need to look into modifying it to use ServiceLoader, which is what Alan was saying that we needed to update the endorsed SAX API. SAX hasn't been active maintained. I'll try to contact him. Best, Joe > > best, > > -- daniel > >> >> -Joe >> >>> >>> -Alan >> > From alex.buckley at oracle.com Mon Mar 21 18:10:26 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 21 Mar 2016 11:10:26 -0700 Subject: Package, import and type declarations are allowed now in module-info.java by spec In-Reply-To: <56EFFABF.2000102@oracle.com> References: <56D07F37.1030806@oracle.com> <56D098BB.5070200@oracle.com> <56E021CE.3050801@oracle.com> <56E09D62.3060507@oracle.com> <56EFFABF.2000102@oracle.com> Message-ID: <56F03912.1020607@oracle.com> Imagine the 7.6 text about the host system wasn't there. Now the JLS has no rules about the name of the file from which a CompilationUnit production is parsed. A compiler is therefore allowed to reject a file named module-info.java whenever it wishes. Now imagine the 7.6 text is put back. Since it allows the host system to choose when to follow it, it has no bearing on the previous paragraph. Georgiy, I don't think it's productive to continue this thread further. Alex On 3/21/2016 6:44 AM, Georgiy Rakov wrote: > According to my understanding import or type declarations are > *optionally* followed by a type declaration according to the > CompilationUnit grammar rule. JLS 7.6 just conditionally allows compiler > to restrict file names to be aligned with type declaration but the > compile errors are produced even if the condition is not met. > > Thanks, > Georgiy. > > On 10.03.2016 1:02, Alex Buckley wrote: >> The JLS doesn't prevent javac from rejecting a package declaration or >> an import declaration in a file called module-info.java. >> >> In fact, since a package declaration or import declaration must be >> followed by a type declaration, and since a type declaration cannot >> use a hyphen, javac is free to take the optional rule from JLS 7.6 -- >> filename must align with type declaration -- and develop it further: >> rejecting a package declaration or import declaration in >> module-info.java because the filename cannot possibly align with any >> type declaration. >> >> I can't speak to what a particular EA build of javac is doing with a >> particular option. javac options are irrelevant to the JLS. If a >> compiler accepts the Java language circa SE 9, then a module >> declaration is a valid compilation unit. What's the name of the file >> containing such a compilation unit? Anything the compiler likes. >> >> Alex >> >> On 3/9/2016 5:14 AM, Georgiy Rakov wrote: >>> Hi Alex, >>> >>> if I understand correctly you mean about following assertions from >>> JLS 7.6: >>> >>> If and only if packages are stored in a file system (?7.2 >>> ), >>> the host system may choose to enforce the restriction that it is a >>> compile-time error if a type is not found in a file under a name >>> composed of the type name plus an extension (such as |.java|or >>> |.jav|) if either of the following is true: >>> >>> * >>> >>> The type is referred to by code in other compilation units of >>> the package in which the type is declared. >>> >>> * >>> >>> The type is declared |public|(and therefore is potentially >>> accessible from code in other packages). >>> >>> Literally these assertion doesn't make presented behavior corresponding >>> to spec because the declared type is neither public nor being referred >>> to from other sources being compiled. >>> >>> Nevertheless following sources doesn't compile either despite the fact >>> that no types are declared there at all. >>> Namely when only package is specified: >>> >>> mod\module-info.java: >>> module mod { >>> exports pkg; >>> } >>> >>> mod\pkg\module-info.java: >>> package pkg; >>> >>> then compiling it by following command line with javac from [2]: >>> >>> javac -modulesourcepath . mod\module-info.java >>> mod\pkg\module-info.java >>> >>> causes following output: >>> >>> mod\pkg\module-info.java:1: error: expected 'module >>> package pkg; >>> ^ >>> 1 error >>> >>> When only import statment is specified: >>> >>> mod\module-info.java: >>> module mod { >>> exports pkg; >>> } >>> >>> mod\pkg\module-info.java: >>> import java.util.List; >>> >>> then compiling it by following command line with javac from [2]: >>> >>> javac -modulesourcepath . mod\module-info.java >>> mod\pkg\module-info.java >>> >>> causes following output: >>> >>> mod\pkg\module-info.java:1: error: expected 'module' >>> import java.util.List; >>> ^ >>> 1 error >>> >>> Please see minimized test cases attached in tests23.zip. In order to >>> reproduce, please: >>> >>> 1. Unzip the attached archive to some dir on Windows machined, say >>> directory A; >>> 2. Rename A\test2\test_bat to A\test2\test.bat and A\test3\test_bat to >>> A\test3\test.bat; >>> 3. Modify these two test.bat files by changing JDK_HOME variable to >>> point to your jigsaw JDK 9 installation directory; >>> 4. Run test.bat files in turn. >>> >>> BTW: javac behavior [2] currently differs depending on whether sources >>> are compiled "in module" mode or not. By "module mode" I mean specifying >>> modulesourcepath option. For instance without modulesourcepath option >>> module declarations are not recognized as valid grammar while import >>> declarations contained within module-info.java compile successfully. >>> This can be seen by experimenting with test3 from the attached >>> testcases. Now javac from [2] even can throw exception in "non-module" >>> mode, please see https://bugs.openjdk.java.net/browse/JDK-8150733. >>> >>> Could you please tell if spec will specify somehow two modes of >>> processing java-sources, now it [1] doesn't. >>> >>> [1] http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html >>> [2] >>> http://download.java.net/java/jigsaw/archive/106/binaries/jigsaw-jdk-9-ea+106_windows-x86_bin.zip >>> >>> >>> Thanks, >>> Georgiy. >>> >>> On 26.02.2016 21:26, Alex Buckley wrote: >>>> On 2/26/2016 8:37 AM, Georgiy Rakov wrote: >>>>> current spec [1] now contains following assertions related to grammar: >>>>> >>>>> A compilation unit (JLS 7.3) may contain a module declaration, in >>>>> which case the filename of the compilation unit is typically >>>>> |module-info.java|. >>>>> >>>>> CompilationUnit: >>>>> [PackageDeclaration] {ImportDeclaration} {TypeDeclaration} >>>>> ModuleDeclaration >>>>> >>>>> These assertions allows to specify any of import, package or type >>>>> declarations in any compilation unit, for instance module-info.java is >>>>> allowed to contain any of the mentioned declarations. However >>>>> currently >>>>> javac in the latest jigsaw build [2] reports an error on such cases >>>>> provided they are compiled in module mode. For example if we have >>>>> following directory structure: >>>>> >>>>> mod\module-info.java: >>>>> module mod { >>>>> exports pkg; >>>>> } >>>>> >>>>> mod\pkg\module-info.java: >>>>> package pkg; >>>>> >>>>> class C { >>>>> } >>>>> >>>>> then compiling it by following command line with javac from [2]: >>>>> >>>>> javac -modulesourcepath . mod\module-info.java >>>>> mod\pkg\module-info.java >>>>> >>>>> causes following output: >>>>> >>>>> mod\pkg\module-info.java:1: error: expected 'module' >>>>> package pkg; >>>>> ^ >>>>> 1 error >>>> >>>> javac is merely choosing to implement the rule at the end of JLS 7.6 >>>> that a type declaration (optionally preceded by package/import >>>> declarations) must be provided in a suitably named file. >>>> >>>> Perhaps I should say "a variant of the rule" because 7.6 as written >>>> concerns a public type and your example has a package-access type. >>>> Still, bottom line, javac is free to require that a compilation unit >>>> which starts with a package declaration _must not_ be in a file called >>>> foo-bar.java -- the hyphen indicates a name that can't possibly align >>>> with the type declared in the compilation unit. >>>> >>>> The error message for mod\pkg\module-info.java could be a bit more >>>> helpful, but that's a quality-of-implementation detail. >>>> >>>> Conversely, a compilation unit that contains a module declaration >>>> _may_ be in a file called module-info.java, or in a file called >>>> foo-bar.java, or in a file called mod_decl.JAV. The "typically" in [1] >>>> is meant to indicate that the sub-clause on filename is non-normative. >>>> This is akin to how a compilation unit that contains a package-access >>>> type declaration for class C _may_ be in a file D.java. >>>> >>>> Alex >>> > From Alan.Bateman at oracle.com Mon Mar 21 18:31:17 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 21 Mar 2016 18:31:17 +0000 Subject: 8078820 -> Re: RFR: 8068938: Test deploying a XML parser as a module In-Reply-To: <56F02F9E.3020302@oracle.com> References: <01e401d14c1c$916b5220$b441f660$@oracle.com> <5694B4F3.1010002@oracle.com> <94E1094C-7ADB-4596-A9F8-4B64E97565E2@oracle.com> <56A7AD3A.5000601@oracle.com> <56A8A593.80909@oracle.com> <56EDDD6D.8050605@oracle.com> <56EFBA38.2000201@oracle.com> <56F02F9E.3020302@oracle.com> Message-ID: <56F03DF5.8050705@oracle.com> On 21/03/2016 17:30, huizhe wang wrote: > > As Peter mentioned in the other thread (8068938...), references to > jaxp changes in JIRA would point to wrong links, that would be > disruptive. Plus, we (people who have jaxp workplace configured using > the JAXP standalone structure) would have to spend time re-configure > yet again for another repo change/move. Given our busy schedule, it's > just unnecessary, IMHO. Sure, some mild disruption but I don't see it as a major issue. > > At issue is test consolidation, we already have all jaxp test in the > jaxp repo. For this particular test, I don't mind if we have to put it > in the jdk repo in some kind of "module" category. But if you'd like > it in the jaxp repo, Frank might need to investigate whether he wants > find an alternative to the test libs he used or whether it's feasible > to make a copy to the jaxp repo. I think it would be best if it co-located with the other unit tests. -Alan From Alan.Bateman at oracle.com Mon Mar 21 18:57:22 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 21 Mar 2016 18:57:22 +0000 Subject: Review Request 8152197: Single place to specify module-specific information for images build In-Reply-To: <06AF330D-151A-4063-9C61-0AD0A417EB04@oracle.com> References: <06AF330D-151A-4063-9C61-0AD0A417EB04@oracle.com> Message-ID: <56F04412.3060205@oracle.com> On 21/03/2016 17:32, Mandy Chung wrote: > Erik, > > This cleans up several makefiles and now have one single file (make/common/Modules.gmk) to specify the module-specific information for the build: > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8152197/webrev.00/index.html > > This looks a good clean-up. One thing that isn't clear is how to get tool modules into the JRE. I suspect that JRE_MODULES needs to be $(BOOT_MODULES) + $(PLATFORM_MODULES) + jdk.policytool + jdk.scripting.nashorn.shell to be consistent with JRE 8 builds. -Alan From jeffhain at rocketmail.com Mon Mar 21 23:50:44 2016 From: jeffhain at rocketmail.com (Jeff Hain) Date: Mon, 21 Mar 2016 23:50:44 +0000 (UTC) Subject: libraries that split packages References: <1687245725.4423086.1458604244176.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <1687245725.4423086.1458604244176.JavaMail.yahoo@mail.yahoo.com> Hi. >I am also interested in concrete examples. >Can anybody help me out? Just pushed a sample for computing split packages, using Jadecy: https://github.com/jeffhain/jadecy/blob/master/src/samples/java/net/jadecy/SplitPackageSample.java Replacing JAVA_HOME value with the path of a directory containing all the jars you like, it would show you all the split packages, and classes causing them. -Jeff From mandy.chung at oracle.com Tue Mar 22 00:36:33 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 21 Mar 2016 17:36:33 -0700 Subject: Review Request 8152197: Single place to specify module-specific information for images build In-Reply-To: <56F04412.3060205@oracle.com> References: <06AF330D-151A-4063-9C61-0AD0A417EB04@oracle.com> <56F04412.3060205@oracle.com> Message-ID: <659A3873-F979-4458-A163-A9CDF21CCF10@oracle.com> > On Mar 21, 2016, at 11:57 AM, Alan Bateman wrote: > > On 21/03/2016 17:32, Mandy Chung wrote: >> Erik, >> >> This cleans up several makefiles and now have one single file (make/common/Modules.gmk) to specify the module-specific information for the build: >> >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8152197/webrev.00/index.html >> >> > This looks a good clean-up. > > One thing that isn't clear is how to get tool modules into the JRE. I suspect that JRE_MODULES needs to be $(BOOT_MODULES) + $(PLATFORM_MODULES) + jdk.policytool + jdk.scripting.nashorn.shell to be consistent with JRE 8 builds. Good catch. I compared the modules listed in make/Images.gmk before the change with make/common/Modules.gmk and found some existing issues - jdk.policytool has not been linked in JRE and I can?t quite tell why jdk.jvmstat and jdk.jvmstat.rmi are linked in JRE. I believe we only need the following tools be included in JRE to be consistent with JRE 8 builds: JRE_TOOL_MODULES += \ jdk.pack200 \ jdk.policytool \ jdk.scripting.nashorn.shell \ Updated webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8152197/webrev.01/index.html Mandy From mandy.chung at oracle.com Tue Mar 22 00:42:43 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 21 Mar 2016 17:42:43 -0700 Subject: Review Request 8152197: Single place to specify module-specific information for images build In-Reply-To: <659A3873-F979-4458-A163-A9CDF21CCF10@oracle.com> References: <06AF330D-151A-4063-9C61-0AD0A417EB04@oracle.com> <56F04412.3060205@oracle.com> <659A3873-F979-4458-A163-A9CDF21CCF10@oracle.com> Message-ID: > On Mar 21, 2016, at 5:36 PM, Mandy Chung wrote: > >> >> On Mar 21, 2016, at 11:57 AM, Alan Bateman wrote: >> >> On 21/03/2016 17:32, Mandy Chung wrote: >>> Erik, >>> >>> This cleans up several makefiles and now have one single file (make/common/Modules.gmk) to specify the module-specific information for the build: >>> >>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8152197/webrev.00/index.html >>> >>> >> This looks a good clean-up. >> >> One thing that isn't clear is how to get tool modules into the JRE. I suspect that JRE_MODULES needs to be $(BOOT_MODULES) + $(PLATFORM_MODULES) + jdk.policytool + jdk.scripting.nashorn.shell to be consistent with JRE 8 builds. > > > Good catch. I compared the modules listed in make/Images.gmk before the change with make/common/Modules.gmk and found some existing issues - jdk.policytool has not been linked in JRE and I can?t quite tell why jdk.jvmstat and jdk.jvmstat.rmi are linked in JRE. I believe we only need the following tools be included in JRE to be consistent with JRE 8 builds: > > JRE_TOOL_MODULES += \ > jdk.pack200 \ > jdk.policytool \ > jdk.scripting.nashorn.shell \ > > Updated webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8152197/webrev.01/index.html In fact, JDK-8071338 has moved policytool from JRE to JDK in JDK 9. webrev.01 updated in place. Mandy From Alan.Bateman at oracle.com Tue Mar 22 07:34:27 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 22 Mar 2016 07:34:27 +0000 Subject: Review Request 8152197: Single place to specify module-specific information for images build In-Reply-To: References: <06AF330D-151A-4063-9C61-0AD0A417EB04@oracle.com> <56F04412.3060205@oracle.com> <659A3873-F979-4458-A163-A9CDF21CCF10@oracle.com> Message-ID: <56F0F583.5070702@oracle.com> On 22/03/2016 00:42, Mandy Chung wrote: >> On Mar 21, 2016, at 5:36 PM, Mandy Chung wrote: >> >> Good catch. I compared the modules listed in make/Images.gmk before the change with make/common/Modules.gmk and found some existing issues - jdk.policytool has not been linked in JRE and I can?t quite tell why jdk.jvmstat and jdk.jvmstat.rmi are linked in JRE. I believe we only need the following tools be included in JRE to be consistent with JRE 8 builds: >> >> JRE_TOOL_MODULES += \ >> jdk.pack200 \ >> jdk.policytool \ >> jdk.scripting.nashorn.shell \ >> >> Updated webrev: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8152197/webrev.01/index.html > > In fact, JDK-8071338 has moved policytool from JRE to JDK in JDK 9. webrev.01 updated in place. > I remember that discussion with Max. The webrev looks good, I assume you'll push this to jdk9/dev once the jdk-9+111 has been pulled into that forest. -Alan From erik.joelsson at oracle.com Tue Mar 22 08:45:50 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 22 Mar 2016 09:45:50 +0100 Subject: Review Request 8152197: Single place to specify module-specific information for images build In-Reply-To: References: <06AF330D-151A-4063-9C61-0AD0A417EB04@oracle.com> <56F04412.3060205@oracle.com> <659A3873-F979-4458-A163-A9CDF21CCF10@oracle.com> Message-ID: <56F1063E.6050004@oracle.com> Hello, I like the consolidation of all module information. I don't like that every time Modules.gmk is included, it calculates the IMPORTED_MODULES. It also looks like that can't work in the current patch since the call is before the definition of FindImportedModules. I can see if I can modify this to have the calculation done lazily or at least only on demand. /Erik On 2016-03-22 01:42, Mandy Chung wrote: >> On Mar 21, 2016, at 5:36 PM, Mandy Chung wrote: >> >>> On Mar 21, 2016, at 11:57 AM, Alan Bateman wrote: >>> >>> On 21/03/2016 17:32, Mandy Chung wrote: >>>> Erik, >>>> >>>> This cleans up several makefiles and now have one single file (make/common/Modules.gmk) to specify the module-specific information for the build: >>>> >>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8152197/webrev.00/index.html >>>> >>>> >>> This looks a good clean-up. >>> >>> One thing that isn't clear is how to get tool modules into the JRE. I suspect that JRE_MODULES needs to be $(BOOT_MODULES) + $(PLATFORM_MODULES) + jdk.policytool + jdk.scripting.nashorn.shell to be consistent with JRE 8 builds. >> >> Good catch. I compared the modules listed in make/Images.gmk before the change with make/common/Modules.gmk and found some existing issues - jdk.policytool has not been linked in JRE and I can?t quite tell why jdk.jvmstat and jdk.jvmstat.rmi are linked in JRE. I believe we only need the following tools be included in JRE to be consistent with JRE 8 builds: >> >> JRE_TOOL_MODULES += \ >> jdk.pack200 \ >> jdk.policytool \ >> jdk.scripting.nashorn.shell \ >> >> Updated webrev: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8152197/webrev.01/index.html > > In fact, JDK-8071338 has moved policytool from JRE to JDK in JDK 9. webrev.01 updated in place. > > Mandy > From Alan.Bateman at oracle.com Tue Mar 22 08:50:27 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 22 Mar 2016 08:50:27 +0000 Subject: libraries that split packages In-Reply-To: <1687245725.4423086.1458604244176.JavaMail.yahoo@mail.yahoo.com> References: <1687245725.4423086.1458604244176.JavaMail.yahoo.ref@mail.yahoo.com> <1687245725.4423086.1458604244176.JavaMail.yahoo@mail.yahoo.com> Message-ID: <56F10753.7000101@oracle.com> On 21/03/2016 23:50, Jeff Hain wrote: > Hi. > > >> I am also interested in concrete examples. >> Can anybody help me out? > > Just pushed a sample for computing split packages, > using Jadecy: > https://github.com/jeffhain/jadecy/blob/master/src/samples/java/net/jadecy/SplitPackageSample.java > > > Replacing JAVA_HOME value with the path of a directory containing > all the jars you like, it would show you all the split packages, > and classes causing them. > > For bonus points then check for overlap with the packages in modules in the runtime image. That would help with the cases that Nicolai mentions in his mail. -Alan From peter.levart at gmail.com Tue Mar 22 12:06:05 2016 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 22 Mar 2016 13:06:05 +0100 Subject: modulepath and classpath mixture In-Reply-To: References: <56CC57A1.2050109@oracle.com> <56CD6F36.8020503@oracle.com> Message-ID: <56F1352D.60506@gmail.com> On 02/24/2016 08:30 PM, Robert Scholte wrote: > On Wed, 24 Feb 2016 09:52:06 +0100, Alan Bateman > wrote: > >> >> On 23/02/2016 21:10, Robert Scholte wrote: >>> : >>> >>> If I understand this correctly I need to know the module name. >> Has there been any discussion around having the module name in the >> POM? From the mails then it sounds like the project is mostly >> "unaware" that it is creating a module. The other thing that comes to >> mind is the source layout and whether it will get to the point where >> the module name is in the file path. I'm mostly thinking of multi >> module projects where one might have the source to multiple modules >> in the same source tree. >> >> -Alan > > The name of the module with not end up in pom-4.0.0, it'll simply > break the xsd and would have effect on all other tools/IDEs/etc > depending on the pom. > The only place where one might specify the module name is in the > configuration of the maven-compiler-plugin. > In Brussels we talked about multimodules, but it makes more sense that > 1 Maven project contains zero or one module-info[1]. > And yes, I think a MavenProject will probably be unaware of its own > module name. It knows its source roots and outputdirectories (for both > main/java and test/java) and the packaged jar. Based on the > availability of the module-info in one of these locations it knows how > to construct the commandline arguments. > At least, this is what I'm hoping to achieve. > > thanks, > Robert > > [1] https://twitter.com/rfscholte/status/694599731515899904 Hi Robert, Why do you want to support tests that "inject" classes into packages of main artifact? Is this mainly because that's how it is done today? With modules I would rather create tests in its own module and use qualified exports from otherwise concealed packages of main module to give tests access to types that are not accessible otherwise. This however means that main module would have to use public qualifier on types and members to allow test module to access them. In effect substituting the package-private-nes with partly concealed packages to enable testability. Perhaps jigsaw should realize that testabililty is an important aspect to support. Forcing tools to compile a suitable set of javac and java options to compile or inject new classes into an existing module and augment it's dependencies is not very pleasant. Maybe this could be supported with a little twist to the accessibility rules. Let me borrow a rough idea that already circulated this list a while ago and modify it to fit on the top of jigsaw accessibility rules. Suppose that a qualified export of a package to the specific module(s) could be augmented with say a "private" keyword: module my.mod { requires ...; export private my.mod.internal to my.mod.test; } module my.mod.test { requires my.mod; requires junit; } ...which would not only export the package to the specific module(s), but also enable access to package-private types/members of that package from the target module(s) as though those types/members were public for them and for them only. It would only be possible to specify "private" keyword with qualified exports - not with unqualified. Would that be against any jigsaw goals? Regards, Peter From jeffhain at rocketmail.com Tue Mar 22 20:00:21 2016 From: jeffhain at rocketmail.com (Jeff Hain) Date: Tue, 22 Mar 2016 20:00:21 +0000 (UTC) Subject: libraries that split packages References: <1698792429.5362821.1458676821406.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <1698792429.5362821.1458676821406.JavaMail.yahoo@mail.yahoo.com> >For bonus points then check for overlap with the packages in modules in >the runtime image. That would help with the cases that Nicolai mentions >in his mail. Working on modules extracted from lib/modules (just feeding Jadecy with modules directories instead of jars), with version 9-ea+110-2016-03-17-022235.javare.4664.nc, I found just that: ### jdk.net: ?? jdk.net: ????? jdk.net.module-info ?? java.base: ????? jdk.net.ExtendedSocketOptions ????? jdk.net.NetworkPermission ????? jdk.net.SocketFlow ????? jdk.net.Sockets ### If adding jsr305 jar (3.0.1) in a pseudo-module directory, I got that more: ### javax.annotation: ?? java.annotations.common: ????? javax.annotation.Generated ????? javax.annotation.PostConstruct ????? javax.annotation.PreDestroy ????? javax.annotation.Resource ????? javax.annotation.Resources ?? jsr305: ????? javax.annotation.CheckForNull ????? javax.annotation.CheckForSigned ????? javax.annotation.CheckReturnValue ????? javax.annotation.Detainted ????? javax.annotation.MatchesPattern ????? javax.annotation.Nonnegative ????? javax.annotation.Nonnull ????? javax.annotation.Nullable ????? javax.annotation.OverridingMethodsMustInvokeSuper ????? javax.annotation.ParametersAreNonnullByDefault ????? javax.annotation.ParametersAreNullableByDefault ????? javax.annotation.PropertyKey ????? javax.annotation.RegEx ????? javax.annotation.Signed ????? javax.annotation.Syntax ????? javax.annotation.Tainted ????? javax.annotation.Untainted ????? javax.annotation.WillClose ????? javax.annotation.WillCloseWhenClosed ????? javax.annotation.WillNotClose ### and with xml-apis (2.0.2), many more, so not showing classes: ### javax.xml.parsers: ?? java.xml: ?? xml_apis: javax.xml.transform: ?? java.xml: ?? xml_apis: javax.xml.transform.dom: ?? java.xml: ?? xml_apis: javax.xml.transform.sax: ?? java.xml: ?? xml_apis: javax.xml.transform.stream: ?? java.xml: ?? xml_apis: org.w3c.dom: ?? java.xml: ?? xml_apis: org.w3c.dom.css: ?? xml_apis: ?? jdk.xml.dom: org.w3c.dom.events: ?? java.xml: ?? xml_apis: org.w3c.dom.html: ?? xml_apis: ?? jdk.xml.dom: org.w3c.dom.ranges: ?? java.xml: ?? xml_apis: org.w3c.dom.stylesheets: ?? xml_apis: ?? jdk.xml.dom: org.w3c.dom.traversal: ?? java.xml: ?? xml_apis: org.w3c.dom.views: ?? java.xml: ?? xml_apis: org.xml.sax: ?? java.xml: ?? xml_apis: org.xml.sax.ext: ?? java.xml: ?? xml_apis: org.xml.sax.helpers: ?? java.xml: ?? xml_apis: ### -Jeff From ropalka at redhat.com Tue Mar 22 20:27:35 2016 From: ropalka at redhat.com (Richard Opalka) Date: Tue, 22 Mar 2016 21:27:35 +0100 Subject: libraries that split packages In-Reply-To: <56F031E5.4010308@codefx.org> References: <56F031E5.4010308@codefx.org> Message-ID: <56F1AAB7.1030900@redhat.com> Hi Nicolai, some examples can be found here: https://issues.jboss.org/browse/WFLY-6375 Any "Service Provider" based jar is a potential problem. Rio On 03/21/2016 06:39 PM, Nicolai Parlog wrote: > Hi! > > Are there any numbers on how severe the split package situation is, i.e. > how many libraries split packages with the JDK or among themselves? > > I am also interested in concrete examples. I only know of xml-apis[1] > and FindBugs-JSR305[2] but I am sure many more exist. > > Can anybody help me out? > > so long ... Nicolai > > > [1] http://search.maven.org/#artifactdetails|xml-apis|xml-apis|2.0.2|jar > [2] http://mvnrepository.com/artifact/com.google.code.findbugs/jsr305 From pbenedict at apache.org Tue Mar 22 20:42:39 2016 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 22 Mar 2016 15:42:39 -0500 Subject: libraries that split packages In-Reply-To: <56F1AAB7.1030900@redhat.com> References: <56F031E5.4010308@codefx.org> <56F1AAB7.1030900@redhat.com> Message-ID: Regarding split packages, would an "easy" workaround be to introduce a new command line option so that modules that share packages get the same ClassLoader? Cheers, Paul On Tue, Mar 22, 2016 at 3:27 PM, Richard Opalka wrote: > Hi Nicolai, > > some examples can be found here: > > https://issues.jboss.org/browse/WFLY-6375 > > Any "Service Provider" based jar is a potential problem. > > Rio > > > On 03/21/2016 06:39 PM, Nicolai Parlog wrote: > >> Hi! >> >> Are there any numbers on how severe the split package situation is, i.e. >> how many libraries split packages with the JDK or among themselves? >> >> I am also interested in concrete examples. I only know of xml-apis[1] >> and FindBugs-JSR305[2] but I am sure many more exist. >> >> Can anybody help me out? >> >> so long ... Nicolai >> >> >> [1] http://search.maven.org/#artifactdetails|xml-apis|xml-apis|2.0.2|jar >> [2] http://mvnrepository.com/artifact/com.google.code.findbugs/jsr305 >> > > From nipa at codefx.org Tue Mar 22 20:58:59 2016 From: nipa at codefx.org (Nicolai Parlog) Date: Tue, 22 Mar 2016 21:58:59 +0100 Subject: libraries that split packages In-Reply-To: References: <56F031E5.4010308@codefx.org> <56F1AAB7.1030900@redhat.com> Message-ID: <56F1B213.7050400@codefx.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Paul, but they _do_ get the same class loader (unless you do something fancy). The problem is that split packages allow monkey patching and other undesired edge cases. That a module can not read two modules which export a split package is not an accident but a safety mechanism supporting reliable configuration. Then there is the fact that class loading encounters problems (what where they exactly?) when packages are split, which means that we get a different limitation "for free": no two modules loaded by the same class loader may split a package - exported or not. so long ... Nicolai On 22.03.2016 21:42, Paul Benedict wrote: > Regarding split packages, would an "easy" workaround be to > introduce a new command line option so that modules that share > packages get the same ClassLoader? > > Cheers, Paul > > On Tue, Mar 22, 2016 at 3:27 PM, Richard Opalka > wrote: > >> Hi Nicolai, >> >> some examples can be found here: >> >> https://issues.jboss.org/browse/WFLY-6375 >> >> Any "Service Provider" based jar is a potential problem. >> >> Rio >> >> >> On 03/21/2016 06:39 PM, Nicolai Parlog wrote: >> >>> Hi! >>> >>> Are there any numbers on how severe the split package situation >>> is, i.e. how many libraries split packages with the JDK or >>> among themselves? >>> >>> I am also interested in concrete examples. I only know of >>> xml-apis[1] and FindBugs-JSR305[2] but I am sure many more >>> exist. >>> >>> Can anybody help me out? >>> >>> so long ... Nicolai >>> >>> >>> [1] >>> http://search.maven.org/#artifactdetails|xml-apis|xml-apis|2.0.2|jar >>> >>> [2] http://mvnrepository.com/artifact/com.google.code.findbugs/jsr305 >>> >> >> > - -- PGP Key: http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509 Web: http://codefx.org a blog about software development http://do-foss.de Free and Open Source Software for the City of Dortmund Twitter: https://twitter.com/nipafx -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJW8bISAAoJEMo7rS6czNUJVMQP/072wqyhGxJJMS81gJ9OgBfc KAvXRcrsD+DUxFPT74kdnQbxt6Vrh6nN9km61RWrxhiyMgh+MqLNHjpCnV4XOX2J wzsUM0ouPlw4tLHNbxJEqTVhUW5SJE95Wcsfi9+iFLZnJqqNdoNJNnrn2UZD97Fz maDeXtK2rKpsiv/WS0UiVT/Wp8Nhg0Cz0960UpLZOmXKbvAafixHBkxqwI9BTmmz SbJanSplENk+IPsdke4cE19Er/6xMobhAh0xqZ8di85UVZCgJrNIQmsn/xnQCdTb 02/221EzqYJUKyTwfjlwCNykFyzZSweODlrtiA8OpkieHd+r1JRFFxtqH1oNLIAP Hmulcpo4LbR38LHmVc1QQXAQoeJtUivulGFcS4YXXmDnqvtPAwUCt2lJfOgpyxJG 3i3eQ6IolRFeR27b0+dUeGUr8vYV/K1aCnehjdHt6DHsIyA8WeT68MJtSpr2LRuh FEjeoID8jDG4yKhCaVwsL2LKWeWqYCYYPVIT0gk8ay/iECumGj19U/i84o4dHJWD gWU+ld3IsRSgxERRBrf1EHPwIeUPh4aovgs46h2Uf91SGDK+ur0VjVF4DiutXh8U 0JfjeJXOtZqPveupCivyeiJAU5bbUwlYJGt0bBdDF6NlHSc67JGKvQc2BNk3JwVi lK76w/gqBs6pDO+E+ogq =6m1e -----END PGP SIGNATURE----- From mandy.chung at oracle.com Tue Mar 22 20:59:44 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 22 Mar 2016 13:59:44 -0700 Subject: Review request 8152227: Remove jdk.deploy.osx module descriptor Message-ID: <670F02CD-8A7D-4E54-A59E-A245B74E6CB7@oracle.com> $ hg remove src/jdk.deploy.osx/macosx/classes/module-info.java jdk.deploy.osx has been removed. This follows up a cleanup after merging with JDK-8148187. Mandy From nipa at codefx.org Tue Mar 22 21:00:02 2016 From: nipa at codefx.org (Nicolai Parlog) Date: Tue, 22 Mar 2016 22:00:02 +0100 Subject: libraries that split packages In-Reply-To: <56F1AAB7.1030900@redhat.com> References: <56F031E5.4010308@codefx.org> <56F1AAB7.1030900@redhat.com> Message-ID: <56F1B252.5000408@codefx.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Richard, thank you very much. so long ... Nicolai On 22.03.2016 21:27, Richard Opalka wrote: > Hi Nicolai, > > some examples can be found here: > > https://issues.jboss.org/browse/WFLY-6375 > > Any "Service Provider" based jar is a potential problem. > > Rio > > On 03/21/2016 06:39 PM, Nicolai Parlog wrote: >> Hi! >> >> Are there any numbers on how severe the split package situation >> is, i.e. how many libraries split packages with the JDK or among >> themselves? >> >> I am also interested in concrete examples. I only know of >> xml-apis[1] and FindBugs-JSR305[2] but I am sure many more >> exist. >> >> Can anybody help me out? >> >> so long ... Nicolai >> >> >> [1] >> http://search.maven.org/#artifactdetails|xml-apis|xml-apis|2.0.2|jar >> >> [2] http://mvnrepository.com/artifact/com.google.code.findbugs/jsr305 > - -- PGP Key: http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509 Web: http://codefx.org a blog about software development http://do-foss.de Free and Open Source Software for the City of Dortmund Twitter: https://twitter.com/nipafx -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJW8bJSAAoJEMo7rS6czNUJxiIP/RtaUVB0Qh8DF9Oy0jk6wKrE WjuES8qtoKVQ3rcvVv+0Xu10F8xCDP+evRYzxlhreMBHNSMv3StwdQDdjsUeErdQ lcIWOI2UUSsrFuI990Nnx8xQUaBbQO60DnDgBsa+Y4xhQBPM4vFODQkjixTzXQXl IDS6LO1LBo4wWEeMTjEbRlPkAPWvod7xDE/BzBpOQy2JKVlGkL3JEMIGpmVaZdF7 Lp8xPs+ezCYMcH/uaQDBYptm0tJanAsmRK25AgxahMBFnPWOwpLwLC6Dq9AOZko/ SdZFG9bm4Qdjfv+QsPJehACL6NJMWPtHD961BYd4oxurxhuC0E9RfdM+lk60mMAP 3VCndF4YJ6GGUbdpVtnnIrQdlBFyHc+SuHQJFulgkFR8tXPgOYhG4vS09v++cXq8 6JDNF91FyG7GTmsuMvSgzfJTNH5UvHDLJWzA89Jnb17S6W7JApfwdL22yms972N0 FuXjNFXnNM3TlCMEF7AA71+nY8KzBkMqwFz0LjZRchNkItZ0h2YRMbpPYl1qb4Yu +EKgaUpGkBoDqsfOgUV66BUgkHRmSCL91JWKcGEHsTkZPrX4UkYSTiM10ftehYKE mMvKUyGuP3D5Hxx8SsDzFQoXNWweSIcsZT2q7hLfCCDEl9iT/586SAEUtMOhKrUX HdsFkOcFTT03GmrQQbs6 =N5EK -----END PGP SIGNATURE----- From rfscholte at apache.org Tue Mar 22 21:16:50 2016 From: rfscholte at apache.org (Robert Scholte) Date: Tue, 22 Mar 2016 22:16:50 +0100 Subject: modulepath and classpath mixture In-Reply-To: <56F1352D.60506@gmail.com> References: <56CC57A1.2050109@oracle.com> <56CD6F36.8020503@oracle.com> <56F1352D.60506@gmail.com> Message-ID: On Tue, 22 Mar 2016 13:06:05 +0100, Peter Levart wrote: > > > On 02/24/2016 08:30 PM, Robert Scholte wrote: >> On Wed, 24 Feb 2016 09:52:06 +0100, Alan Bateman >> wrote: >> >>> >>> On 23/02/2016 21:10, Robert Scholte wrote: >>>> : >>>> >>>> If I understand this correctly I need to know the module name. >>> Has there been any discussion around having the module name in the >>> POM? From the mails then it sounds like the project is mostly >>> "unaware" that it is creating a module. The other thing that comes to >>> mind is the source layout and whether it will get to the point where >>> the module name is in the file path. I'm mostly thinking of multi >>> module projects where one might have the source to multiple modules in >>> the same source tree. >>> >>> -Alan >> >> The name of the module with not end up in pom-4.0.0, it'll simply break >> the xsd and would have effect on all other tools/IDEs/etc depending on >> the pom. >> The only place where one might specify the module name is in the >> configuration of the maven-compiler-plugin. >> In Brussels we talked about multimodules, but it makes more sense that >> 1 Maven project contains zero or one module-info[1]. >> And yes, I think a MavenProject will probably be unaware of its own >> module name. It knows its source roots and outputdirectories (for both >> main/java and test/java) and the packaged jar. Based on the >> availability of the module-info in one of these locations it knows how >> to construct the commandline arguments. >> At least, this is what I'm hoping to achieve. >> >> thanks, >> Robert >> >> [1] https://twitter.com/rfscholte/status/694599731515899904 > > Hi Robert, > > Why do you want to support tests that "inject" classes into packages of > main artifact? Is this mainly because that's how it is done today? Yes, that's why. The success of modularization depends on the ease of migration. Javac already comes with a lot of options and flags to make this possible, it is Mavens task to set these with the right values. My current opinion is that I don't want to force users to add module-info files to the test sources, but the module structure of the main sources should be respected. If you want a separate module for testing, that's up to you. If people want to patch the main module, that fine too. If javac supports it, then Maven should support that too. thanks, Robert > With modules I would rather create tests in its own module and use > qualified exports from otherwise concealed packages of main module to > give tests access to types that are not accessible otherwise. This > however means that main module would have to use public qualifier on > types and members to allow test module to access them. In effect > substituting the package-private-nes with partly concealed packages to > enable testability. > > Perhaps jigsaw should realize that testabililty is an important aspect > to support. Forcing tools to compile a suitable set of javac and java > options to compile or inject new classes into an existing module and > augment it's dependencies is not very pleasant. Maybe this could be > supported with a little twist to the accessibility rules. Let me borrow > a rough idea that already circulated this list a while ago and modify it > to fit on the top of jigsaw accessibility rules. > > Suppose that a qualified export of a package to the specific module(s) > could be augmented with say a "private" keyword: > > module my.mod { > requires ...; > export private my.mod.internal to my.mod.test; > } > > module my.mod.test { > requires my.mod; > requires junit; > } > > ...which would not only export the package to the specific module(s), > but also enable access to package-private types/members of that package > from the target module(s) as though those types/members were public for > them and for them only. > > It would only be possible to specify "private" keyword with qualified > exports - not with unqualified. > > Would that be against any jigsaw goals? > > Regards, Peter From david.lloyd at redhat.com Tue Mar 22 21:22:19 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 22 Mar 2016 16:22:19 -0500 Subject: modulepath and classpath mixture In-Reply-To: <56F1352D.60506@gmail.com> References: <56CC57A1.2050109@oracle.com> <56CD6F36.8020503@oracle.com> <56F1352D.60506@gmail.com> Message-ID: <56F1B78B.50001@redhat.com> On 03/22/2016 07:06 AM, Peter Levart wrote: > > > On 02/24/2016 08:30 PM, Robert Scholte wrote: >> On Wed, 24 Feb 2016 09:52:06 +0100, Alan Bateman >> wrote: >> >>> >>> On 23/02/2016 21:10, Robert Scholte wrote: >>>> : >>>> >>>> If I understand this correctly I need to know the module name. >>> Has there been any discussion around having the module name in the >>> POM? From the mails then it sounds like the project is mostly >>> "unaware" that it is creating a module. The other thing that comes to >>> mind is the source layout and whether it will get to the point where >>> the module name is in the file path. I'm mostly thinking of multi >>> module projects where one might have the source to multiple modules >>> in the same source tree. >>> >>> -Alan >> >> The name of the module with not end up in pom-4.0.0, it'll simply >> break the xsd and would have effect on all other tools/IDEs/etc >> depending on the pom. >> The only place where one might specify the module name is in the >> configuration of the maven-compiler-plugin. >> In Brussels we talked about multimodules, but it makes more sense that >> 1 Maven project contains zero or one module-info[1]. >> And yes, I think a MavenProject will probably be unaware of its own >> module name. It knows its source roots and outputdirectories (for both >> main/java and test/java) and the packaged jar. Based on the >> availability of the module-info in one of these locations it knows how >> to construct the commandline arguments. >> At least, this is what I'm hoping to achieve. >> >> thanks, >> Robert >> >> [1] https://twitter.com/rfscholte/status/694599731515899904 > > Hi Robert, > > Why do you want to support tests that "inject" classes into packages of > main artifact? Is this mainly because that's how it is done today? With > modules I would rather create tests in its own module and use qualified > exports from otherwise concealed packages of main module to give tests > access to types that are not accessible otherwise. This however means > that main module would have to use public qualifier on types and members > to allow test module to access them. In effect substituting the > package-private-nes with partly concealed packages to enable testability. > > Perhaps jigsaw should realize that testabililty is an important aspect > to support. Forcing tools to compile a suitable set of javac and java > options to compile or inject new classes into an existing module and > augment it's dependencies is not very pleasant. Maybe this could be > supported with a little twist to the accessibility rules. Let me borrow > a rough idea that already circulated this list a while ago and modify it > to fit on the top of jigsaw accessibility rules. > > Suppose that a qualified export of a package to the specific module(s) > could be augmented with say a "private" keyword: > > module my.mod { > requires ...; > export private my.mod.internal to my.mod.test; > } > > module my.mod.test { > requires my.mod; > requires junit; > } > > ...which would not only export the package to the specific module(s), > but also enable access to package-private types/members of that package > from the target module(s) as though those types/members were public for > them and for them only. FWIW This is something I've been asking for in the JPMS EG. I think this would be an incredibly powerful and useful security tool... and could also potentially eliminate lots of "shared secrets" from the JDK code base (and a few others as well). Not just for tests but also for other existing code bases which today have to rely on privacy-by-convention/documentation for this kind of sharing. > It would only be possible to specify "private" keyword with qualified > exports - not with unqualified. > > Would that be against any jigsaw goals? > > Regards, Peter > -- - DML From rfscholte at apache.org Tue Mar 22 21:23:44 2016 From: rfscholte at apache.org (Robert Scholte) Date: Tue, 22 Mar 2016 22:23:44 +0100 Subject: modulepath and classpath mixture In-Reply-To: References: <56CBAD62.3010508@oracle.com> <20160316135501.530460938eggemoggin.niobe.net> Message-ID: > maven-builder-support/src/test/java/org/apache/maven/building/DefaultProblemTest.java:[1,1] > package exists in another module: maven.builder.support Just wondering, is this the expected behavior? DefaultProblemTest is on the *classpath* and I wouldn't expect that these entries would have any effect on the modulepath entries. I would expect that the packages between modules are checked, and that all these packages are exposed to the classpath; no extra check if classpath packages are in conflict with module packages. The message says ' in *another* module', but this directory is not a module, which makes it extra confusing. thanks, Robert On Thu, 17 Mar 2016 20:51:32 +0100, Robert Scholte wrote: > Hi, > > it seems that simply adding -addmods ALL-MODULE-PATH isn't enough to > compile the test-sources, and some already referred to it. > > Here's the compiler error: > maven-builder-support/src/test/java/org/apache/maven/building/DefaultProblemTest.java:[1,1] > package exists in another module: maven.builder.support > > Let me quote Alan from one of the first responses on this thread: > "For the tests then I assume they are in the same packages as the > sources under src/main/java, is that right? > > In that case I think you will want to compile the tests as if they are > part of the module: > > javac -Xmodule:m -d testclasses/m -mp m.jar test/java/... > > where m is the module name and the module (with sources in > src/main/java) has already been compiled and then packaged as m.jar. The > -Xmodule: option tells the compiler that you compiling the test > classes as if they are part of module m. There is no module-info.java in > the test tree." > > To me it seems like the need for knowing the module name keeps returning. > This increases the need for a proper implementation of the > maven-compiler-plugin as a multirelease JAR. > The pattern as shown during FOSDEM showed that the idea works, but it is > not solid enough. > And the next question would be: can Maven (or actually Plexus > ClassWorld) handle this? > > I'll need to work out the things to be done and try to get more Maven > developers involved. > > thanks, > Robert > > On Wed, 16 Mar 2016 21:55:01 +0100, wrote: > >> 2016/2/27 3:25 -0800, rfscholte at apache.org: >>> I noticed[1] that -addmods already has a special option: ALL-SYSTEM >>> What I'm looking for is something like ALL-MP or ALL-MODULEPATH, which >>> simply exposes all modules on the modulepath to the classpath. The set >>> of >>> moduleEntries on the modulePath are already chosen with care and are in >>> the end all required to be able to compile the test-classes without the >>> need of knowing the name of the module being used to compile with. >> >> We added a special ALL-MODULE-PATH token to the -addmods option, with >> this description now in JEP 261 (http://openjdk.java.net/jeps/261): >> >> As a further special case, if `` is `ALL-MODULE-PATH` then all >> observable modules found on module paths are added to the root set. >> `ALL-MODULE-PATH` is valid at compile time when compiling classes in >> the >> unnamed module, and at run time when the main class of the >> application is >> loaded from the class path into the unnamed module. >> >> This change is in Jigsaw EA build #4647 (https://jdk9.java.net/jigsaw/). >> Please try it out and let us know what you think. >> >> - Mark From pbenedict at apache.org Tue Mar 22 21:35:28 2016 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 22 Mar 2016 16:35:28 -0500 Subject: libraries that split packages In-Reply-To: <56F1B213.7050400@codefx.org> References: <56F031E5.4010308@codefx.org> <56F1AAB7.1030900@redhat.com> <56F1B213.7050400@codefx.org> Message-ID: Split packages is an important testing feature; less so for production code. Maven heavily relies on it for unit and integrating testing. Projects need to be able to build modules, have other modules rely on them, but the test cases need to "live" in the same packages (but different module) to access private-package classes. Cheers, Paul On Tue, Mar 22, 2016 at 3:58 PM, Nicolai Parlog wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hi Paul, > > but they _do_ get the same class loader (unless you do something fancy). > > The problem is that split packages allow monkey patching and other > undesired edge cases. That a module can not read two modules which > export a split package is not an accident but a safety mechanism > supporting reliable configuration. > > Then there is the fact that class loading encounters problems (what > where they exactly?) when packages are split, which means that we get > a different limitation "for free": no two modules loaded by the same > class loader may split a package - exported or not. > > so long ... Nicolai > > > > On 22.03.2016 21:42, Paul Benedict wrote: > > Regarding split packages, would an "easy" workaround be to > > introduce a new command line option so that modules that share > > packages get the same ClassLoader? > > > > Cheers, Paul > > > > On Tue, Mar 22, 2016 at 3:27 PM, Richard Opalka > > wrote: > > > >> Hi Nicolai, > >> > >> some examples can be found here: > >> > >> https://issues.jboss.org/browse/WFLY-6375 > >> > >> Any "Service Provider" based jar is a potential problem. > >> > >> Rio > >> > >> > >> On 03/21/2016 06:39 PM, Nicolai Parlog wrote: > >> > >>> Hi! > >>> > >>> Are there any numbers on how severe the split package situation > >>> is, i.e. how many libraries split packages with the JDK or > >>> among themselves? > >>> > >>> I am also interested in concrete examples. I only know of > >>> xml-apis[1] and FindBugs-JSR305[2] but I am sure many more > >>> exist. > >>> > >>> Can anybody help me out? > >>> > >>> so long ... Nicolai > >>> > >>> > >>> [1] > >>> http://search.maven.org/#artifactdetails|xml-apis|xml-apis|2.0.2|jar > >>> > >>> > [2] http://mvnrepository.com/artifact/com.google.code.findbugs/jsr305 > >>> > >> > >> > > > > - -- > > PGP Key: > http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509 > > Web: > http://codefx.org > a blog about software development > http://do-foss.de > Free and Open Source Software for the City of Dortmund > > Twitter: > https://twitter.com/nipafx > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQIcBAEBCAAGBQJW8bISAAoJEMo7rS6czNUJVMQP/072wqyhGxJJMS81gJ9OgBfc > KAvXRcrsD+DUxFPT74kdnQbxt6Vrh6nN9km61RWrxhiyMgh+MqLNHjpCnV4XOX2J > wzsUM0ouPlw4tLHNbxJEqTVhUW5SJE95Wcsfi9+iFLZnJqqNdoNJNnrn2UZD97Fz > maDeXtK2rKpsiv/WS0UiVT/Wp8Nhg0Cz0960UpLZOmXKbvAafixHBkxqwI9BTmmz > SbJanSplENk+IPsdke4cE19Er/6xMobhAh0xqZ8di85UVZCgJrNIQmsn/xnQCdTb > 02/221EzqYJUKyTwfjlwCNykFyzZSweODlrtiA8OpkieHd+r1JRFFxtqH1oNLIAP > Hmulcpo4LbR38LHmVc1QQXAQoeJtUivulGFcS4YXXmDnqvtPAwUCt2lJfOgpyxJG > 3i3eQ6IolRFeR27b0+dUeGUr8vYV/K1aCnehjdHt6DHsIyA8WeT68MJtSpr2LRuh > FEjeoID8jDG4yKhCaVwsL2LKWeWqYCYYPVIT0gk8ay/iECumGj19U/i84o4dHJWD > gWU+ld3IsRSgxERRBrf1EHPwIeUPh4aovgs46h2Uf91SGDK+ur0VjVF4DiutXh8U > 0JfjeJXOtZqPveupCivyeiJAU5bbUwlYJGt0bBdDF6NlHSc67JGKvQc2BNk3JwVi > lK76w/gqBs6pDO+E+ogq > =6m1e > -----END PGP SIGNATURE----- > > From russell.gold at oracle.com Tue Mar 22 22:20:52 2016 From: russell.gold at oracle.com (Russell Gold) Date: Tue, 22 Mar 2016 18:20:52 -0400 Subject: modulepath and classpath mixture In-Reply-To: <56CC57A1.2050109@oracle.com> References: <56CC57A1.2050109@oracle.com> Message-ID: I?d like to take a step back here. It may be that I have completely misunderstood what is going on, but this all seems to have gotten way more complicated than it should. I am assuming: 1) the project has both module and class path compile dependencies, and possibly has both module and class path test dependencies as well. 2) the artifact type ?module? (or something similar) is now recognized as indicating a Jigsaw module (which needs to go on the module path) 3) the classes being built may be put into their own module, but might not be. Then there are really four categories of dependencies. The compile step needs to place its jar dependencies on the class path and its module dependencies on the module path. I presume that is what Robert is already doing. The test-compile step needs to handle all four, including the compiled class in its test class path. Then there is no need to compile either the main or test classes as part of a module. They may use modules, but that is a different matter. No need for the -Xmodule switch at all. The only reference to module is as dependencies. Did I completely miss the point? - Russ > On Feb 23, 2016, at 7:59 AM, Alan Bateman wrote: > > > On 22/02/2016 20:44, Robert Scholte wrote: >> Hi, >> >> first of all I'd like to say that I'm very pleased with the new -mp options, these matches better with the way Apache Maven would like to work with jars and class-folders. >> >> Here's my use case: I noticed that if I add a module-info to src/main/java and put all compile-scoped dependencies to the module path, all compiles fines. >> I assume that developers are less interested in adding a module-info.java file to src/test/java, so that's what I'm doing right now too. >> Now it seems that I *must* add compile + test scoped to the *classpath* to be able to compile the test classes. >> My first approach was to leave the compile-scoped dependencies on the modulepath and all test-scoped dependencies on the classpath, so the modules keeps their inner related structure, but it seems that the classpath classes cannot access the modulepath classes. >> >> I'm looking for the confirmation that putting all dependencies on the classpath is indeed the right approach in this case. > > For the tests then I assume they are in the same packages as the sources under src/main/java, is that right? > > In that case I think you will want to compile the tests as if they are part of the module: > > javac -Xmodule:m -d testclasses/m -mp m.jar test/java/... > > where m is the module name and the module (with sources in src/main/java) has already been compiled and then packaged as m.jar. The -Xmodule: option tells the compiler that you compiling the test classes as if they are part of module m. There is no module-info.java in the test tree. > > Going further then I expect that JUnit or TestNG is also in the picture, I assume the class path. In that case, the command becomes: > > javac -Xmodule:m -d testclasses/m -mp m.jar \ > -cp junit-4.12.jar -XaddReads:m=ALL-UNNAMED \ > test/java/... > > where you are compiling test classes as if they are module m and at the same time referencing JUnit types on the class path. The -XaddReads:m=ALL-UNNAMED augments the module declaration to say that module m reads all unnamed modules, just think class path here. > > > In order to run then you can use -Xpatch to augment the module with the test classes: > > java -Xpatch:testclasses -mp m.jar -cp junit-4.12.jar -XaddReads:m=ALL-UNNAMED ... > > It is as if the test classes are in m.jar. The alternative is of course to add the test classes to the packaged module but you would still need the -XaddReads because module m does not (and can not) declare that it depends on types on the class path. > > > While on the topic then I should mention that we have a proposal coming to support patches as JAR files as I'm sure you will get to the point soon where the test classes are in a JAR file. > > Hopefully the above is useful. I completely agree with Jon that we need to put down detailed notes and examples. In the case of testing then we have tried out the popular test frameworks on the class path (as above) and also as modules. In the case of JUnit then we have been successful with it on a the module path as an automatic module. Definitely something to write up. > > -Alan From ropalka at redhat.com Tue Mar 22 22:29:09 2016 From: ropalka at redhat.com (Richard Opalka) Date: Tue, 22 Mar 2016 23:29:09 +0100 Subject: modulepath and classpath mixture In-Reply-To: References: <56CBAD62.3010508@oracle.com> <20160316135501.530460938eggemoggin.niobe.net> Message-ID: <56F1C735.8010209@redhat.com> Hi, I'm experiencing the same problem locally. When trying to build Oracle provided maven artifact from sources, namely http://search.maven.org/#artifactdetails|javax.annotation|javax.annotation-api|1.2|jar the build fails on JDK9 (with Jigsaw) with message: ./src/javax/annotation/Priority.java:42: error: package exists in another module: java.annotations.common package javax.annotation; ^ 1 error How is Jigsaw javac going to deal with such compilation scenarios? Rio On 03/22/2016 10:23 PM, Robert Scholte wrote: >> maven-builder-support/src/test/java/org/apache/maven/building/DefaultProblemTest.java:[1,1] >> package exists in another module: maven.builder.support > > Just wondering, is this the expected behavior? > > DefaultProblemTest is on the *classpath* and I wouldn't expect that these > entries would have any effect on the modulepath entries. I would > expect that the packages between modules are checked, and that all > these packages are exposed to the classpath; no extra check if > classpath packages are in conflict with module packages. > The message says ' in *another* module', but this directory is not a > module, which makes it extra confusing. > > thanks, > Robert > > On Thu, 17 Mar 2016 20:51:32 +0100, Robert Scholte > wrote: > >> Hi, >> >> it seems that simply adding -addmods ALL-MODULE-PATH isn't enough to >> compile the test-sources, and some already referred to it. >> >> Here's the compiler error: >> maven-builder-support/src/test/java/org/apache/maven/building/DefaultProblemTest.java:[1,1] >> package exists in another module: maven.builder.support >> >> Let me quote Alan from one of the first responses on this thread: >> "For the tests then I assume they are in the same packages as the >> sources under src/main/java, is that right? >> >> In that case I think you will want to compile the tests as if they >> are part of the module: >> >> javac -Xmodule:m -d testclasses/m -mp m.jar test/java/... >> >> where m is the module name and the module (with sources in >> src/main/java) has already been compiled and then packaged as m.jar. >> The -Xmodule: option tells the compiler that you compiling >> the test classes as if they are part of module m. There is no >> module-info.java in the test tree." >> >> To me it seems like the need for knowing the module name keeps >> returning. >> This increases the need for a proper implementation of the >> maven-compiler-plugin as a multirelease JAR. >> The pattern as shown during FOSDEM showed that the idea works, but it >> is not solid enough. >> And the next question would be: can Maven (or actually Plexus >> ClassWorld) handle this? >> >> I'll need to work out the things to be done and try to get more Maven >> developers involved. >> >> thanks, >> Robert >> >> On Wed, 16 Mar 2016 21:55:01 +0100, wrote: >> >>> 2016/2/27 3:25 -0800, rfscholte at apache.org: >>>> I noticed[1] that -addmods already has a special option: ALL-SYSTEM >>>> What I'm looking for is something like ALL-MP or ALL-MODULEPATH, which >>>> simply exposes all modules on the modulepath to the classpath. The >>>> set of >>>> moduleEntries on the modulePath are already chosen with care and >>>> are in >>>> the end all required to be able to compile the test-classes without >>>> the >>>> need of knowing the name of the module being used to compile with. >>> >>> We added a special ALL-MODULE-PATH token to the -addmods option, with >>> this description now in JEP 261 (http://openjdk.java.net/jeps/261): >>> >>> As a further special case, if `` is `ALL-MODULE-PATH` then >>> all >>> observable modules found on module paths are added to the root set. >>> `ALL-MODULE-PATH` is valid at compile time when compiling classes >>> in the >>> unnamed module, and at run time when the main class of the >>> application is >>> loaded from the class path into the unnamed module. >>> >>> This change is in Jigsaw EA build #4647 >>> (https://jdk9.java.net/jigsaw/). >>> Please try it out and let us know what you think. >>> >>> - Mark From ropalka at redhat.com Tue Mar 22 22:39:35 2016 From: ropalka at redhat.com (Richard Opalka) Date: Tue, 22 Mar 2016 23:39:35 +0100 Subject: modulepath and classpath mixture In-Reply-To: <56F1C735.8010209@redhat.com> References: <56CBAD62.3010508@oracle.com> <20160316135501.530460938eggemoggin.niobe.net> <56F1C735.8010209@redhat.com> Message-ID: <56F1C9A7.7000501@redhat.com> Hi, I just solved it by adding -Xmodule option: javac -Xmodule:java.annotations.common -sourcepath src `find -type f -name *.java` Rio On 03/22/2016 11:29 PM, Richard Opalka wrote: > Hi, > > I'm experiencing the same problem locally. > When trying to build Oracle provided maven artifact from sources, namely > > http://search.maven.org/#artifactdetails|javax.annotation|javax.annotation-api|1.2|jar > > > the build fails on JDK9 (with Jigsaw) with message: > > ./src/javax/annotation/Priority.java:42: error: package exists in > another module: java.annotations.common > package javax.annotation; > ^ > 1 error > > How is Jigsaw javac going to deal with such compilation scenarios? > > Rio > > On 03/22/2016 10:23 PM, Robert Scholte wrote: >>> maven-builder-support/src/test/java/org/apache/maven/building/DefaultProblemTest.java:[1,1] >>> package exists in another module: maven.builder.support >> >> Just wondering, is this the expected behavior? >> >> DefaultProblemTest is on the *classpath* and I wouldn't expect that >> these >> entries would have any effect on the modulepath entries. I would >> expect that the packages between modules are checked, and that all >> these packages are exposed to the classpath; no extra check if >> classpath packages are in conflict with module packages. >> The message says ' in *another* module', but this directory is not a >> module, which makes it extra confusing. >> >> thanks, >> Robert >> >> On Thu, 17 Mar 2016 20:51:32 +0100, Robert Scholte >> >> wrote: >> >>> Hi, >>> >>> it seems that simply adding -addmods ALL-MODULE-PATH isn't enough to >>> compile the test-sources, and some already referred to it. >>> >>> Here's the compiler error: >>> maven-builder-support/src/test/java/org/apache/maven/building/DefaultProblemTest.java:[1,1] >>> package exists in another module: maven.builder.support >>> >>> Let me quote Alan from one of the first responses on this thread: >>> "For the tests then I assume they are in the same packages as the >>> sources under src/main/java, is that right? >>> >>> In that case I think you will want to compile the tests as if they >>> are part of the module: >>> >>> javac -Xmodule:m -d testclasses/m -mp m.jar test/java/... >>> >>> where m is the module name and the module (with sources in >>> src/main/java) has already been compiled and then packaged as m.jar. >>> The -Xmodule: option tells the compiler that you compiling >>> the test classes as if they are part of module m. There is no >>> module-info.java in the test tree." >>> >>> To me it seems like the need for knowing the module name keeps >>> returning. >>> This increases the need for a proper implementation of the >>> maven-compiler-plugin as a multirelease JAR. >>> The pattern as shown during FOSDEM showed that the idea works, but >>> it is not solid enough. >>> And the next question would be: can Maven (or actually Plexus >>> ClassWorld) handle this? >>> >>> I'll need to work out the things to be done and try to get more >>> Maven developers involved. >>> >>> thanks, >>> Robert >>> >>> On Wed, 16 Mar 2016 21:55:01 +0100, wrote: >>> >>>> 2016/2/27 3:25 -0800, rfscholte at apache.org: >>>>> I noticed[1] that -addmods already has a special option: ALL-SYSTEM >>>>> What I'm looking for is something like ALL-MP or ALL-MODULEPATH, >>>>> which >>>>> simply exposes all modules on the modulepath to the classpath. The >>>>> set of >>>>> moduleEntries on the modulePath are already chosen with care and >>>>> are in >>>>> the end all required to be able to compile the test-classes >>>>> without the >>>>> need of knowing the name of the module being used to compile with. >>>> >>>> We added a special ALL-MODULE-PATH token to the -addmods option, with >>>> this description now in JEP 261 (http://openjdk.java.net/jeps/261): >>>> >>>> As a further special case, if `` is `ALL-MODULE-PATH` >>>> then all >>>> observable modules found on module paths are added to the root set. >>>> `ALL-MODULE-PATH` is valid at compile time when compiling classes >>>> in the >>>> unnamed module, and at run time when the main class of the >>>> application is >>>> loaded from the class path into the unnamed module. >>>> >>>> This change is in Jigsaw EA build #4647 >>>> (https://jdk9.java.net/jigsaw/). >>>> Please try it out and let us know what you think. >>>> >>>> - Mark From claes.redestad at oracle.com Wed Mar 23 01:08:01 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 23 Mar 2016 02:08:01 +0100 Subject: Review request 8152227: Remove jdk.deploy.osx module descriptor In-Reply-To: <670F02CD-8A7D-4E54-A59E-A245B74E6CB7@oracle.com> References: <670F02CD-8A7D-4E54-A59E-A245B74E6CB7@oracle.com> Message-ID: <56F1EC71.6030701@oracle.com> Looks good, Mandy /Claes On 2016-03-22 21:59, Mandy Chung wrote: > $ hg remove src/jdk.deploy.osx/macosx/classes/module-info.java > > jdk.deploy.osx has been removed. This follows up a cleanup after merging with JDK-8148187. > > Mandy From mandy.chung at oracle.com Wed Mar 23 01:59:18 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 22 Mar 2016 18:59:18 -0700 Subject: Review Request 8152197: Single place to specify module-specific information for images build In-Reply-To: <56F1063E.6050004@oracle.com> References: <06AF330D-151A-4063-9C61-0AD0A417EB04@oracle.com> <56F04412.3060205@oracle.com> <659A3873-F979-4458-A163-A9CDF21CCF10@oracle.com> <56F1063E.6050004@oracle.com> Message-ID: Erik, This is the updated webrev incorporating your suggested patch for the imported modules: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8152197/webrev.02 Mandy > On Mar 22, 2016, at 1:45 AM, Erik Joelsson wrote: > > Hello, > > I like the consolidation of all module information. I don't like that every time Modules.gmk is included, it calculates the IMPORTED_MODULES. It also looks like that can't work in the current patch since the call is before the definition of FindImportedModules. > > I can see if I can modify this to have the calculation done lazily or at least only on demand. > > /Erik > > On 2016-03-22 01:42, Mandy Chung wrote: >>> On Mar 21, 2016, at 5:36 PM, Mandy Chung wrote: >>> >>>> On Mar 21, 2016, at 11:57 AM, Alan Bateman wrote: >>>> >>>> On 21/03/2016 17:32, Mandy Chung wrote: >>>>> Erik, >>>>> >>>>> This cleans up several makefiles and now have one single file (make/common/Modules.gmk) to specify the module-specific information for the build: >>>>> >>>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8152197/webrev.00/index.html >>>>> >>>>> >>>> This looks a good clean-up. >>>> >>>> One thing that isn't clear is how to get tool modules into the JRE. I suspect that JRE_MODULES needs to be $(BOOT_MODULES) + $(PLATFORM_MODULES) + jdk.policytool + jdk.scripting.nashorn.shell to be consistent with JRE 8 builds. >>> >>> Good catch. I compared the modules listed in make/Images.gmk before the change with make/common/Modules.gmk and found some existing issues - jdk.policytool has not been linked in JRE and I can?t quite tell why jdk.jvmstat and jdk.jvmstat.rmi are linked in JRE. I believe we only need the following tools be included in JRE to be consistent with JRE 8 builds: >>> >>> JRE_TOOL_MODULES += \ >>> jdk.pack200 \ >>> jdk.policytool \ >>> jdk.scripting.nashorn.shell \ >>> >>> Updated webrev: >>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8152197/webrev.01/index.html >> >> In fact, JDK-8071338 has moved policytool from JRE to JDK in JDK 9. webrev.01 updated in place. >> >> Mandy >> > From Alan.Bateman at oracle.com Wed Mar 23 06:50:08 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 Mar 2016 06:50:08 +0000 Subject: Review request 8152227: Remove jdk.deploy.osx module descriptor In-Reply-To: <670F02CD-8A7D-4E54-A59E-A245B74E6CB7@oracle.com> References: <670F02CD-8A7D-4E54-A59E-A245B74E6CB7@oracle.com> Message-ID: <56F23CA0.1070704@oracle.com> Looks good, easily missed when jake was sync'ed up. On 22/03/2016 20:59, Mandy Chung wrote: > $ hg remove src/jdk.deploy.osx/macosx/classes/module-info.java > > jdk.deploy.osx has been removed. This follows up a cleanup after merging with JDK-8148187. > > Mandy From Alan.Bateman at oracle.com Wed Mar 23 07:14:24 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 Mar 2016 07:14:24 +0000 Subject: modulepath and classpath mixture In-Reply-To: References: <56CBAD62.3010508@oracle.com> <20160316135501.530460938eggemoggin.niobe.net> Message-ID: <56F24250.8050309@oracle.com> On 22/03/2016 21:23, Robert Scholte wrote: >> maven-builder-support/src/test/java/org/apache/maven/building/DefaultProblemTest.java:[1,1] >> package exists in another module: maven.builder.support > > Just wondering, is this the expected behavior? > > DefaultProblemTest is on the *classpath* and I wouldn't expect that these > entries would have any effect on the modulepath entries. I would > expect that the packages between modules are checked, and that all > these packages are exposed to the classpath; no extra check if > classpath packages are in conflict with module packages. > The message says ' in *another* module', but this directory is not a > module, which makes it extra confusing. It looks like it is trying to compile org/apache/maven/building/DefaultProblemTest.java on the class path (unnamed module) but package org.apache.maven.building is in module maven.builder.support on the module path. I think this is back to needing the module name as this can only work if you compile the test as if it is part of the module, meaning -Xmodule:maven.builder.support here. -Alan From Alan.Bateman at oracle.com Wed Mar 23 07:17:02 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 Mar 2016 07:17:02 +0000 Subject: libraries that split packages In-Reply-To: References: <56F031E5.4010308@codefx.org> <56F1AAB7.1030900@redhat.com> <56F1B213.7050400@codefx.org> Message-ID: <56F242EE.3060707@oracle.com> On 22/03/2016 21:35, Paul Benedict wrote: > Split packages is an important testing feature; less so for production > code. Maven heavily relies on it for unit and integrating testing. Projects > need to be able to build modules, have other modules rely on them, but the > test cases need to "live" in the same packages (but different module) to > access private-package classes. > and just to say that we have options for injecting tests into modules at both compile time and runtime. These command line options aren't sometime that many developers will grok but I hope we get to the point where the tools makes it easy. -Alan From Alan.Bateman at oracle.com Wed Mar 23 07:21:46 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 Mar 2016 07:21:46 +0000 Subject: modulepath and classpath mixture In-Reply-To: References: <56CC57A1.2050109@oracle.com> Message-ID: <56F2440A.7010505@oracle.com> On 22/03/2016 22:20, Russell Gold wrote: > I?d like to take a step back here. It may be that I have completely misunderstood what is going on, but this all seems to have gotten way more complicated than it should. > > I am assuming: > > 1) the project has both module and class path compile dependencies, and possibly has both module and class path test dependencies as well. > 2) the artifact type ?module? (or something similar) is now recognized as indicating a Jigsaw module (which needs to go on the module path) > 3) the classes being built may be put into their own module, but might not be. > > Then there are really four categories of dependencies. The compile step needs to place its jar dependencies on the class path and its module dependencies on the module path. I presume that is what Robert is already doing. > The test-compile step needs to handle all four, including the compiled class in its test class path. > > Then there is no need to compile either the main or test classes as part of a module. They may use modules, but that is a different matter. No need for the -Xmodule switch at all. The only reference to module is as dependencies. > > Did I completely miss the point? > It depends on where the tests live. If they are black box tests that only exercise the API (the public types in the module's exported packages) then they can live anywhere. If they are in the same class loader and package as the code they are testing (the norm in Maven) then they need to compiled as if they are part of the module. We might think of these as white box tests as they can make use of public types in packages that aren't exported, maybe they are using package-private types/methods too. -Alan From Alan.Bateman at oracle.com Wed Mar 23 07:55:50 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 Mar 2016 07:55:50 +0000 Subject: Upgrading EE modules (was Re: modulepath and classpath mixture) In-Reply-To: <56F1C735.8010209@redhat.com> References: <56CBAD62.3010508@oracle.com> <20160316135501.530460938eggemoggin.niobe.net> <56F1C735.8010209@redhat.com> Message-ID: <56F24C06.2000208@oracle.com> On 22/03/2016 22:29, Richard Opalka wrote: > Hi, > > I'm experiencing the same problem locally. > When trying to build Oracle provided maven artifact from sources, namely > > http://search.maven.org/#artifactdetails|javax.annotation|javax.annotation-api|1.2|jar > > > the build fails on JDK9 (with Jigsaw) with message: > > ./src/javax/annotation/Priority.java:42: error: package exists in > another module: java.annotations.common > package javax.annotation; > ^ > 1 error > > How is Jigsaw javac going to deal with such compilation scenarios? I've changed the subject line as this issue seems to be about how to compile with, and make use of, the EE versions of the so-called "Common Annotations". The JSR 250 defined Common Annotations is one of a small number of APIs that is shared between Java SE and Java EE. Java SE defines a subset, where Java EE defines the full API (or the full set of annotations in this case). With JDK 8 and older then Java EE or app servers needed to deploy an EE version to override the Java SE version. The only supported way of doing this was via the endorsed standards override mechanism (that mechanism was documented for both endorsed standards and standalone technologies with JSR 250 one of the standalone technologies). As things currently stand, the replacement to the endorsed standards override mechanism is upgradeable modules. In JEP 261 you will see the option -upgrademodulepath that can be used to deploy modules that upgrade/override modules in the JDK. So what you need here is the Java EE version of the java.annotations.common module and deploy it via -upgrademodulepath to upgrade/override the module in the JDK. Unfortunately there isn't an EE version of this module yet so you have to create it yourself. Not hard, you just need to compile the following module-info.java and put it in the top-level directory of the JAR file to make it a modular JAR. module java.annotations.common { exports javax.annotation; exports javax.annotation.security; exports javax.annotation.sql; } Note that the Java SE/JDK version exports one package, the Java EE version exports three packages. You can check that the EE version is observable with the following common: java -upgrademodulepath libs/javax.annotation-api.jar -listmods or -listmods:java.annotations.common to have the module definition printed so that you can checks the exports. -Alan From weijun.wang at oracle.com Wed Mar 23 08:12:27 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 23 Mar 2016 16:12:27 +0800 Subject: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules In-Reply-To: References: <56C3381E.4070903@oracle.com> <9b8fd97d-852e-ec62-c481-f68d2e6be8da@oracle.com> <4E118FCE-0D69-4F32-B8FA-21DA9830AD23@oracle.com> <1A423858-F07C-4ECA-BD9B-14B78165407E@oracle.com> <2CFD24DE-8CE5-49AF-B3A2-E5EC9AB3D375@oracle.com> <794bd57c-66d6-73e6-7387-be8697c356ba@oracle.com> <56C57FF8.2010205@oracle.com> <56C5946C.1020806@oracle.com> <99442C80-5980-4F01-929D-472BAF6A003D@oracle.com> <56C6D55B.2070600@oracle.com> <42EAA796-09E7-4209-9C7E-8788D66CF67E@oracle.com> <56C6E200.3070800@oracle.com> <4BB3D736-BC1C-4CAE-9C04-43AE882DDBC9@oracle.com> <301EAFFD-F524-40F8-A09E-65E486E237DC@oracle.com> <04F33E30-05B6-4156-BE5D-3838D945CE5C@oracle.com> <54FEEAB6-BEA4-427D-8CE7-0AF25BBDF75E@oracle.com> <53302B38-A13E-43B3-ACEF-CC6905793856@oracle.com> Message-ID: <8595858E-209C-431D-96A5-3D1868E7348B@oracle.com> > >> The SunPKCS11 compatibility line will be add in a sub-patch for jake. >> > > You can send me the jake?s delta patch once you push the change to jdk9/dev. I've been busy recently on DRBG and will be back working on this one. Now that jake/m3 is in jdk9/dev I assume I will just include the jake-related codes and directly push a single changeset to jdk9/dev. Right? Thanks Max > > Thanks > Mandy From Alan.Bateman at oracle.com Wed Mar 23 08:20:47 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 Mar 2016 08:20:47 +0000 Subject: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules In-Reply-To: <8595858E-209C-431D-96A5-3D1868E7348B@oracle.com> References: <794bd57c-66d6-73e6-7387-be8697c356ba@oracle.com> <56C57FF8.2010205@oracle.com> <56C5946C.1020806@oracle.com> <99442C80-5980-4F01-929D-472BAF6A003D@oracle.com> <56C6D55B.2070600@oracle.com> <42EAA796-09E7-4209-9C7E-8788D66CF67E@oracle.com> <56C6E200.3070800@oracle.com> <4BB3D736-BC1C-4CAE-9C04-43AE882DDBC9@oracle.com> <301EAFFD-F524-40F8-A09E-65E486E237DC@oracle.com> <04F33E30-05B6-4156-BE5D-3838D945CE5C@oracle.com> <54FEEAB6-BEA4-427D-8CE7-0AF25BBDF75E@oracle.com> <53302B38-A13E-43B3-ACEF-CC6905793856@oracle.com> <8595858E-209C-431D-96A5-3D1868E7348B@oracle.com> Message-ID: <56F251DF.3080208@oracle.com> On 23/03/2016 08:12, Wang Weijun wrote: > Now that jake/m3 is in jdk9/dev I assume I will just include the jake-related codes and directly push a single changeset to jdk9/dev. Right? > Yes, changes like this this can be pushed via jdk9/dev. In the mean-time, we will continue to work in jigsaw/jake as there are many core areas where we'll need to prototype and iterate on. Some of these changes might be disruptive and/or require coordinated changes to the compiler and runtime so we'll work on them here before they go into jdk9/dev. -Alan From Alan.Bateman at oracle.com Wed Mar 23 10:38:59 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 Mar 2016 10:38:59 +0000 Subject: libraries that split packages In-Reply-To: <56F1AAB7.1030900@redhat.com> References: <56F031E5.4010308@codefx.org> <56F1AAB7.1030900@redhat.com> Message-ID: <56F27243.7010709@oracle.com> On 22/03/2016 20:27, Richard Opalka wrote: > Hi Nicolai, > > some examples can be found here: > > https://issues.jboss.org/browse/WFLY-6375 > This link didn't work for me yesterday but it does now. The six modules that you have listed here are the EE modules that are in Java SE. If you compare the output of the following commands: java -limitmods java.se -listmods vs. java -limitmods java.se.ee -listmods then you'll see the same six. In all cases then the way to override/upgrade these to the EE version is to deploy the EE version of the module on the upgrade module path. In recent years then the need for app servers to upgrade JAXB and JAX-WS has diminished significantly so you might not need to upgrade both of those. -Alan From scolebourne at joda.org Wed Mar 23 11:01:00 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 23 Mar 2016 11:01:00 +0000 Subject: modulepath and classpath mixture In-Reply-To: <56F2440A.7010505@oracle.com> References: <56CC57A1.2050109@oracle.com> <56F2440A.7010505@oracle.com> Message-ID: On 23 March 2016 at 07:21, Alan Bateman wrote: > If they are in the same class loader and package as > the code they are testing (the norm in Maven) then they need to compiled as > if they are part of the module. I struggle with that idea. To me, tests are very definitely not part of the module. To me, they are very clearly a separate module, one that uses the base module (separate tree of code, separate dependencies, separate compilation phase). In maven, there is even the possibility for one testing module to depend on another testing module, a very useful feature. The only special case about testing modules is that they are given full access to everything in the underlying module. Forcing test code to be embedded within the actual module just because the module design doesn't allow any other option is flawed IMO. Peter Levart's mail suggested one approach to provide the necessary access rights for testing modules. But it still requires publication package-by-package. Really, what is needed is a way to express that the testing module is intimately connected, perhaps imposing a requirement that both are loaded in the same classloader. eg. module my.mod { fully-exposed-to my.mod.test; } module my.mod.test { requires my.mod; // since other end specifies fully-exposed-to, this gets full access requires junit; } Is this issue on the list of open issues? http://openjdk.java.net/projects/jigsaw/spec/issues/ Stephen From David.Hill at Oracle.com Wed Mar 23 12:28:27 2016 From: David.Hill at Oracle.com (David Hill) Date: Wed, 23 Mar 2016 08:28:27 -0400 Subject: modulepath and classpath mixture In-Reply-To: References: <56CC57A1.2050109@oracle.com> <56F2440A.7010505@oracle.com> Message-ID: <56F28BEB.2030902@Oracle.com> On 3/23/16, 7:01 AM, Stephen Colebourne wrote: > On 23 March 2016 at 07:21, Alan Bateman wrote: >> If they are in the same class loader and package as >> the code they are testing (the norm in Maven) then they need to compiled as >> if they are part of the module. We have worked through this white/black box testing classes in JavaFX, While not a perfect solution we have something that seems to work (at least we get the tests to pass anyway :-) I created a OpenJFX Unit test in Jigsaw TOI in our wiki here . While it is specific to the JFX build, there is a lot of detail in there that is general to unit testing and Jigsaw. There are several keys here. 1) separate out the white/black box test classes, creating new "shims" (white box classes) as needed. We picked the "test.*" package for the black box tests and refactored all of our unit tests into it. 2) at build time create a copy of our "core" classes with the white box shims added in so that we have one module override tree 3) use Xpatch, @addExports so that things can be found "@addExport" is an argfile usage which makes adding multiline -XaddExport: options reasonable. If you don't know about @argfile, you might want to look at my wiki page just to learn about those :-) Certainly the solution we have took a lot of rework, and we did debate with the Jigsaw team about several elements of it. But what we ended up with works within the current boundaries. BTW - any feedback or questions on the TOI would be appreciated. https://wiki.openjdk.java.net/display/OpenJFX/OpenJFX+unit+tests > I struggle with that idea. > > To me, tests are very definitely not part of the module. To me, they > are very clearly a separate module, one that uses the base module > (separate tree of code, separate dependencies, separate compilation > phase). In maven, there is even the possibility for one testing module > to depend on another testing module, a very useful feature. > > The only special case about testing modules is that they are given > full access to everything in the underlying module. Forcing test code > to be embedded within the actual module just because the module design > doesn't allow any other option is flawed IMO. > > Peter Levart's mail suggested one approach to provide the necessary > access rights for testing modules. But it still requires publication > package-by-package. Really, what is needed is a way to express that > the testing module is intimately connected, perhaps imposing a > requirement that both are loaded in the same classloader. eg. > > module my.mod { > fully-exposed-to my.mod.test; > } > module my.mod.test { > requires my.mod; // since other end specifies fully-exposed-to, > this gets full access > requires junit; > } > > Is this issue on the list of open issues? > http://openjdk.java.net/projects/jigsaw/spec/issues/ > > Stephen -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From Alan.Bateman at oracle.com Wed Mar 23 12:51:24 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 Mar 2016 12:51:24 +0000 Subject: modulepath and classpath mixture In-Reply-To: References: <56CC57A1.2050109@oracle.com> <56F2440A.7010505@oracle.com> Message-ID: <56F2914C.3030706@oracle.com> On 23/03/2016 11:01, Stephen Colebourne wrote: > On 23 March 2016 at 07:21, Alan Bateman wrote: >> If they are in the same class loader and package as >> the code they are testing (the norm in Maven) then they need to compiled as >> if they are part of the module. > I struggle with that idea. If types T1 and T2 have the same defining loader and both types are in the same package then they are in the same module. T1 can't be module M1 and T2 in a different module M2. (I shudder the thought of it being different or attempting to change what default/package access means after all these years.) > > To me, tests are very definitely not part of the module. To me, they > are very clearly a separate module, one that uses the base module > (separate tree of code, separate dependencies, separate compilation > phase). In maven, there is even the possibility for one testing module > to depend on another testing module, a very useful feature. You can of course develop tests in their own modules, this should be painless for black-box testing. White-box testing is more complicated of course as such tests need to nestmate with the module internals they are testing. If people are testing package private classes or methods today then those test classes are in the same loader/package as the code they are testing. There are several discussions points in the mails here but I believe it is the scenario that Robert is trying to get working with Maven. It seems more of a convention though, it may be that many tests aren't really white tests and they could like in their own test.* packages and other modules without difficulty. > > The only special case about testing modules is that they are given > full access to everything in the underlying module. Forcing test code > to be embedded within the actual module just because the module design > doesn't allow any other option is flawed IMO. There isn't anything forcing the test sources to be the same source tree as the classes they are testing. Tests that directly make use of module internals can be compiled separately, have dependences beyond what the original module requires, and be packaged in their own artifact. When running then the -Xpatch option brings them together. If the tools can make this easy for average developers then it might not be too bad. -Alan. From russell.gold at oracle.com Wed Mar 23 13:02:10 2016 From: russell.gold at oracle.com (Russell Gold) Date: Wed, 23 Mar 2016 09:02:10 -0400 Subject: modulepath and classpath mixture In-Reply-To: <56F2440A.7010505@oracle.com> References: <56CC57A1.2050109@oracle.com> <56F2440A.7010505@oracle.com> Message-ID: > On Mar 23, 2016, at 3:21 AM, Alan Bateman wrote: > > On 22/03/2016 22:20, Russell Gold wrote: >> I?d like to take a step back here. It may be that I have completely misunderstood what is going on, but this all seems to have gotten way more complicated than it should. >> >> I am assuming: >> >> 1) the project has both module and class path compile dependencies, and possibly has both module and class path test dependencies as well. >> 2) the artifact type ?module? (or something similar) is now recognized as indicating a Jigsaw module (which needs to go on the module path) >> 3) the classes being built may be put into their own module, but might not be. >> >> Then there are really four categories of dependencies. The compile step needs to place its jar dependencies on the class path and its module dependencies on the module path. I presume that is what Robert is already doing. >> The test-compile step needs to handle all four, including the compiled class in its test class path. >> >> Then there is no need to compile either the main or test classes as part of a module. They may use modules, but that is a different matter. No need for the -Xmodule switch at all. The only reference to module is as dependencies. >> >> Did I completely miss the point? >> > It depends on where the tests live. If they are black box tests that only exercise the API (the public types in the module's exported packages) then they can live anywhere. If they are in the same class loader and package as the code they are testing (the norm in Maven) then they need to compiled as if they are part of the module. We might think of these as white box tests as they can make use of public types in packages that aren't exported, maybe they are using package-private types/methods too. > Why does the module concept even need to exist at that point? Seems to me that it is much simpler to treat them as classes on the class path rather than a module. The module status can come in during packaging, no? - Russ From Alan.Bateman at oracle.com Wed Mar 23 14:05:19 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 Mar 2016 14:05:19 +0000 Subject: modulepath and classpath mixture In-Reply-To: References: <56CC57A1.2050109@oracle.com> <56F2440A.7010505@oracle.com> Message-ID: <56F2A29F.9050507@oracle.com> On 23/03/2016 13:02, Russell Gold wrote: > : > > Why does the module concept even need to exist at that point? Seems to me that it is much simpler to treat them as classes on the class path rather than a module. The module status can come in during packaging, no? > I'm not sure that I understand your mail. Are you asking why are modules are supported at compile-time? Or are you asking why the compiler doesn't allow packages to be split between the unnamed module and a named module? -Alan. From russell.gold at oracle.com Wed Mar 23 14:15:04 2016 From: russell.gold at oracle.com (Russell Gold) Date: Wed, 23 Mar 2016 10:15:04 -0400 Subject: modulepath and classpath mixture In-Reply-To: <56F2A29F.9050507@oracle.com> References: <56CC57A1.2050109@oracle.com> <56F2440A.7010505@oracle.com> <56F2A29F.9050507@oracle.com> Message-ID: <85AD85D8-5623-418A-BB19-E3A66350AA59@oracle.com> Here are my assumptions, which you can correct. 1. A jar or classes directory placed on a class path are treated as part of the unnamed module 2. A jar containing a module-info file is treated as a module when placed on a module path, and restricts access to non-exported packages 3. A jmod file is only usable on the module path. If a class directory or a jar function as modules when placed on the class path, what is the point of a separate module path? And even in that case, doesn?t it make sense to treat a class directory as part of the unnamed module in general? That makes this problem go away completely. It doesn?t provide access to third parties, as code would not be distributed as loose classes. - Russ > On Mar 23, 2016, at 10:05 AM, Alan Bateman wrote: > > > > On 23/03/2016 13:02, Russell Gold wrote: >> : >> >> Why does the module concept even need to exist at that point? Seems to me that it is much simpler to treat them as classes on the class path rather than a module. The module status can come in during packaging, no? >> > I'm not sure that I understand your mail. Are you asking why are modules are supported at compile-time? Or are you asking why the compiler doesn't allow packages to be split between the unnamed module and a named module? > > -Alan. From scolebourne at joda.org Wed Mar 23 14:42:58 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 23 Mar 2016 14:42:58 +0000 Subject: modulepath and classpath mixture In-Reply-To: <56F2914C.3030706@oracle.com> References: <56CC57A1.2050109@oracle.com> <56F2440A.7010505@oracle.com> <56F2914C.3030706@oracle.com> Message-ID: On 23 March 2016 at 12:51, Alan Bateman wrote: > If types T1 and T2 have the same defining loader and both types are in the > same package then they are in the same module. T1 can't be module M1 and T2 > in a different module M2. > (I shudder the thought of it being different or attempting to change what > default/package access means after all these years.) I'm not asking for package scope to change meaning. It is Jigsaw that is trying to change its meaning wrt tests. Discussion of white vs black box testing is all very well and good, but its completely impractical. There are tens of thousands of existing projects out there, in open source and private, that rely on tests being in the same package. It is in essence a fundamental part of common approaches to testing. Making it hard to test code in the same package, as seems to be proposed, would be a nightmare for migration. (Many open source projects are for fun in spare time. Who is going to want to refactor all their tests to meet what amounts to an artificial limitation? Not me.) I don't particularly care what the mechanism is for this, but at the requirements level: - there are two modules - main and test - each has its own source tree - each has its own dependencies - each is released separately - each could be hosted on a central repo - the test module needs to be able to contain the same packages as the main module - the test module needs to be able to invoke package-scoped code in the same package in the main module To clarify further consider 4 modules, A, B, A-test and B-test where B depends on A. Module A-test may have a method foo() that uses package scope to access something in A. Module B-test will depend on A-test and rely on foo() to get access to that internal object. One apparent option would appear to be to merge the two modules dynamically at load time. However, they do need to be released and published separately (Note that I view the thread discussion of references to test classes on the classpath as another hack. The release and dependency elements clearly show tests to be modules, just ones with special access.) Stephen From Alan.Bateman at oracle.com Wed Mar 23 15:18:50 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 Mar 2016 15:18:50 +0000 Subject: modulepath and classpath mixture In-Reply-To: References: <56CC57A1.2050109@oracle.com> <56F2440A.7010505@oracle.com> <56F2914C.3030706@oracle.com> Message-ID: <56F2B3DA.402@oracle.com> On 23/03/2016 14:42, Stephen Colebourne wrote: > : > > I don't particularly care what the mechanism is for this, but at the > requirements level: > - there are two modules - main and test > - each has its own source tree > - each has its own dependencies > - each is released separately > - each could be hosted on a central repo > - the test module needs to be able to contain the same packages as the > main module > - the test module needs to be able to invoke package-scoped code in > the same package in the main module > > To clarify further consider 4 modules, A, B, A-test and B-test where B > depends on A. Module A-test may have a method foo() that uses package > scope to access something in A. Module B-test will depend on A-test > and rely on foo() to get access to that internal object. To your list, I would add the ability to make use of testing frameworks like TestNG and JUnit. In any case, and as things currently stand, you've got most of the above. One differences is that the tests are not a separate module, they are instead compiled and run in a way that patches the main module. The second difference is that they don't have their own module declaration, instead the compilation or run augments the dependences with any additional dependences that the tests have. As I said, if they tools makes it easy then I don't think it's too bad. > > (Note that I view the thread discussion of > references to test classes on the classpath as another hack. > Packages can't be split between modules and classpath so there is no support for that. -Alan From Alan.Bateman at oracle.com Wed Mar 23 15:42:23 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 Mar 2016 15:42:23 +0000 Subject: modulepath and classpath mixture In-Reply-To: <85AD85D8-5623-418A-BB19-E3A66350AA59@oracle.com> References: <56CC57A1.2050109@oracle.com> <56F2440A.7010505@oracle.com> <56F2A29F.9050507@oracle.com> <85AD85D8-5623-418A-BB19-E3A66350AA59@oracle.com> Message-ID: <56F2B95F.5020706@oracle.com> On 23/03/2016 14:15, Russell Gold wrote: > Here are my assumptions, which you can correct. > > 1. A jar or classes directory placed on a class path are treated as part of the unnamed module Yes > 2. A jar containing a module-info file is treated as a module when placed on a module path, and restricts access to non-exported packages It also declares what it depends on and maybe services that it uses/provides. Also a JAR file on the module path without a module-info.class is treated as an automatic module. > 3. A jmod file is only usable on the module path. JMOD files are unlikely to be seen by most developers. They are not an executable format. They are mostly for link-time when creating a custom run-time image. > > If a class directory or a jar function as modules when placed on the class path, what is the point of a separate module path? And even in that case, doesn?t it make sense to treat a class directory as part of the unnamed module in general? That makes this problem go away completely. It doesn?t provide access to third parties, as code would not be distributed as loose classes. > You would loose the benefits of the module path and I assume couldn't distinguish automatic modules from regular JAR files. In general I would think this would be just confusing and I don't know what problem it would solve. -Alan From anthony.vanelverdinghe at gmail.com Wed Mar 23 18:26:24 2016 From: anthony.vanelverdinghe at gmail.com (Anthony Vanelverdinghe) Date: Wed, 23 Mar 2016 19:26:24 +0100 Subject: jdeps -check: add section on exports Message-ID: <56F2DFD0.70106@gmail.com> Hi It would be great if jdeps -check would also have a section on exports: this section would list non-exported packages which contain types that are exposed (e.g. through method signatures) by exported packages. Ideally, those appearances should be listed under each package, i.e.: com.foo.impl type X is exposed by member Y of exported type Z Using this, one could easily see whether the package should indeed be exported, or whether a method was mistakenly made public, or ... JDK-8147050 already mentions the similar case of checking whether or not a "requires" ought to be public. What do you think? Should I file an issue for this? Kind regards, Anthony From forax at univ-mlv.fr Wed Mar 23 18:31:54 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 23 Mar 2016 19:31:54 +0100 (CET) Subject: jdeps -check: add section on exports In-Reply-To: <56F2DFD0.70106@gmail.com> References: <56F2DFD0.70106@gmail.com> Message-ID: <1652856612.2441234.1458757914364.JavaMail.zimbra@u-pem.fr> In my opinion, it should be a warning (or even an error) in javac, you should not create a bad module in the first place. R?mi ----- Mail original ----- > De: "Anthony Vanelverdinghe" > ?: jigsaw-dev at openjdk.java.net > Envoy?: Mercredi 23 Mars 2016 19:26:24 > Objet: jdeps -check: add section on exports > > Hi > > It would be great if jdeps -check would also have a section on exports: > this section would list non-exported packages which contain types that > are exposed (e.g. through method signatures) by exported packages. > Ideally, those appearances should be listed under each package, i.e.: > > com.foo.impl > type X is exposed by member Y of exported type Z > > Using this, one could easily see whether the package should indeed be > exported, or whether a method was mistakenly made public, or ... > > JDK-8147050 already mentions the similar case of checking whether or not > a "requires" ought to be public. > > What do you think? Should I file an issue for this? > > Kind regards, > Anthony > From jonathan.gibbons at oracle.com Wed Mar 23 19:58:20 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 23 Mar 2016 12:58:20 -0700 Subject: jdeps -check: add section on exports In-Reply-To: <1652856612.2441234.1458757914364.JavaMail.zimbra@u-pem.fr> References: <56F2DFD0.70106@gmail.com> <1652856612.2441234.1458757914364.JavaMail.zimbra@u-pem.fr> Message-ID: <56F2F55C.4080607@oracle.com> At a minimum, it would be a candidate for a -Xlint check. -- Jon On 03/23/2016 11:31 AM, Remi Forax wrote: > In my opinion, it should be a warning (or even an error) in javac, > you should not create a bad module in the first place. > > R?mi > > ----- Mail original ----- >> De: "Anthony Vanelverdinghe" >> ?: jigsaw-dev at openjdk.java.net >> Envoy?: Mercredi 23 Mars 2016 19:26:24 >> Objet: jdeps -check: add section on exports >> >> Hi >> >> It would be great if jdeps -check would also have a section on exports: >> this section would list non-exported packages which contain types that >> are exposed (e.g. through method signatures) by exported packages. >> Ideally, those appearances should be listed under each package, i.e.: >> >> com.foo.impl >> type X is exposed by member Y of exported type Z >> >> Using this, one could easily see whether the package should indeed be >> exported, or whether a method was mistakenly made public, or ... >> >> JDK-8147050 already mentions the similar case of checking whether or not >> a "requires" ought to be public. >> >> What do you think? Should I file an issue for this? >> >> Kind regards, >> Anthony >> From forax at univ-mlv.fr Wed Mar 23 20:32:31 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 23 Mar 2016 21:32:31 +0100 (CET) Subject: jdeps -check: add section on exports In-Reply-To: <56F2F55C.4080607@oracle.com> References: <56F2DFD0.70106@gmail.com> <1652856612.2441234.1458757914364.JavaMail.zimbra@u-pem.fr> <56F2F55C.4080607@oracle.com> Message-ID: <971408416.2470755.1458765151803.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Jonathan Gibbons" > ?: jigsaw-dev at openjdk.java.net > Envoy?: Mercredi 23 Mars 2016 20:58:20 > Objet: Re: jdeps -check: add section on exports > > At a minimum, it would be a candidate for a -Xlint check. > > -- Jon I think it should be an error that explains that the package containing a not visible class in the signature of a publicly visible method should be either exported or publicly exported in the module info, it will greatly help people to create correct module info. R?mi > > On 03/23/2016 11:31 AM, Remi Forax wrote: > > In my opinion, it should be a warning (or even an error) in javac, > > you should not create a bad module in the first place. > > > > R?mi > > > > ----- Mail original ----- > >> De: "Anthony Vanelverdinghe" > >> ?: jigsaw-dev at openjdk.java.net > >> Envoy?: Mercredi 23 Mars 2016 19:26:24 > >> Objet: jdeps -check: add section on exports > >> > >> Hi > >> > >> It would be great if jdeps -check would also have a section on exports: > >> this section would list non-exported packages which contain types that > >> are exposed (e.g. through method signatures) by exported packages. > >> Ideally, those appearances should be listed under each package, i.e.: > >> > >> com.foo.impl > >> type X is exposed by member Y of exported type Z > >> > >> Using this, one could easily see whether the package should indeed be > >> exported, or whether a method was mistakenly made public, or ... > >> > >> JDK-8147050 already mentions the similar case of checking whether or not > >> a "requires" ought to be public. > >> > >> What do you think? Should I file an issue for this? > >> > >> Kind regards, > >> Anthony > >> > > From naoto.sato at oracle.com Wed Mar 23 22:47:24 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 23 Mar 2016 15:47:24 -0700 Subject: RFR: 8152143: jlink --include-locales should gracefully detect certain user error Message-ID: <56F31CFC.9060403@oracle.com> Hello, Please review the fix to the following bug: https://bugs.openjdk.java.net/browse/JDK-8152143 The fix is located at: http://cr.openjdk.java.net/~naoto/8152143/webrev.02/ Naoto From mandy.chung at oracle.com Wed Mar 23 23:30:51 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 23 Mar 2016 16:30:51 -0700 Subject: RFR: 8152143: jlink --include-locales should gracefully detect certain user error In-Reply-To: <56F31CFC.9060403@oracle.com> References: <56F31CFC.9060403@oracle.com> Message-ID: > On Mar 23, 2016, at 3:47 PM, Naoto Sato wrote: > > Hello, > > Please review the fix to the following bug: > > https://bugs.openjdk.java.net/browse/JDK-8152143 > > The fix is located at: > > http://cr.openjdk.java.net/~naoto/8152143/webrev.02/ Looks okay to me. Mandy From pbenedict at apache.org Thu Mar 24 00:45:41 2016 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 23 Mar 2016 19:45:41 -0500 Subject: Why not get rid of versions? Message-ID: Based on today's discussions, I've been thinking if there is any merit in dumping the notion of Module Version altogether? I am beginning to think it's completely irrelevant to the Module System. Versions are important during builds and for interacting with artifact repositories, but once artifacts are resolved and installed into the JDK as modules, versioning has no more utility. You don't even need Versions to link modules together. The only thing that is actually needed is the Module Name. It looks like to me versions are metadata that belong outside the JDK and classfile format. I think a whole host of problems go away when the Version goes away. The JDK isn't an artifact manager so it doesn't need versions. What do you think? From forax at univ-mlv.fr Thu Mar 24 00:57:12 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 24 Mar 2016 01:57:12 +0100 (CET) Subject: Why not get rid of versions? In-Reply-To: References: Message-ID: <244875632.2528263.1458781032429.JavaMail.zimbra@u-pem.fr> yes, module versions are just metadata, as you said they are not needed by the JDK, but jigsaw also wants to ease the interrop with module systems that does their resolution at runtime, so IMO the JDK has to provide a way to query the version of a module at runtime. R?mi ----- Mail original ----- > De: "Paul Benedict" > ?: "ML OpenJDK Jigsaw Developers" > Envoy?: Jeudi 24 Mars 2016 01:45:41 > Objet: Why not get rid of versions? > > Based on today's discussions, I've been thinking if there is any merit in > dumping the notion of Module Version altogether? I am beginning to think > it's completely irrelevant to the Module System. > > Versions are important during builds and for interacting with artifact > repositories, but once artifacts are resolved and installed into the JDK as > modules, versioning has no more utility. You don't even need Versions to > link modules together. The only thing that is actually needed is the Module > Name. > > It looks like to me versions are metadata that belong outside the JDK and > classfile format. I think a whole host of problems go away when the Version > goes away. The JDK isn't an artifact manager so it doesn't need versions. > > What do you think? > From pbenedict at apache.org Thu Mar 24 02:39:55 2016 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 23 Mar 2016 21:39:55 -0500 Subject: Why not get rid of versions? In-Reply-To: <244875632.2528263.1458781032429.JavaMail.zimbra@u-pem.fr> References: <244875632.2528263.1458781032429.JavaMail.zimbra@u-pem.fr> Message-ID: Remi, where do you see that coming into play? Correct me if wrong, but there is no Version component of Module dependencies. I didn't see a version attached to the "required" statement. On Mar 23, 2016 7:57 PM, "Remi Forax" wrote: > yes, > module versions are just metadata, as you said they are not needed by the > JDK, > but jigsaw also wants to ease the interrop with module systems that does > their resolution at runtime, > so IMO the JDK has to provide a way to query the version of a module at > runtime. > > R?mi > > ----- Mail original ----- > > De: "Paul Benedict" > > ?: "ML OpenJDK Jigsaw Developers" > > Envoy?: Jeudi 24 Mars 2016 01:45:41 > > Objet: Why not get rid of versions? > > > > Based on today's discussions, I've been thinking if there is any merit in > > dumping the notion of Module Version altogether? I am beginning to think > > it's completely irrelevant to the Module System. > > > > Versions are important during builds and for interacting with artifact > > repositories, but once artifacts are resolved and installed into the JDK > as > > modules, versioning has no more utility. You don't even need Versions to > > link modules together. The only thing that is actually needed is the > Module > > Name. > > > > It looks like to me versions are metadata that belong outside the JDK and > > classfile format. I think a whole host of problems go away when the > Version > > goes away. The JDK isn't an artifact manager so it doesn't need versions. > > > > What do you think? > > > From pbenedict at apache.org Thu Mar 24 03:06:08 2016 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 23 Mar 2016 22:06:08 -0500 Subject: Why not get rid of versions? In-Reply-To: <244875632.2528263.1458781032429.JavaMail.zimbra@u-pem.fr> References: <244875632.2528263.1458781032429.JavaMail.zimbra@u-pem.fr> Message-ID: Okay, I see. They get baked into the class file by the build tool. Well, what if they weren't there at all? Every module system today already has external metadata and it is more descriptive than starting it from scratch in the JDK (see #StandardModuleAttributes). All I would ask if there could be given some thought about this, especially if it has a chance to reduce some complexity of the Module specification. On Mar 23, 2016 7:57 PM, "Remi Forax" wrote: > yes, > module versions are just metadata, as you said they are not needed by the > JDK, > but jigsaw also wants to ease the interrop with module systems that does > their resolution at runtime, > so IMO the JDK has to provide a way to query the version of a module at > runtime. > > R?mi > > ----- Mail original ----- > > De: "Paul Benedict" > > ?: "ML OpenJDK Jigsaw Developers" > > Envoy?: Jeudi 24 Mars 2016 01:45:41 > > Objet: Why not get rid of versions? > > > > Based on today's discussions, I've been thinking if there is any merit in > > dumping the notion of Module Version altogether? I am beginning to think > > it's completely irrelevant to the Module System. > > > > Versions are important during builds and for interacting with artifact > > repositories, but once artifacts are resolved and installed into the JDK > as > > modules, versioning has no more utility. You don't even need Versions to > > link modules together. The only thing that is actually needed is the > Module > > Name. > > > > It looks like to me versions are metadata that belong outside the JDK and > > classfile format. I think a whole host of problems go away when the > Version > > goes away. The JDK isn't an artifact manager so it doesn't need versions. > > > > What do you think? > > > From sundararajan.athijegannathan at oracle.com Thu Mar 24 03:25:13 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 24 Mar 2016 08:55:13 +0530 Subject: RFR: 8152143: jlink --include-locales should gracefully detect certain user error In-Reply-To: <56F31CFC.9060403@oracle.com> References: <56F31CFC.9060403@oracle.com> Message-ID: <56F35E19.6030507@oracle.com> +1 -Sundar On 3/24/2016 4:17 AM, Naoto Sato wrote: > Hello, > > Please review the fix to the following bug: > > https://bugs.openjdk.java.net/browse/JDK-8152143 > > The fix is located at: > > http://cr.openjdk.java.net/~naoto/8152143/webrev.02/ > > Naoto From russell.gold at oracle.com Thu Mar 24 03:37:11 2016 From: russell.gold at oracle.com (Russell Gold) Date: Wed, 23 Mar 2016 23:37:11 -0400 Subject: modulepath and classpath mixture In-Reply-To: <56F2B95F.5020706@oracle.com> References: <56CC57A1.2050109@oracle.com> <56F2440A.7010505@oracle.com> <56F2A29F.9050507@oracle.com> <85AD85D8-5623-418A-BB19-E3A66350AA59@oracle.com> <56F2B95F.5020706@oracle.com> Message-ID: > On Mar 23, 2016, at 11:42 AM, Alan Bateman wrote: > > > > On 23/03/2016 14:15, Russell Gold wrote: >> Here are my assumptions, which you can correct. >> >> 1. A jar or classes directory placed on a class path are treated as part of the unnamed module > Yes Then it seems to me that there isn?t actually a problem, here. Build tools can continue to work unchanged, using class paths to allow unit tests to access the code they are testing. The jars are then treated as modules by other builds, which shouldn?t be accessing the module internals in any case. If they really do need to access them, they just put those jars on their class paths - but that?s a hint of poor modularity and testability. > >> 2. A jar containing a module-info file is treated as a module when placed on a module path, and restricts access to non-exported packages > It also declares what it depends on and maybe services that it uses/provides. > > Also a JAR file on the module path without a module-info.class is treated as an automatic module. And what is an automatic module? I didn?t see that in the specs > > >> 3. A jmod file is only usable on the module path. > JMOD files are unlikely to be seen by most developers. They are not an executable format. They are mostly for link-time when creating a custom run-time image. > > >> >> If a class directory or a jar function as modules when placed on the class path, what is the point of a separate module path? And even in that case, doesn?t it make sense to treat a class directory as part of the unnamed module in general? That makes this problem go away completely. It doesn?t provide access to third parties, as code would not be distributed as loose classes. >> > You would loose the benefits of the module path and I assume couldn't distinguish automatic modules from regular JAR files. In general I would think this would be just confusing and I don't know what problem it would solve. It doesn?t, because it was based on my assumptions being wrong :) I was trying to understand the problems Robert and Stephen were raising - and I cannot see the issue. - Russ From Alan.Bateman at oracle.com Thu Mar 24 06:49:25 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 24 Mar 2016 06:49:25 +0000 Subject: RFR: 8152143: jlink --include-locales should gracefully detect certain user error In-Reply-To: <56F31CFC.9060403@oracle.com> References: <56F31CFC.9060403@oracle.com> Message-ID: <56F38DF5.5080805@oracle.com> On 23/03/2016 22:47, Naoto Sato wrote: > Hello, > > Please review the fix to the following bug: > > https://bugs.openjdk.java.net/browse/JDK-8152143 > > The fix is located at: > > http://cr.openjdk.java.net/~naoto/8152143/webrev.02/ One little nit that I didn't notice before is "eg: en,ja,*-IN" where I assume should be "e.g." -Alan From alan.bateman at oracle.com Thu Mar 24 08:51:37 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 24 Mar 2016 08:51:37 +0000 Subject: hg: jigsaw/jake/corba: 3 new changesets Message-ID: <201603240851.u2O8pbxf001109@aojmv0008.oracle.com> Changeset: 2bb92dd44275 Author: alanb Date: 2016-03-17 19:03 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/2bb92dd44275 8142968: Module System implementation Summary: Initial integration of JEP 200, JEP 260, JEP 261, and JEP 282 Reviewed-by: alanb, mchung Contributed-by: alan.bateman at oracle.com, alex.buckley at oracle.com, jonathan.gibbons at oracle.com, karen.kinnear at oracle.com, mandy.chung at oracle.com, mark.reinhold at oracle.com, daniel.fuchs at oracle.com, erik.joelsson at oracle.com ! make/gensrc/Gensrc-java.corba.gmk + src/java.corba/share/classes/module-info.java Changeset: 780d0620add3 Author: lana Date: 2016-03-23 19:33 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/780d0620add3 Added tag jdk-9+111 for changeset 2bb92dd44275 ! .hgtags Changeset: 23039f205de0 Author: alanb Date: 2016-03-24 07:23 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/23039f205de0 Merge ! make/gensrc/Gensrc-java.corba.gmk ! src/java.corba/share/classes/module-info.java From alan.bateman at oracle.com Thu Mar 24 08:51:38 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 24 Mar 2016 08:51:38 +0000 Subject: hg: jigsaw/jake: 3 new changesets Message-ID: <201603240851.u2O8pcRW001155@aojmv0008.oracle.com> Changeset: f900d5afd9c8 Author: alanb Date: 2016-03-17 19:03 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/f900d5afd9c8 8142968: Module System implementation Summary: Initial integration of JEP 200, JEP 260, JEP 261, and JEP 282 Reviewed-by: alanb, mchung, tbell Contributed-by: alan.bateman at oracle.com, alex.buckley at oracle.com, jonathan.gibbons at oracle.com, karen.kinnear at oracle.com, mandy.chung at oracle.com, mark.reinhold at oracle.com, erik.joelsson at oracle.com, chris.hegarty at oracle.com, christian.tornqvist at oracle.com, harold.seigel at oracle.com, igor.ignatyev at oracle.com, james.laskey at oracle.com, jean-francois.denise at oracle.com, sundararajan.athijegannathan at oracle.com ! common/autoconf/basics.m4 ! common/autoconf/boot-jdk.m4 ! common/autoconf/bootcycle-spec.gmk.in + common/autoconf/buildjdk-spec.gmk.in ! common/autoconf/configure.ac ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 ! common/autoconf/platform.m4 ! common/autoconf/source-dirs.m4 ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 ! common/bin/compare.sh ! common/conf/jib-profiles.js - make/CheckModules.gmk ! make/CompileJavaModules.gmk + make/CopyImportModules.gmk + make/CreateBuildJdkCopy.gmk + make/CreateJmods.gmk - make/GenerateModuleDeps.gmk + make/GensrcModuleInfo.gmk ! make/HotspotWrapper.gmk ! make/Images.gmk ! make/Javadoc.gmk ! make/Jprt.gmk ! make/JrtfsJar.gmk ! make/Main.gmk ! make/MainSupport.gmk ! make/StripBinaries.gmk ! make/common/CORE_PKGS.gmk ! make/common/JavaCompilation.gmk ! make/common/MakeBase.gmk ! make/common/Modules.gmk ! make/common/NativeCompilation.gmk ! make/common/SetupJavaCompilers.gmk - modules.xml ! test/lib/sun/hotspot/WhiteBox.java Changeset: 1b6243189056 Author: lana Date: 2016-03-23 19:33 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/1b6243189056 Added tag jdk-9+111 for changeset f900d5afd9c8 ! .hgtags Changeset: f16cff1e7698 Author: alanb Date: 2016-03-24 07:02 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/f16cff1e7698 Merge ! common/autoconf/basics.m4 ! common/autoconf/boot-jdk.m4 ! common/autoconf/bootcycle-spec.gmk.in ! common/autoconf/buildjdk-spec.gmk.in ! common/autoconf/configure.ac ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 ! common/autoconf/platform.m4 ! common/autoconf/source-dirs.m4 ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 ! common/bin/compare.sh ! common/conf/jib-profiles.js ! make/CompileJavaModules.gmk ! make/CopyImportModules.gmk ! make/CreateBuildJdkCopy.gmk ! make/CreateJmods.gmk ! make/GensrcModuleInfo.gmk ! make/HotspotWrapper.gmk ! make/Images.gmk ! make/Javadoc.gmk ! make/Jprt.gmk ! make/JrtfsJar.gmk ! make/Main.gmk ! make/MainSupport.gmk ! make/StripBinaries.gmk ! make/common/CORE_PKGS.gmk ! make/common/JavaCompilation.gmk ! make/common/MakeBase.gmk ! make/common/Modules.gmk ! make/common/NativeCompilation.gmk ! make/common/SetupJavaCompilers.gmk ! test/lib/sun/hotspot/WhiteBox.java From alan.bateman at oracle.com Thu Mar 24 08:51:38 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 24 Mar 2016 08:51:38 +0000 Subject: hg: jigsaw/jake/jaxws: 3 new changesets Message-ID: <201603240851.u2O8pcL9001187@aojmv0008.oracle.com> Changeset: 4d5296e0920a Author: alanb Date: 2016-03-17 19:04 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/4d5296e0920a 8142968: Module System implementation Summary: Initial integration of JEP 200, JEP 260, JEP 261, and JEP 282 Reviewed-by: lancea, mchung Contributed-by: alan.bateman at oracle.com, alex.buckley at oracle.com, jonathan.gibbons at oracle.com, karen.kinnear at oracle.com, mandy.chung at oracle.com, mark.reinhold at oracle.com, miroslav.kos at oracle.com, erik.joelsson at oracle.com ! src/java.activation/share/classes/javax/activation/DataContentHandler.java ! src/java.activation/share/classes/javax/activation/MailcapCommandMap.java + src/java.activation/share/classes/module-info.java + src/java.annotations.common/share/classes/module-info.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/ClassFactory.java + src/java.xml.bind/share/classes/module-info.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/transport/http/server/EndpointImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/util/HandlerAnnotationProcessor.java + src/java.xml.ws/share/classes/module-info.java ! src/jdk.xml.bind/share/classes/com/sun/codemodel/internal/fmt/JStaticJavaFile.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/generator/bean/BeanGenerator.java + src/jdk.xml.bind/share/classes/module-info.java + src/jdk.xml.ws/share/classes/module-info.java Changeset: 21274e7937ba Author: lana Date: 2016-03-23 19:33 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/21274e7937ba Added tag jdk-9+111 for changeset 4d5296e0920a ! .hgtags Changeset: 2863c702ea24 Author: alanb Date: 2016-03-24 07:23 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/2863c702ea24 Merge ! src/java.activation/share/classes/javax/activation/DataContentHandler.java ! src/java.activation/share/classes/javax/activation/MailcapCommandMap.java ! src/java.activation/share/classes/module-info.java ! src/java.annotations.common/share/classes/module-info.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/ClassFactory.java ! 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 Mar 24 08:51:39 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 24 Mar 2016 08:51:39 +0000 Subject: hg: jigsaw/jake/jaxp: 3 new changesets Message-ID: <201603240851.u2O8pdGu001251@aojmv0008.oracle.com> Changeset: 27a3d65e1580 Author: alanb Date: 2016-03-17 19:04 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/27a3d65e1580 8142968: Module System implementation Summary: Initial integration of JEP 200, JEP 260, JEP 261, and JEP 282 Reviewed-by: alanb, mchung, joehw Contributed-by: alan.bateman at oracle.com, alex.buckley at oracle.com, jonathan.gibbons at oracle.com, karen.kinnear at oracle.com, mandy.chung at oracle.com, mark.reinhold at oracle.com, daniel.fuchs at oracle.com, erik.joelsson at oracle.com ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Constants.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/XSLTC.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/compiler/FunctionTable.java + src/java.xml/share/classes/module-info.java + src/jdk.xml.dom/share/classes/module-info.java ! test/TEST.ROOT ! test/javax/xml/jaxp/unittest/TEST.properties Changeset: 0dd23d402170 Author: lana Date: 2016-03-23 19:33 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/0dd23d402170 Added tag jdk-9+111 for changeset 27a3d65e1580 ! .hgtags Changeset: b61878ed500b Author: alanb Date: 2016-03-24 07:19 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/b61878ed500b Merge ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Constants.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/XSLTC.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/compiler/FunctionTable.java ! src/java.xml/share/classes/module-info.java ! test/javax/xml/jaxp/unittest/TEST.properties From alan.bateman at oracle.com Thu Mar 24 08:51:41 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 24 Mar 2016 08:51:41 +0000 Subject: hg: jigsaw/jake/nashorn: 3 new changesets Message-ID: <201603240851.u2O8pfHC001275@aojmv0008.oracle.com> Changeset: 133ea8746b37 Author: alanb Date: 2016-03-17 19:04 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/133ea8746b37 8142968: Module System implementation Summary: Initial integration of JEP 200, JEP 260, JEP 261, and JEP 282 Reviewed-by: mhaupt, hannesw Contributed-by: alan.bateman at oracle.com, alex.buckley at oracle.com, jonathan.gibbons at oracle.com, karen.kinnear at oracle.com, mandy.chung at oracle.com, mark.reinhold at oracle.com, sundararajan.athijegannathan at oracle.com, erik.joelsson at oracle.com ! buildtools/nasgen/build.xml ! buildtools/nasgen/project.properties ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ClassGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/MemberInfo.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/MethodGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInfo.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInfoCollector.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInstrumentor.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/StringConstants.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/Where.java ! make/BuildNashorn.gmk ! make/build-nasgen.xml ! make/build.xml ! make/nbproject/ide-targets.xml ! make/project.properties ! samples/test.js ! src/jdk.dynalink/share/classes/jdk/dynalink/DynamicLinkerFactory.java ! src/jdk.dynalink/share/classes/jdk/dynalink/beans/CallerSensitiveDynamicMethod.java ! src/jdk.dynalink/share/classes/jdk/dynalink/beans/CheckRestrictedPackage.java ! src/jdk.dynalink/share/classes/jdk/dynalink/linker/support/Lookup.java + src/jdk.dynalink/share/classes/module-info.java + src/jdk.scripting.nashorn.shell/share/classes/module-info.java - src/jdk.scripting.nashorn/share/classes/META-INF/MANIFEST.MF - src/jdk.scripting.nashorn/share/classes/META-INF/services/javax.script.ScriptEngineFactory ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/OptimisticTypesPersistence.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/NashornLoader.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptLoader.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Source.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/StructureLoader.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaAdapterClassLoader.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaAdapterServices.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java + src/jdk.scripting.nashorn/share/classes/module-info.java ! test/TEST.ROOT ! test/script/currently-failing/JDK-8055034.js ! test/script/nosecurity/JDK-8044798.js ! test/script/nosecurity/JDK-8044851.js ! test/script/nosecurity/JDK-8067215.js ! test/script/nosecurity/JDK-8078049.js ! test/script/trusted/classfilter_extends.js.EXPECTED ! test/script/trusted/classfilter_mozilla_compat.js.EXPECTED ! test/script/trusted/event_queue.js ! test/script/trusted/optimistic_recompilation.js ! test/src/jdk/nashorn/internal/runtime/doubleconv/test/BignumTest.java ! test/src/jdk/nashorn/internal/runtime/doubleconv/test/DiyFpTest.java ! test/src/jdk/nashorn/internal/runtime/regexp/joni/test/JoniTest.java ! test/src/jdk/nashorn/internal/runtime/regexp/test/JdkRegExpTest.java ! test/src/jdk/nashorn/internal/runtime/test/ConsStringTest.java ! test/src/jdk/nashorn/internal/runtime/test/ContextTest.java ! test/src/jdk/nashorn/internal/runtime/test/ExceptionsNotSerializable.java ! test/src/jdk/nashorn/internal/runtime/test/JDK_8078414_Test.java ! test/src/jdk/nashorn/internal/runtime/test/JSTypeTest.java ! test/src/jdk/nashorn/internal/test/framework/ScriptRunnable.java Changeset: 8e70b6afdbce Author: lana Date: 2016-03-23 19:33 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/8e70b6afdbce Added tag jdk-9+111 for changeset 133ea8746b37 ! .hgtags Changeset: a2cca56da75b Author: alanb Date: 2016-03-24 07:23 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/a2cca56da75b Merge ! .hgtags ! buildtools/nasgen/build.xml ! buildtools/nasgen/project.properties ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/MemberInfo.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/StringConstants.java ! make/BuildNashorn.gmk ! make/build-nasgen.xml ! make/build.xml ! make/project.properties ! samples/test.js ! src/jdk.dynalink/share/classes/jdk/dynalink/DynamicLinkerFactory.java ! src/jdk.dynalink/share/classes/jdk/dynalink/beans/CallerSensitiveDynamicMethod.java ! src/jdk.dynalink/share/classes/jdk/dynalink/beans/CheckRestrictedPackage.java ! src/jdk.dynalink/share/classes/jdk/dynalink/linker/support/Lookup.java ! src/jdk.scripting.nashorn.shell/share/classes/module-info.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/NashornLoader.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptLoader.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Source.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/StructureLoader.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaAdapterClassLoader.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaAdapterServices.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java ! src/jdk.scripting.nashorn/share/classes/module-info.java ! test/script/currently-failing/JDK-8055034.js ! test/script/nosecurity/JDK-8044798.js ! test/script/nosecurity/JDK-8044851.js ! test/script/nosecurity/JDK-8067215.js ! test/script/trusted/event_queue.js ! test/script/trusted/optimistic_recompilation.js ! test/src/jdk/nashorn/internal/runtime/regexp/joni/test/JoniTest.java ! test/src/jdk/nashorn/internal/runtime/regexp/test/JdkRegExpTest.java ! test/src/jdk/nashorn/internal/runtime/test/ConsStringTest.java ! test/src/jdk/nashorn/internal/runtime/test/ContextTest.java ! test/src/jdk/nashorn/internal/runtime/test/ExceptionsNotSerializable.java ! test/src/jdk/nashorn/internal/runtime/test/JSTypeTest.java ! test/src/jdk/nashorn/internal/test/framework/ScriptRunnable.java From alan.bateman at oracle.com Thu Mar 24 08:51:49 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 24 Mar 2016 08:51:49 +0000 Subject: hg: jigsaw/jake/hotspot: 3 new changesets Message-ID: <201603240851.u2O8pnPq001330@aojmv0008.oracle.com> Changeset: c558850fac57 Author: alanb Date: 2016-03-17 19:04 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c558850fac57 8142968: Module System implementation Summary: Initial integration of JEP 200, JEP 260, JEP 261, and JEP 282 Reviewed-by: acorn, ccheung, coleenp, ctornqvi, dholmes, dsimms, gtriantafill, iklam, jiangli, mgronlun, mseledtsov, cjplummer, sspitsyn, stefank, twisti, hseigel, lfoltan, alanb, mchung, dfazunen Contributed-by: alan.bateman at oracle.com, alex.buckley at oracle.com, jonathan.gibbons at oracle.com, karen.kinnear at oracle.com, mandy.chung at oracle.com, mark.reinhold at oracle.com, harold.seigel at oracle.com, lois.foltan at oracle.com, calvin.cheung at oracle.com, christian.tornqvist at oracle.com, erik.joelsson at oracle.com, george.triantafillou at oracle.com, igor.ignatyev at oracle.com, ioi.lam at oracle.com, james.laskey at oracle.com, jean-francois.denise at oracle.com, jiangli.zhou at oracle.com, markus.gronlund at oracle.com, serguei.spitsyn at oracle.com, staffan.larsen at oracle.com, sundararajan.athijegannathan at oracle.com ! make/share/makefiles/mapfile-vers ! make/test/JtregNative.gmk + src/jdk.hotspot.agent/share/classes/module-info.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/ClassLoaderStats.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/FinalizerInfo.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/HeapDumper.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/JInfo.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/JStack.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/ObjectHistogram.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/PMap.java - src/jdk.vm.ci/share/classes/META-INF/services/jdk.vm.ci.hotspot.HotSpotJVMCIBackendFactory + src/jdk.vm.ci/share/classes/module-info.java ! src/os/posix/dtrace/hotspot_jni.d ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoader.hpp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/classfile/classLoaderExt.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/javaClasses.inline.hpp ! src/share/vm/classfile/jimage.hpp ! src/share/vm/classfile/klassFactory.cpp + src/share/vm/classfile/moduleEntry.cpp + src/share/vm/classfile/moduleEntry.hpp + src/share/vm/classfile/modules.cpp + src/share/vm/classfile/modules.hpp + src/share/vm/classfile/packageEntry.cpp + src/share/vm/classfile/packageEntry.hpp ! src/share/vm/classfile/sharedPathsMiscInfo.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/systemDictionaryShared.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/jvmci/jvmciEnv.cpp ! src/share/vm/logging/logTag.hpp ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/filemap.hpp ! src/share/vm/memory/metaspaceShared.cpp ! src/share/vm/memory/metaspaceShared.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/arrayKlass.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/typeArrayKlass.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/precompiled/precompiled.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jni.h ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/jvmti.xml ! src/share/vm/prims/jvmti.xsl ! src/share/vm/prims/jvmtiEnter.xsl ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiEnvBase.hpp ! src/share/vm/prims/jvmtiEventController.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiH.xsl ! src/share/vm/prims/jvmtiLib.xsl ! src/share/vm/prims/jvmtiManageCapabilities.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/jniHandles.cpp ! src/share/vm/runtime/jniHandles.hpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/reflection.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/statSampler.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/services/jmm.h ! src/share/vm/services/management.cpp + src/share/vm/trace/traceBackend.cpp ! src/share/vm/trace/traceDataTypes.hpp ! src/share/vm/trace/traceMacros.hpp ! src/share/vm/trace/tracetypes.xml ! src/share/vm/utilities/dtrace_disabled.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/utf8.cpp ! src/share/vm/utilities/utf8.hpp ! test/TEST.ROOT ! test/compiler/dependencies/MonomorphicObjectCall/TestMonomorphicObjectCall.java ! test/compiler/jsr292/CallSiteDepContextTest.java ! test/compiler/jsr292/NonInlinedCall/Agent.java ! test/compiler/jsr292/NonInlinedCall/GCTest.java ! test/compiler/jsr292/NonInlinedCall/InvokeTest.java - test/compiler/jsr292/NonInlinedCall/NonInlinedReinvoker.java ! test/compiler/jsr292/NonInlinedCall/RedefineTest.java + test/compiler/jsr292/patches/java.base/java/lang/invoke/MethodHandleHelper.java ! test/compiler/jvmci/SecurityRestrictionsTest.java ! test/compiler/jvmci/code/DataPatchTest.java ! test/compiler/jvmci/code/SimpleCodeInstallationTest.java ! test/compiler/jvmci/code/SimpleDebugInfoTest.java ! test/compiler/jvmci/code/VirtualObjectDebugInfoTest.java ! test/compiler/jvmci/common/CTVMUtilities.java - test/compiler/jvmci/common/CompilerToVMHelper.java - test/compiler/jvmci/common/PublicMetaspaceWrapperObject.java + test/compiler/jvmci/common/patches/jdk.vm.ci/jdk/vm/ci/hotspot/CompilerToVMHelper.java + test/compiler/jvmci/common/patches/jdk.vm.ci/jdk/vm/ci/hotspot/MetaAccessWrapper.java + test/compiler/jvmci/common/patches/jdk.vm.ci/jdk/vm/ci/hotspot/PublicMetaspaceWrapperObject.java ! test/compiler/jvmci/compilerToVM/AllocateCompileIdTest.java ! test/compiler/jvmci/compilerToVM/CanInlineMethodTest.java ! test/compiler/jvmci/compilerToVM/CollectCountersTest.java ! test/compiler/jvmci/compilerToVM/DebugOutputTest.java ! test/compiler/jvmci/compilerToVM/DisassembleCodeBlobTest.java ! test/compiler/jvmci/compilerToVM/DoNotInlineOrCompileTest.java ! test/compiler/jvmci/compilerToVM/ExecuteInstalledCodeTest.java ! test/compiler/jvmci/compilerToVM/FindUniqueConcreteMethodTest.java ! test/compiler/jvmci/compilerToVM/GetBytecodeTest.java ! test/compiler/jvmci/compilerToVM/GetClassInitializerTest.java ! test/compiler/jvmci/compilerToVM/GetConstantPoolTest.java ! test/compiler/jvmci/compilerToVM/GetExceptionTableTest.java ! test/compiler/jvmci/compilerToVM/GetImplementorTest.java ! test/compiler/jvmci/compilerToVM/GetLineNumberTableTest.java ! test/compiler/jvmci/compilerToVM/GetLocalVariableTableTest.java ! test/compiler/jvmci/compilerToVM/GetMaxCallTargetOffsetTest.java ! test/compiler/jvmci/compilerToVM/GetNextStackFrameTest.java ! test/compiler/jvmci/compilerToVM/GetResolvedJavaMethodAtSlotTest.java ! test/compiler/jvmci/compilerToVM/GetResolvedJavaMethodTest.java ! test/compiler/jvmci/compilerToVM/GetResolvedJavaTypeTest.java ! test/compiler/jvmci/compilerToVM/GetStackTraceElementTest.java ! test/compiler/jvmci/compilerToVM/GetSymbolTest.java ! test/compiler/jvmci/compilerToVM/GetVtableIndexForInterfaceTest.java ! test/compiler/jvmci/compilerToVM/HasCompiledCodeForOSRTest.java ! test/compiler/jvmci/compilerToVM/HasFinalizableSubclassTest.java ! test/compiler/jvmci/compilerToVM/InitializeConfigurationTest.java ! test/compiler/jvmci/compilerToVM/InvalidateInstalledCodeTest.java ! test/compiler/jvmci/compilerToVM/IsMatureTest.java ! test/compiler/jvmci/compilerToVM/LookupKlassInPoolTest.java ! test/compiler/jvmci/compilerToVM/LookupKlassRefIndexInPoolTest.java ! test/compiler/jvmci/compilerToVM/LookupMethodInPoolTest.java ! test/compiler/jvmci/compilerToVM/LookupNameAndTypeRefIndexInPoolTest.java ! test/compiler/jvmci/compilerToVM/LookupNameInPoolTest.java ! test/compiler/jvmci/compilerToVM/LookupSignatureInPoolTest.java ! test/compiler/jvmci/compilerToVM/LookupTypeTest.java ! test/compiler/jvmci/compilerToVM/MaterializeVirtualObjectTest.java ! test/compiler/jvmci/compilerToVM/MethodIsIgnoredBySecurityStackWalkTest.java ! test/compiler/jvmci/compilerToVM/ReadUncompressedOopTest.java ! test/compiler/jvmci/compilerToVM/ReprofileTest.java ! test/compiler/jvmci/compilerToVM/ResolveConstantInPoolTest.java ! test/compiler/jvmci/compilerToVM/ResolveFieldInPoolTest.java ! test/compiler/jvmci/compilerToVM/ResolveMethodTest.java ! test/compiler/jvmci/compilerToVM/ResolvePossiblyCachedConstantInPoolTest.java ! test/compiler/jvmci/compilerToVM/ResolveTypeInPoolTest.java ! test/compiler/jvmci/compilerToVM/ShouldDebugNonSafepointsTest.java ! test/compiler/jvmci/compilerToVM/ShouldInlineMethodTest.java ! test/compiler/jvmci/events/JvmciCreateMetaAccessContextTest.java ! test/compiler/jvmci/events/JvmciNotifyInstallEventTest.java - test/compiler/jvmci/events/MetaAccessWrapper.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/ConstantTest.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/RedefineClassTest.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestConstantReflectionProvider.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestJavaField.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestJavaMethod.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestJavaType.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestMetaAccessProvider.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaField.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaMethod.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java ! test/compiler/stable/StableConfiguration.java ! test/compiler/stable/TestStableBoolean.java ! test/compiler/stable/TestStableByte.java ! test/compiler/stable/TestStableChar.java ! test/compiler/stable/TestStableDouble.java ! test/compiler/stable/TestStableFloat.java ! test/compiler/stable/TestStableInt.java ! test/compiler/stable/TestStableLong.java ! test/compiler/stable/TestStableMemoryBarrier.java ! test/compiler/stable/TestStableObject.java ! test/compiler/stable/TestStableShort.java ! test/compiler/unsafe/UnsafeGetConstantField.java ! test/gc/TestSmallHeap.java + test/gc/metaspace/PerfCounter.java + test/gc/metaspace/PerfCounters.java ! test/runtime/BadObjectClass/BootstrapRedefine.java - test/runtime/BadObjectClass/Object.java + test/runtime/BootClassAppendProp/BootClassPathAppend.java + test/runtime/BootClassAppendProp/BootClassPathAppendProp.java + test/runtime/BootClassAppendProp/SunBootClassPath.java ! test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java ! test/runtime/CommandLine/OptionsValidation/TestOptionsWithRangesDynamic.java ! test/runtime/SharedArchiveFile/BasicJarBuilder.java + test/runtime/SharedArchiveFile/BootAppendTests.java + test/runtime/SharedArchiveFile/LoadClass.java ! test/runtime/SharedArchiveFile/PrintSharedArchiveAndExit.java ! test/runtime/SharedArchiveFile/SharedStrings.java + test/runtime/SharedArchiveFile/javax/sound/sampled/MyClass.jasm + test/runtime/SharedArchiveFile/nonjdk/myPackage/MyClass.java + test/runtime/SharedArchiveFile/org/omg/CORBA/Context.jasm + test/runtime/getSysPackage/GetSysPkgTest.java + test/runtime/logging/ModulesTest.java + test/runtime/modules/AccModuleTest.java + test/runtime/modules/AccessCheck/CheckRead.java + test/runtime/modules/AccessCheck/DiffCL_CheckRead.java + test/runtime/modules/AccessCheck/DiffCL_ExpQualOther.java + test/runtime/modules/AccessCheck/DiffCL_ExpQualToM1.java + test/runtime/modules/AccessCheck/DiffCL_ExpUnqual.java + test/runtime/modules/AccessCheck/DiffCL_PkgNotExp.java + test/runtime/modules/AccessCheck/DiffCL_Umod.java + test/runtime/modules/AccessCheck/DiffCL_UmodUpkg.java + test/runtime/modules/AccessCheck/ExpQualOther.java + test/runtime/modules/AccessCheck/ExpQualToM1.java + test/runtime/modules/AccessCheck/ExpUnqual.java + test/runtime/modules/AccessCheck/ExportAllUnnamed.java + test/runtime/modules/AccessCheck/ModuleLibrary.java + test/runtime/modules/AccessCheck/PkgNotExp.java + test/runtime/modules/AccessCheck/Umod.java + test/runtime/modules/AccessCheck/UmodDiffCL_ExpQualOther.java + test/runtime/modules/AccessCheck/UmodDiffCL_ExpUnqual.java + test/runtime/modules/AccessCheck/UmodDiffCL_PkgNotExp.java + test/runtime/modules/AccessCheck/UmodDiffCL_Umod.java + test/runtime/modules/AccessCheck/UmodDiffCL_UmodUpkg.java + test/runtime/modules/AccessCheck/UmodUPkg.java + test/runtime/modules/AccessCheck/UmodUpkgDiffCL_ExpQualOther.java + test/runtime/modules/AccessCheck/UmodUpkgDiffCL_NotExp.java + test/runtime/modules/AccessCheck/UmodUpkgDiffCL_Umod.java + test/runtime/modules/AccessCheck/UmodUpkg_ExpQualOther.java + test/runtime/modules/AccessCheck/UmodUpkg_NotExp.java + test/runtime/modules/AccessCheck/UmodUpkg_Umod.java + test/runtime/modules/AccessCheck/Umod_ExpQualOther.java + test/runtime/modules/AccessCheck/Umod_ExpUnqual.java + test/runtime/modules/AccessCheck/Umod_PkgNotExp.java + test/runtime/modules/AccessCheck/Umod_UmodUpkg.java + test/runtime/modules/AccessCheck/c4.java + test/runtime/modules/AccessCheck/c5.java + test/runtime/modules/AccessCheck/myloaders/MyDiffClassLoader.java + test/runtime/modules/AccessCheck/myloaders/MySameClassLoader.java + test/runtime/modules/AccessCheck/p1/c1.java + test/runtime/modules/AccessCheck/p1/c1Loose.java + test/runtime/modules/AccessCheck/p1/c1ReadEdge.java + test/runtime/modules/AccessCheck/p1/c1ReadEdgeDiffLoader.java + test/runtime/modules/AccessCheck/p2/c2.java + test/runtime/modules/AccessCheck/p3/c3.jcod + test/runtime/modules/AccessCheck/p3/c3ReadEdge.jcod + test/runtime/modules/AccessCheck/p3/c3ReadEdgeDiffLoader.jcod + test/runtime/modules/AccessCheck/p6/c6.java + test/runtime/modules/AccessCheckAllUnnamed.java + test/runtime/modules/AccessCheckExp.java + test/runtime/modules/AccessCheckJavaBase.java + test/runtime/modules/AccessCheckRead.java + test/runtime/modules/AccessCheckSuper.java + test/runtime/modules/AccessCheckUnnamed.java + test/runtime/modules/AccessCheckWorks.java + test/runtime/modules/CCE_module_msg.java + test/runtime/modules/ExportTwice.java + test/runtime/modules/JVMAddModuleExportToAllUnnamed.java + test/runtime/modules/JVMAddModuleExports.java + test/runtime/modules/JVMAddModuleExportsToAll.java + test/runtime/modules/JVMAddModulePackage.java + test/runtime/modules/JVMAddReadsModule.java + test/runtime/modules/JVMCanReadModule.java + test/runtime/modules/JVMDefineModule.java + test/runtime/modules/JVMGetModuleByPkgName.java + test/runtime/modules/JVMIsExportedToModule.java + test/runtime/modules/LoadUnloadModuleStress.java + test/runtime/modules/ModuleHelper.java + test/runtime/modules/Visibility/XbootcpNoVisibility.java + test/runtime/modules/Visibility/XbootcpVisibility.java + test/runtime/modules/Visibility/XpatchVisibility.java + test/runtime/modules/Xpatch/Xpatch2Dirs.java + test/runtime/modules/Xpatch/Xpatch2DirsMain.java + test/runtime/modules/Xpatch/XpatchMain.java + test/runtime/modules/Xpatch/XpatchTest.java + test/runtime/modules/Xpatch/XpatchTraceCL.java + test/runtime/modules/XpatchCDS.java + test/runtime/modules/acc_module.jcod + test/runtime/modules/getModuleJNI/GetModule.java + test/runtime/modules/getModuleJNI/libGetModule.c + test/runtime/modules/java.base/java/lang/reflect/ModuleHelper.java + test/runtime/modules/p1/c1.java + test/runtime/modules/p2/c2.java + test/runtime/modules/p3/c3.java ! test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java ! test/testlibrary/ClassFileInstaller.java ! test/testlibrary/jdk/test/lib/InMemoryJavaCompiler.java - test/testlibrary/jdk/test/lib/PerfCounter.java - test/testlibrary/jdk/test/lib/PerfCounters.java ! test/testlibrary/jdk/test/lib/cli/CommandLineOptionTest.java + test/testlibrary/whitebox/sun/hotspot/WhiteBox.java Changeset: cf67bfa444b1 Author: lana Date: 2016-03-23 19:33 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/cf67bfa444b1 Added tag jdk-9+111 for changeset c558850fac57 ! .hgtags Changeset: 15ce3a603c19 Author: alanb Date: 2016-03-24 07:23 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/15ce3a603c19 Merge ! .hgtags ! make/share/makefiles/mapfile-vers ! make/test/JtregNative.gmk ! src/jdk.hotspot.agent/share/classes/module-info.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/ClassLoaderStats.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/FinalizerInfo.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/HeapDumper.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/JInfo.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/JStack.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/ObjectHistogram.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/PMap.java ! src/jdk.vm.ci/share/classes/module-info.java ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoader.hpp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/classfile/classLoaderExt.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/javaClasses.inline.hpp ! src/share/vm/classfile/jimage.hpp ! src/share/vm/classfile/klassFactory.cpp ! src/share/vm/classfile/moduleEntry.cpp ! src/share/vm/classfile/moduleEntry.hpp ! src/share/vm/classfile/modules.cpp ! src/share/vm/classfile/modules.hpp ! src/share/vm/classfile/packageEntry.cpp ! src/share/vm/classfile/packageEntry.hpp ! src/share/vm/classfile/sharedPathsMiscInfo.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/systemDictionaryShared.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/jvmci/jvmciEnv.cpp ! src/share/vm/logging/logTag.hpp ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/filemap.hpp ! src/share/vm/memory/metaspaceShared.cpp ! src/share/vm/memory/metaspaceShared.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/arrayKlass.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/typeArrayKlass.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/precompiled/precompiled.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jni.h ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/jvmti.xml ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiEnvBase.hpp ! src/share/vm/prims/jvmtiEventController.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiH.xsl ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/jniHandles.cpp ! src/share/vm/runtime/jniHandles.hpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/reflection.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/statSampler.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/services/jmm.h ! src/share/vm/services/management.cpp ! src/share/vm/trace/traceBackend.cpp ! src/share/vm/trace/traceDataTypes.hpp ! src/share/vm/trace/traceMacros.hpp ! src/share/vm/trace/tracetypes.xml ! src/share/vm/utilities/dtrace_disabled.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/utf8.cpp ! src/share/vm/utilities/utf8.hpp ! test/compiler/dependencies/MonomorphicObjectCall/TestMonomorphicObjectCall.java ! test/compiler/jsr292/CallSiteDepContextTest.java ! test/compiler/jsr292/NonInlinedCall/GCTest.java ! test/compiler/jsr292/NonInlinedCall/InvokeTest.java ! test/compiler/jsr292/NonInlinedCall/RedefineTest.java ! test/compiler/jvmci/SecurityRestrictionsTest.java ! test/compiler/jvmci/code/DataPatchTest.java ! test/compiler/jvmci/code/SimpleCodeInstallationTest.java ! test/compiler/jvmci/code/SimpleDebugInfoTest.java ! test/compiler/jvmci/code/VirtualObjectDebugInfoTest.java ! test/compiler/jvmci/common/patches/jdk.vm.ci/jdk/vm/ci/hotspot/CompilerToVMHelper.java ! test/compiler/jvmci/common/patches/jdk.vm.ci/jdk/vm/ci/hotspot/MetaAccessWrapper.java ! test/compiler/jvmci/common/patches/jdk.vm.ci/jdk/vm/ci/hotspot/PublicMetaspaceWrapperObject.java ! test/compiler/jvmci/compilerToVM/AllocateCompileIdTest.java ! test/compiler/jvmci/compilerToVM/CanInlineMethodTest.java ! test/compiler/jvmci/compilerToVM/CollectCountersTest.java ! test/compiler/jvmci/compilerToVM/DebugOutputTest.java ! test/compiler/jvmci/compilerToVM/DoNotInlineOrCompileTest.java ! test/compiler/jvmci/compilerToVM/ExecuteInstalledCodeTest.java ! test/compiler/jvmci/compilerToVM/FindUniqueConcreteMethodTest.java ! test/compiler/jvmci/compilerToVM/GetBytecodeTest.java ! test/compiler/jvmci/compilerToVM/GetClassInitializerTest.java ! test/compiler/jvmci/compilerToVM/GetConstantPoolTest.java ! test/compiler/jvmci/compilerToVM/GetExceptionTableTest.java ! test/compiler/jvmci/compilerToVM/GetImplementorTest.java ! test/compiler/jvmci/compilerToVM/GetLineNumberTableTest.java ! test/compiler/jvmci/compilerToVM/GetLocalVariableTableTest.java ! test/compiler/jvmci/compilerToVM/GetMaxCallTargetOffsetTest.java ! test/compiler/jvmci/compilerToVM/GetNextStackFrameTest.java ! test/compiler/jvmci/compilerToVM/GetResolvedJavaMethodAtSlotTest.java ! test/compiler/jvmci/compilerToVM/GetResolvedJavaMethodTest.java ! test/compiler/jvmci/compilerToVM/GetResolvedJavaTypeTest.java ! test/compiler/jvmci/compilerToVM/GetStackTraceElementTest.java ! test/compiler/jvmci/compilerToVM/GetSymbolTest.java ! test/compiler/jvmci/compilerToVM/GetVtableIndexForInterfaceTest.java ! test/compiler/jvmci/compilerToVM/HasCompiledCodeForOSRTest.java ! test/compiler/jvmci/compilerToVM/HasFinalizableSubclassTest.java ! test/compiler/jvmci/compilerToVM/InitializeConfigurationTest.java ! test/compiler/jvmci/compilerToVM/IsMatureTest.java ! test/compiler/jvmci/compilerToVM/LookupKlassInPoolTest.java ! test/compiler/jvmci/compilerToVM/LookupTypeTest.java ! test/compiler/jvmci/compilerToVM/MethodIsIgnoredBySecurityStackWalkTest.java ! test/compiler/jvmci/compilerToVM/ReadUncompressedOopTest.java ! test/compiler/jvmci/compilerToVM/ReprofileTest.java ! test/compiler/jvmci/compilerToVM/ResolveConstantInPoolTest.java ! test/compiler/jvmci/compilerToVM/ResolveMethodTest.java ! test/compiler/jvmci/compilerToVM/ResolveTypeInPoolTest.java ! test/compiler/jvmci/compilerToVM/ShouldDebugNonSafepointsTest.java ! test/compiler/jvmci/compilerToVM/ShouldInlineMethodTest.java ! test/compiler/jvmci/events/JvmciCreateMetaAccessContextTest.java ! test/compiler/jvmci/events/JvmciNotifyInstallEventTest.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/ConstantTest.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/RedefineClassTest.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestConstantReflectionProvider.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestJavaField.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestJavaMethod.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestJavaType.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestMetaAccessProvider.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaField.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaMethod.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java ! test/compiler/stable/StableConfiguration.java ! test/compiler/stable/TestStableBoolean.java ! test/compiler/stable/TestStableByte.java ! test/compiler/stable/TestStableChar.java ! test/compiler/stable/TestStableDouble.java ! test/compiler/stable/TestStableFloat.java ! test/compiler/stable/TestStableInt.java ! test/compiler/stable/TestStableLong.java ! test/compiler/stable/TestStableMemoryBarrier.java ! test/compiler/stable/TestStableObject.java ! test/compiler/stable/TestStableShort.java ! test/compiler/unsafe/UnsafeGetConstantField.java ! test/gc/TestSmallHeap.java ! test/runtime/BadObjectClass/BootstrapRedefine.java ! test/runtime/BootClassAppendProp/BootClassPathAppendProp.java ! test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java ! test/runtime/SharedArchiveFile/BasicJarBuilder.java ! test/runtime/SharedArchiveFile/BootAppendTests.java ! test/runtime/SharedArchiveFile/PrintSharedArchiveAndExit.java ! test/runtime/SharedArchiveFile/SharedStrings.java ! test/runtime/getSysPackage/GetSysPkgTest.java ! test/runtime/logging/ModulesTest.java ! test/runtime/modules/AccModuleTest.java ! test/runtime/modules/AccessCheck/CheckRead.java ! test/runtime/modules/AccessCheck/DiffCL_CheckRead.java ! test/runtime/modules/AccessCheck/DiffCL_ExpQualOther.java ! test/runtime/modules/AccessCheck/DiffCL_ExpQualToM1.java ! test/runtime/modules/AccessCheck/DiffCL_ExpUnqual.java ! test/runtime/modules/AccessCheck/DiffCL_PkgNotExp.java ! test/runtime/modules/AccessCheck/DiffCL_Umod.java ! test/runtime/modules/AccessCheck/DiffCL_UmodUpkg.java ! test/runtime/modules/AccessCheck/ExpQualOther.java ! test/runtime/modules/AccessCheck/ExpQualToM1.java ! test/runtime/modules/AccessCheck/ExpUnqual.java ! test/runtime/modules/AccessCheck/ExportAllUnnamed.java ! test/runtime/modules/AccessCheck/ModuleLibrary.java ! test/runtime/modules/AccessCheck/PkgNotExp.java ! test/runtime/modules/AccessCheck/Umod.java ! test/runtime/modules/AccessCheck/UmodDiffCL_ExpQualOther.java ! test/runtime/modules/AccessCheck/UmodDiffCL_ExpUnqual.java ! test/runtime/modules/AccessCheck/UmodDiffCL_PkgNotExp.java ! test/runtime/modules/AccessCheck/UmodDiffCL_Umod.java ! test/runtime/modules/AccessCheck/UmodDiffCL_UmodUpkg.java ! test/runtime/modules/AccessCheck/UmodUPkg.java ! test/runtime/modules/AccessCheck/UmodUpkgDiffCL_ExpQualOther.java ! test/runtime/modules/AccessCheck/UmodUpkgDiffCL_NotExp.java ! test/runtime/modules/AccessCheck/UmodUpkgDiffCL_Umod.java ! test/runtime/modules/AccessCheck/UmodUpkg_ExpQualOther.java ! test/runtime/modules/AccessCheck/UmodUpkg_NotExp.java ! test/runtime/modules/AccessCheck/UmodUpkg_Umod.java ! test/runtime/modules/AccessCheck/Umod_ExpQualOther.java ! test/runtime/modules/AccessCheck/Umod_ExpUnqual.java ! test/runtime/modules/AccessCheck/Umod_PkgNotExp.java ! test/runtime/modules/AccessCheck/Umod_UmodUpkg.java ! test/runtime/modules/AccessCheck/myloaders/MyDiffClassLoader.java ! test/runtime/modules/AccessCheck/myloaders/MySameClassLoader.java ! test/runtime/modules/AccessCheck/p1/c1Loose.java ! test/runtime/modules/AccessCheckAllUnnamed.java ! test/runtime/modules/AccessCheckExp.java ! test/runtime/modules/AccessCheckRead.java ! test/runtime/modules/AccessCheckSuper.java ! test/runtime/modules/AccessCheckUnnamed.java ! test/runtime/modules/AccessCheckWorks.java ! test/runtime/modules/ExportTwice.java ! test/runtime/modules/JVMAddModuleExportToAllUnnamed.java ! test/runtime/modules/JVMAddModuleExports.java ! test/runtime/modules/JVMAddModuleExportsToAll.java ! test/runtime/modules/JVMAddModulePackage.java ! test/runtime/modules/JVMAddReadsModule.java ! test/runtime/modules/JVMCanReadModule.java ! test/runtime/modules/JVMDefineModule.java ! test/runtime/modules/JVMIsExportedToModule.java ! test/runtime/modules/LoadUnloadModuleStress.java ! test/runtime/modules/ModuleHelper.java ! test/runtime/modules/Visibility/XbootcpNoVisibility.java ! test/runtime/modules/Visibility/XbootcpVisibility.java ! test/runtime/modules/Xpatch/Xpatch2Dirs.java ! test/runtime/modules/Xpatch/XpatchMain.java ! test/runtime/modules/Xpatch/XpatchTest.java ! test/runtime/modules/Xpatch/XpatchTraceCL.java ! test/runtime/modules/XpatchCDS.java ! test/runtime/modules/getModuleJNI/GetModule.java ! test/runtime/modules/getModuleJNI/libGetModule.c ! test/runtime/modules/java.base/java/lang/reflect/ModuleHelper.java ! test/runtime/modules/p1/c1.java ! test/runtime/modules/p2/c2.java ! test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java ! test/testlibrary/ClassFileInstaller.java ! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java From alan.bateman at oracle.com Thu Mar 24 08:51:50 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 24 Mar 2016 08:51:50 +0000 Subject: hg: jigsaw/jake/langtools: 3 new changesets Message-ID: <201603240851.u2O8ppfa001334@aojmv0008.oracle.com> Changeset: 9adfb22ff08f Author: alanb Date: 2016-03-17 19:04 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/9adfb22ff08f 8142968: Module System implementation Summary: Initial integration of JEP 200, JEP 260, JEP 261, and JEP 282 Reviewed-by: jjg, jlahoda, vromero, mcimadamore, bpatel, ksrini, darcy, anazarov, dfuchs Contributed-by: alan.bateman at oracle.com, alex.buckley at oracle.com, jonathan.gibbons at oracle.com, karen.kinnear at oracle.com, mandy.chung at oracle.com, mark.reinhold at oracle.com, jan.lahoda at oracle.com, vicente.romero at oracle.com, andreas.lundblad at oracle.com, andrey.x.nazarov at oracle.com, chris.hegarty at oracle.com, erik.joelsson at oracle.com, kumar.x.srinivasan at oracle.com, sundararajan.athijegannathan at oracle.com ! make/CompileInterim.gmk ! make/build.properties ! make/build.xml ! make/gendata/Gendata-jdk.compiler.gmk ! make/intellij/ant.xml ! make/intellij/build.xml ! make/intellij/langtools.iml ! make/intellij/src/idea/LangtoolsIdeaAntLogger.java ! make/intellij/workspace.xml ! make/launcher.sh-template ! make/netbeans/langtools/build.xml ! make/netbeans/langtools/nbproject/project.xml ! make/tools/anttasks/SelectToolTask.java ! make/tools/crules/CodingRulesAnalyzerPlugin.java ! make/tools/propertiesparser/parser/MessageType.java ! src/java.compiler/share/classes/javax/lang/model/element/Element.java ! src/java.compiler/share/classes/javax/lang/model/element/ElementKind.java ! src/java.compiler/share/classes/javax/lang/model/element/ElementVisitor.java + 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/javax/lang/model/type/TypeKind.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor6.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor9.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementFilter.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor9.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementScanner9.java ! src/java.compiler/share/classes/javax/lang/model/util/Elements.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor9.java ! src/java.compiler/share/classes/javax/tools/ForwardingJavaFileManager.java ! src/java.compiler/share/classes/javax/tools/JavaFileManager.java ! src/java.compiler/share/classes/javax/tools/StandardLocation.java ! src/java.compiler/share/classes/javax/tools/ToolProvider.java + src/java.compiler/share/classes/module-info.java + src/jdk.compiler/share/classes/com/sun/source/tree/DirectiveTree.java + src/jdk.compiler/share/classes/com/sun/source/tree/ExportsTree.java + src/jdk.compiler/share/classes/com/sun/source/tree/ModuleTree.java + src/jdk.compiler/share/classes/com/sun/source/tree/ProvidesTree.java + src/jdk.compiler/share/classes/com/sun/source/tree/RequiresTree.java ! src/jdk.compiler/share/classes/com/sun/source/tree/Tree.java ! src/jdk.compiler/share/classes/com/sun/source/tree/TreeVisitor.java + src/jdk.compiler/share/classes/com/sun/source/tree/UsesTree.java ! src/jdk.compiler/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java ! src/jdk.compiler/share/classes/com/sun/tools/doclint/DocLint.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/BasicJavacTask.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/ClientCodeWrapper.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTool.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/ClassFinder.java + src/jdk.compiler/share/classes/com/sun/tools/javac/code/Directive.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Kinds.java + src/jdk.compiler/share/classes/com/sun/tools/javac/code/ModuleFinder.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Printer.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeTag.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java + src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/BaseFileManager.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/JRTIndex.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java + src/jdk.compiler/share/classes/com/sun/tools/javac/file/ModuleNameReader.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassFile.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/JNIWriter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Arguments.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Main.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/model/JavacElements.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties - src/jdk.compiler/share/classes/com/sun/tools/javac/sym/CreateSymbols.java - src/jdk.compiler/share/classes/com/sun/tools/javac/sym/Profiles.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeScanner.java + src/jdk.compiler/share/classes/com/sun/tools/javac/util/ModuleHelper.java + src/jdk.compiler/share/classes/com/sun/tools/javac/util/ModuleWrappers.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Name.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java - src/jdk.compiler/share/classes/com/sun/tools/javac/util/ServiceLoader.java ! src/jdk.compiler/share/classes/com/sun/tools/javah/JavahTask.java ! src/jdk.compiler/share/classes/com/sun/tools/javah/resources/l10n.properties ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/PubApiExtractor.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/Source.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/SjavacImpl.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/SmartFileManager.java + src/jdk.compiler/share/classes/module-info.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/AbstractPackageIndexWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/AbstractProfileIndexWriter.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfileIndexFrameWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageFrameWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageIndexFrameWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageWriterImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfileWriterImpl.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/WriterFactoryImpl.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlConstants.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlStyle.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/ProfilePackageSummaryWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/ProfileSummaryWriter.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/WriterFactory.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractBuilder.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/builders/BuilderFactory.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ProfilePackageSummaryBuilder.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ProfileSummaryBuilder.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclet.xml ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets.properties ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFileFactory.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPaths.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/util/MetaKeywords.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/util/StandardDocFileFactory.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/util/Utils.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/util/VisibleMemberMap.java ! src/jdk.javadoc/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/jdk.javadoc/share/classes/com/sun/tools/javadoc/DocEnv.java ! src/jdk.javadoc/share/classes/com/sun/tools/javadoc/DocletInvoker.java ! src/jdk.javadoc/share/classes/com/sun/tools/javadoc/JavadocTool.java ! src/jdk.javadoc/share/classes/com/sun/tools/javadoc/PackageDocImpl.java ! src/jdk.javadoc/share/classes/com/sun/tools/javadoc/Start.java ! src/jdk.javadoc/share/classes/com/sun/tools/javadoc/ToolOption.java ! src/jdk.javadoc/share/classes/com/sun/tools/javadoc/resources/javadoc.properties + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractModuleIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractPackageIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConfigurationImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleIndexFrameWriter.java + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModulePackageIndexFrameWriter.java + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageIndexFrameWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/WriterFactoryImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlConstants.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/AbstractDoclet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/Configuration.java + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/ModuleSummaryWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/WorkArounds.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/WriterFactory.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/BuilderFactory.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ConstantsSummaryBuilder.java + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ModuleSummaryBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclet.xml ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletManager.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocPaths.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/MetaKeywords.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/StandardDocFileFactory.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/DocEnv.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/JavadocClassFinder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/JavadocTool.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ToolOption.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/resources/javadoc.properties + src/jdk.javadoc/share/classes/module-info.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/AccessFlags.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/Attribute.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/ClassWriter.java + src/jdk.jdeps/share/classes/com/sun/tools/classfile/ConcealedPackages_attribute.java + src/jdk.jdeps/share/classes/com/sun/tools/classfile/Hashes_attribute.java + src/jdk.jdeps/share/classes/com/sun/tools/classfile/MainClass_attribute.java + src/jdk.jdeps/share/classes/com/sun/tools/classfile/Module_attribute.java + src/jdk.jdeps/share/classes/com/sun/tools/classfile/TargetPlatform_attribute.java + src/jdk.jdeps/share/classes/com/sun/tools/classfile/Version_attribute.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/JavapTask.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/Options.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap.properties ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Analyzer.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Archive.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ClassFileReader.java + src/jdk.jdeps/share/classes/com/sun/tools/jdeps/DependencyFinder.java + src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsFilter.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsTask.java + src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsWriter.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Module.java + src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleAnalyzer.java + src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleInfoBuilder.java + src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModulePaths.java - src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModulesXmlReader.java - src/jdk.jdeps/share/classes/com/sun/tools/jdeps/PlatformClassPath.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Profile.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps.properties ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdkinternals.properties + src/jdk.jdeps/share/classes/module-info.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/remote/RemoteAgent.java ! src/jdk.jshell/share/classes/jdk/jshell/ExecutionControl.java ! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java ! src/jdk.jshell/share/classes/jdk/jshell/TaskFactory.java + src/jdk.jshell/share/classes/module-info.java ! test/Makefile ! test/ProblemList.txt ! test/TEST.ROOT ! test/com/sun/javadoc/testCustomTag/TestCustomTag.java ! test/com/sun/javadoc/testCustomTag/taglets/CustomTag.java ! test/com/sun/javadoc/testHtmlVersion/TestHtmlVersion.java ! test/com/sun/javadoc/testLinkOption/TestLinkOption.java + test/com/sun/javadoc/testLinkOption/extra/StringBuilder.java - test/com/sun/javadoc/testLinkOption/java/lang/StringBuilderChild.java + test/com/sun/javadoc/testLinkOption/jdk/package-list + test/com/sun/javadoc/testLinkOption/mylib/lang/StringBuilderChild.java - test/com/sun/javadoc/testLinkOption/package-list ! test/com/sun/javadoc/testNavigation/TestNavigation.java ! test/com/sun/javadoc/testNestedInlineTag/TestNestedInlineTag.java ! test/com/sun/javadoc/testNestedInlineTag/testtaglets/BoldTaglet.java ! test/com/sun/javadoc/testNestedInlineTag/testtaglets/GreenTaglet.java ! test/com/sun/javadoc/testNestedInlineTag/testtaglets/UnderlineTaglet.java - test/com/sun/javadoc/testProfiles/TestProfiles.java - test/com/sun/javadoc/testProfiles/TestProfilesConfiguration.java - test/com/sun/javadoc/testProfiles/pkg1/Class1Pkg1.java - test/com/sun/javadoc/testProfiles/pkg1/Class2Pkg1.java - test/com/sun/javadoc/testProfiles/pkg1/Class3Pkg1.java - test/com/sun/javadoc/testProfiles/pkg1/Interface1Pkg1.java - test/com/sun/javadoc/testProfiles/pkg2/Anno1Pkg2.java - test/com/sun/javadoc/testProfiles/pkg2/Anno2Pkg2.java - test/com/sun/javadoc/testProfiles/pkg2/Class1Pkg2.java - test/com/sun/javadoc/testProfiles/pkg2/ClassError.java - test/com/sun/javadoc/testProfiles/pkg2/ClassException.java - test/com/sun/javadoc/testProfiles/pkg3/Class1Pkg3.java - test/com/sun/javadoc/testProfiles/pkg3/Class2Pkg3.java - test/com/sun/javadoc/testProfiles/pkg3/Interface1Pkg3.java - test/com/sun/javadoc/testProfiles/pkg4/Anno1Pkg4.java - test/com/sun/javadoc/testProfiles/pkg4/Class1Pkg4.java - test/com/sun/javadoc/testProfiles/pkg5/Class1Pkg5.java - test/com/sun/javadoc/testProfiles/pkg5/Interface1Pkg5.java - test/com/sun/javadoc/testProfiles/pkgDeprecated/Class1PkgDeprecated.java - test/com/sun/javadoc/testProfiles/pkgDeprecated/package-info.java - test/com/sun/javadoc/testProfiles/profile-rtjar-includes-nopkgs.txt - test/com/sun/javadoc/testProfiles/profile-rtjar-includes.txt ! test/com/sun/javadoc/testSubTitle/TestSubTitle.java ! test/com/sun/javadoc/testTaglets/TestTaglets.java ! test/com/sun/javadoc/testTaglets/taglets/Foo.java ! test/jdk/javadoc/doclet/5093723/T5093723.java ! test/jdk/javadoc/doclet/AccessAsciiArt/AccessAsciiArt.java ! test/jdk/javadoc/doclet/AccessFrameTitle/AccessFrameTitle.java ! test/jdk/javadoc/doclet/AccessH1/AccessH1.java ! test/jdk/javadoc/doclet/AccessSkipNav/AccessSkipNav.java ! test/jdk/javadoc/doclet/AccessSummary/AccessSummary.java ! test/jdk/javadoc/doclet/AuthorDD/AuthorDD.java ! test/jdk/javadoc/doclet/DocRootSlash/DocRootSlash.java ! test/jdk/javadoc/doclet/InheritDocForUserTags/DocTest.java ! test/jdk/javadoc/doclet/JavascriptWinTitle/JavascriptWinTitle.java ! test/jdk/javadoc/doclet/MetaTag/MetaTag.java ! test/jdk/javadoc/doclet/PackagesHeader/PackagesHeader.java ! test/jdk/javadoc/doclet/T6735320/T6735320.java ! test/jdk/javadoc/doclet/ValidHtml/ValidHtml.java ! test/jdk/javadoc/doclet/VersionNumber/VersionNumber.java ! test/jdk/javadoc/doclet/WindowTitles/WindowTitles.java ! test/jdk/javadoc/doclet/constantValues/TestConstantValuesDriver.java ! test/jdk/javadoc/doclet/dupThrowsTags/TestDupThrowsTags.java ! test/jdk/javadoc/doclet/testAbsLinkPath/TestAbsLinkPath.java ! test/jdk/javadoc/doclet/testAbstractMethod/TestAbstractMethod.java ! test/jdk/javadoc/doclet/testAnchorNames/TestAnchorNames.java ! test/jdk/javadoc/doclet/testAnnotationOptional/TestAnnotationOptional.java ! test/jdk/javadoc/doclet/testAnnotationTypes/TestAnnotationTypes.java ! test/jdk/javadoc/doclet/testBackSlashInLink/TestBackSlashInLink.java ! test/jdk/javadoc/doclet/testBadPackageFileInJar/TestBadPackageFileInJar.java ! test/jdk/javadoc/doclet/testBadSourceFile/TestBadSourceFile.java ! test/jdk/javadoc/doclet/testBaseClass/TestBaseClass.java ! test/jdk/javadoc/doclet/testBreakIterator/TestBreakIterator.java ! test/jdk/javadoc/doclet/testCRLineSeparator/TestCRLineSeparator.java ! test/jdk/javadoc/doclet/testCharset/TestCharset.java ! test/jdk/javadoc/doclet/testClassCrossReferences/TestClassCrossReferences.java ! test/jdk/javadoc/doclet/testClassTree/TestClassTree.java ! test/jdk/javadoc/doclet/testCmndLineClass/TestCmndLineClass.java ! test/jdk/javadoc/doclet/testCompletionFailure/TestCompletionFailure.java ! test/jdk/javadoc/doclet/testConstantValuesPage/TestConstantValuesPage.java ! test/jdk/javadoc/doclet/testConstructorIndent/TestConstructorIndent.java ! test/jdk/javadoc/doclet/testConstructors/TestConstructors.java ! test/jdk/javadoc/doclet/testDeprecatedDocs/TestDeprecatedDocs.java ! test/jdk/javadoc/doclet/testDocEncoding/TestDocEncoding.java ! test/jdk/javadoc/doclet/testDocErrorReporter/TestDocErrorReporter.java ! test/jdk/javadoc/doclet/testDocFileDir/TestDocFileDir.java ! test/jdk/javadoc/doclet/testDocFiles/TestDocFiles.java ! test/jdk/javadoc/doclet/testDocRootInlineTag/TestDocRootInlineTag.java ! test/jdk/javadoc/doclet/testDocRootLink/TestDocRootLink.java ! test/jdk/javadoc/doclet/testDupParamWarn/TestDupParamWarn.java ! test/jdk/javadoc/doclet/testEmptyClass/TestEmptyClass.java ! test/jdk/javadoc/doclet/testEnclosingClass/TestEnclosingClass.java ! test/jdk/javadoc/doclet/testEncoding/TestEncoding.java ! test/jdk/javadoc/doclet/testExternalOverridenMethod/TestExternalOverridenMethod.java ! test/jdk/javadoc/doclet/testGeneratedBy/TestGeneratedBy.java ! test/jdk/javadoc/doclet/testGroupOption/TestGroupOption.java ! test/jdk/javadoc/doclet/testHeadings/TestHeadings.java ! test/jdk/javadoc/doclet/testHelpFile/TestHelpFile.java ! test/jdk/javadoc/doclet/testHelpOption/TestHelpOption.java ! test/jdk/javadoc/doclet/testHiddenMembers/TestHiddenMembers.java ! test/jdk/javadoc/doclet/testHref/TestHref.java ! test/jdk/javadoc/doclet/testHrefInDocComment/TestHrefInDocComment.java ! test/jdk/javadoc/doclet/testHtmlComments/TestHtmlComments.java ! test/jdk/javadoc/doclet/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java ! test/jdk/javadoc/doclet/testHtmlDocument/TestHtmlDocument.java ! test/jdk/javadoc/doclet/testHtmlStrongTag/TestHtmlStrongTag.java ! test/jdk/javadoc/doclet/testHtmlTableStyles/TestHtmlTableStyles.java ! test/jdk/javadoc/doclet/testHtmlTableTags/TestHtmlTableTags.java ! test/jdk/javadoc/doclet/testHtmlTag/TestHtmlTag.java ! test/jdk/javadoc/doclet/testHtmlVersion/TestHtmlVersion.java ! test/jdk/javadoc/doclet/testIndentation/TestIndentation.java ! test/jdk/javadoc/doclet/testIndex/TestIndex.java ! test/jdk/javadoc/doclet/testInlineLinkLabel/TestInlineLinkLabel.java ! test/jdk/javadoc/doclet/testInterface/TestInterface.java ! test/jdk/javadoc/doclet/testJavaFX/TestJavaFX.java ! test/jdk/javadoc/doclet/testJavascript/TestJavascript.java ! test/jdk/javadoc/doclet/testLambdaFeature/TestLambdaFeature.java ! test/jdk/javadoc/doclet/testLeadingSpaces/LeadingSpaces.java ! test/jdk/javadoc/doclet/testLegacyTaglet/TestLegacyTaglet.java ! test/jdk/javadoc/doclet/testLinkOption/TestBadLinkOption.java ! test/jdk/javadoc/doclet/testLinkOption/TestLinkOption.java ! test/jdk/javadoc/doclet/testLinkOption/TestNewLineInLink.java + test/jdk/javadoc/doclet/testLinkOption/extra/StringBuilder.java - test/jdk/javadoc/doclet/testLinkOption/java/lang/StringBuilderChild.java + test/jdk/javadoc/doclet/testLinkOption/jdk/package-list + test/jdk/javadoc/doclet/testLinkOption/mylib/lang/StringBuilderChild.java - test/jdk/javadoc/doclet/testLinkOption/package-list ! test/jdk/javadoc/doclet/testLinkTaglet/TestLinkTaglet.java ! test/jdk/javadoc/doclet/testLinkToSerialForm/TestLinkToSerialForm.java ! test/jdk/javadoc/doclet/testLiteralCodeInPre/TestLiteralCodeInPre.java ! test/jdk/javadoc/doclet/testMemberInheritence/TestMemberInheritence.java ! test/jdk/javadoc/doclet/testMemberSummary/TestMemberSummary.java ! test/jdk/javadoc/doclet/testMethodTypes/TestMethodTypes.java ! test/jdk/javadoc/doclet/testModifierEx/TestModifierEx.java ! test/jdk/javadoc/doclet/testNavigation/TestNavigation.java ! test/jdk/javadoc/doclet/testNestedGenerics/TestNestedGenerics.java ! test/jdk/javadoc/doclet/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/jdk/javadoc/doclet/testNoPackagesFile/TestNoPackagesFile.java ! test/jdk/javadoc/doclet/testNotifications/TestNotifications.java ! test/jdk/javadoc/doclet/testOptions/TestOptions.java ! test/jdk/javadoc/doclet/testOrdering/TestOrdering.java ! test/jdk/javadoc/doclet/testOverridenMethods/TestMultiInheritence.java ! test/jdk/javadoc/doclet/testOverridenMethods/TestOverridenMethodDocCopy.java ! test/jdk/javadoc/doclet/testOverridenMethods/TestOverridenPrivateMethods.java ! test/jdk/javadoc/doclet/testOverridenMethods/TestOverridenPrivateMethodsWithPackageFlag.java ! test/jdk/javadoc/doclet/testOverridenMethods/TestOverridenPrivateMethodsWithPrivateFlag.java ! test/jdk/javadoc/doclet/testPackageDeprecation/TestPackageDeprecation.java ! test/jdk/javadoc/doclet/testPackagePage/TestPackagePage.java ! test/jdk/javadoc/doclet/testParamTaglet/TestParamTaglet.java ! test/jdk/javadoc/doclet/testPrivateClasses/TestPrivateClasses.java ! test/jdk/javadoc/doclet/testRecurseSubPackages/TestRecurseSubPackages.java ! test/jdk/javadoc/doclet/testRelativeLinks/TestRelativeLinks.java ! test/jdk/javadoc/doclet/testRepeatedAnnotations/TestRepeatedAnnotations.java ! test/jdk/javadoc/doclet/testReturnTag/TestReturnTag.java ! test/jdk/javadoc/doclet/testSearch/TestSearch.java ! test/jdk/javadoc/doclet/testSeeTag/TestSeeTag.java ! test/jdk/javadoc/doclet/testSerialVersionUID/TestSerialVersionUID.java ! test/jdk/javadoc/doclet/testSerializedForm/TestSerializedForm.java ! test/jdk/javadoc/doclet/testSerializedFormDeprecationInfo/TestSerializedFormDeprecationInfo.java ! test/jdk/javadoc/doclet/testSimpleTag/TestSimpleTag.java ! test/jdk/javadoc/doclet/testSimpleTagExclude/TestSimpleTagExclude.java ! test/jdk/javadoc/doclet/testSimpleTagInherit/TestSimpleTagInherit.java ! test/jdk/javadoc/doclet/testSinceTag/TestSinceTag.java ! test/jdk/javadoc/doclet/testSingleQuotedLink/TestSingleQuotedLink.java ! test/jdk/javadoc/doclet/testSourceTab/TestSourceTab.java ! test/jdk/javadoc/doclet/testStylesheet/TestStylesheet.java ! test/jdk/javadoc/doclet/testSubTitle/TestSubTitle.java ! test/jdk/javadoc/doclet/testSummaryHeading/TestSummaryHeading.java ! test/jdk/javadoc/doclet/testSuperclassInSerialForm/TestSuperClassInSerialForm.java ! test/jdk/javadoc/doclet/testSupplementary/TestSupplementary.java ! test/jdk/javadoc/doclet/testTagInheritence/TestTagInheritence.java ! test/jdk/javadoc/doclet/testTagMisuse/TestTagMisuse.java ! test/jdk/javadoc/doclet/testTagOutput/TestTagOutput.java ! test/jdk/javadoc/doclet/testThrowsHead/TestThrowsHead.java ! test/jdk/javadoc/doclet/testThrowsInheritence/TestThrowsTagInheritence.java ! test/jdk/javadoc/doclet/testThrowsTag/TestThrowsTag.java ! test/jdk/javadoc/doclet/testTitleInHref/TestTitleInHref.java ! test/jdk/javadoc/doclet/testTopOption/TestTopOption.java ! test/jdk/javadoc/doclet/testTypeAnnotations/TestTypeAnnotations.java ! test/jdk/javadoc/doclet/testTypeParams/TestTypeParameters.java ! test/jdk/javadoc/doclet/testUnnamedPackage/TestUnnamedPackage.java ! test/jdk/javadoc/doclet/testUseOption/TestUseOption.java ! test/jdk/javadoc/doclet/testValueTag/TestValueTag.java ! test/jdk/javadoc/doclet/testWarnBadParamNames/TestWarnBadParamNames.java ! test/jdk/javadoc/doclet/testWindowTitle/TestWindowTitle.java ! test/jdk/javadoc/doclet/testXOption/TestXOption.java ! test/jdk/javadoc/doclet/typeAnnotations/smoke/TestSmoke.java ! test/jdk/javadoc/tool/6227454/Test.java ! test/jdk/javadoc/tool/6942366/T6942366.java ! test/jdk/javadoc/tool/6958836/Test.java ! test/jdk/javadoc/tool/6964914/Test.java ! test/jdk/javadoc/tool/6964914/TestStdDoclet.java ! test/jdk/javadoc/tool/6964914/TestUserDoclet.java ! test/jdk/javadoc/tool/BreakIteratorWarning.java ! test/jdk/javadoc/tool/CheckResourceKeys.java ! test/jdk/javadoc/tool/EnsureNewOldDoclet.java ! test/jdk/javadoc/tool/FlagsTooEarly.java ! test/jdk/javadoc/tool/MaxWarns.java ! test/jdk/javadoc/tool/NoStar.java ! test/jdk/javadoc/tool/QuietOption.java ! test/jdk/javadoc/tool/ReleaseOption.java ! test/jdk/javadoc/tool/T4994049/T4994049.java ! test/jdk/javadoc/tool/T6551367.java ! test/jdk/javadoc/tool/T6968833.java ! test/jdk/javadoc/tool/VerifyLocale.java ! test/jdk/javadoc/tool/XWerror.java ! test/jdk/javadoc/tool/api/basic/JavadocTaskImplTest.java ! test/jdk/javadoc/tool/completionFailure/CompletionFailure.java ! test/jdk/javadoc/tool/doclint/DocLintTest.java ! test/jdk/javadoc/tool/doclint/ImplicitHeadersTest.java ! test/jdk/javadoc/tool/dupOk/DupOk.java ! test/jdk/javadoc/tool/nonConstExprs/Test.java ! test/jdk/javadoc/tool/outputRedirect/Test.java ! test/jdk/javadoc/tool/parser/7091528/T7091528.java ! test/jdk/jshell/ClassPathTest.java ! test/jdk/jshell/CommandCompletionTest.java ! test/jdk/jshell/CompletionSuggestionTest.java ! test/jdk/jshell/ComputeFQNsTest.java ! test/jdk/jshell/ErrorTranslationTest.java ! test/jdk/jshell/ImportTest.java ! test/jdk/jshell/InferTypeTest.java ! test/jdk/jshell/StartOptionTest.java ! test/jdk/jshell/T8146368/JShellToolTest8146368.java ! test/jdk/jshell/ToolFormatTest.java ! test/jdk/jshell/ToolReloadTest.java ! test/lib/annotations/annotations/classfile/ClassfileInspector.java ! test/tools/all/RunCodingRules.java ! test/tools/doclint/tool/PathsTest.java ! test/tools/javac/4846262/CheckEBCDICLocaleTest.java ! test/tools/javac/6302184/HiddenOptionsShouldUseGivenEncodingTest.java ! test/tools/javac/6330997/T6330997.java ! test/tools/javac/6403424/T6403424.java ! test/tools/javac/6508981/TestInferBinaryName.java ! test/tools/javac/6589361/T6589361.java ! test/tools/javac/6627362/T6627362.java ! test/tools/javac/6889255/T6889255.java ! test/tools/javac/AnonymousSubclassTest.java ! test/tools/javac/ClassPathTest/ClassPathTest.java ! test/tools/javac/ConstFoldTest.java ! test/tools/javac/Diagnostics/6769027/T6769027.java ! test/tools/javac/ExtDirs/ExtDirTest.java ! test/tools/javac/IncorrectInheritance/IncorrectInheritanceTest.java ! test/tools/javac/MethodParameters/AttributeVisitor.java ! test/tools/javac/MethodParametersTest.java ! test/tools/javac/MissingInclude/MissingIncludeTest.java - test/tools/javac/Object1.java - test/tools/javac/Object1.out - test/tools/javac/Object2.java - test/tools/javac/Object2.out ! test/tools/javac/Paths/AbsolutePathTest.java ! test/tools/javac/Paths/Diagnostics.sh ! test/tools/javac/ProtectedInnerClass/ProtectedInnerClassesTest.java ! test/tools/javac/T4093617/T4093617.java ! test/tools/javac/T4093617/T4093617.out + test/tools/javac/T4093617/java.base/Object.java ! test/tools/javac/T4965689/ClassLiteralWastesByteTest.java ! test/tools/javac/T5053846/MethodRefDupInConstantPoolTest.java ! test/tools/javac/T5090006/AssertionFailureTest.java ! test/tools/javac/T6181889/EmptyFinallyTest.java ! test/tools/javac/T6358024.java ! test/tools/javac/T6358166.java ! test/tools/javac/T6403466.java ! test/tools/javac/T6405099.java ! test/tools/javac/T6406771.java ! test/tools/javac/T6435291/T6435291.java ! test/tools/javac/T6558476.java ! test/tools/javac/T6725036.java ! test/tools/javac/T6942649.java ! test/tools/javac/T6970173/DebugPointerAtBadPositionTest.java ! test/tools/javac/T6972327.java ! test/tools/javac/T6985181.java ! test/tools/javac/T6993301.java ! test/tools/javac/T7008643/InlinedFinallyConfuseDebuggersTest.java ! test/tools/javac/T7040592/T7040592.java ! test/tools/javac/T8003967/DetectMutableStaticFields.java ! test/tools/javac/T8009640/CheckRejectProfileBCPOptionsIfUsedTogetherTest.java ! test/tools/javac/T8010659/CompilerCrashWhenMixingBinariesAndSourcesTest.java ! test/tools/javac/T8010737/ParameterNamesAreNotCopiedToAnonymousInitTest.java ! test/tools/javac/T8013394/CompileErrorWithIteratorTest.java ! test/tools/javac/T8019486/WrongLNTForLambdaTest.java ! test/tools/javac/T8022162/IncorrectSignatureDeterminationForInnerClassesTest.java ! test/tools/javac/T8024039/NoDeadCodeGenerationOnTrySmtTest.java ! test/tools/javac/T8024437/ExceptionInferenceFromClassFileTest.java ! test/tools/javac/TryWithResources/TwrForVariable3.out ! test/tools/javac/VersionOpt.java ! test/tools/javac/annotations/SyntheticParameters.java ! test/tools/javac/annotations/typeAnnotations/TypeProcOnly.java ! test/tools/javac/annotations/typeAnnotations/classfile/NestedLambdasCastedTest.java ! test/tools/javac/annotations/typeAnnotations/packageanno/PackageProcessor.java ! test/tools/javac/api/6400303/T6400303.java ! test/tools/javac/api/6412656/T6412656.java ! test/tools/javac/api/6418694/T6418694.java ! test/tools/javac/api/6440528/T6440528.java ! test/tools/javac/api/6557752/T6557752.java ! test/tools/javac/api/6852595/T6852595.java ! test/tools/javac/api/T6358786.java ! test/tools/javac/api/T6397104.java ! test/tools/javac/api/T6412669.java ! test/tools/javac/api/TestClientCodeWrapper.java ! test/tools/javac/api/TestGetElementReference.java ! test/tools/javac/api/TestJavacTask.java ! test/tools/javac/api/TestJavacTaskScanner.java ! test/tools/javac/api/TestResolveError.java ! test/tools/javac/api/TestResolveIdent.java ! test/tools/javac/api/TestSearchPaths.java ! test/tools/javac/api/TestTrees.java ! test/tools/javac/api/ToolProvider/HelloWorldTest.java ! test/tools/javac/api/ToolProvider/ToolProviderTest1.java ! test/tools/javac/api/ToolProvider/ToolProviderTest2.java + test/tools/javac/api/mod/api/pkg/Api.java + test/tools/javac/api/mod/module-info.java ! test/tools/javac/api/taskListeners/CompileEvent.java ! test/tools/javac/boxing/IncrementBoxedAndAccess.java ! test/tools/javac/cast/intersection/model/Model01.java ! test/tools/javac/cast/intersection/model/ModelChecker.java ! test/tools/javac/classfiles/InnerClasses/T8068517.java ! test/tools/javac/classfiles/attributes/AnnotationDefault/AnnotationDefaultTest.java ! test/tools/javac/classfiles/attributes/EnclosingMethod/EnclosingMethodTest.java ! test/tools/javac/classfiles/attributes/LineNumberTable/LineNumberTest.java ! test/tools/javac/classfiles/attributes/LocalVariableTable/LocalVariableTableTest.java ! test/tools/javac/classfiles/attributes/LocalVariableTable/LocalVariableTypeTableTest.java + test/tools/javac/classfiles/attributes/Module/ModuleFlagTest.java + test/tools/javac/classfiles/attributes/Module/ModuleTest.java + test/tools/javac/classfiles/attributes/Module/ModuleTestBase.java ! test/tools/javac/classfiles/attributes/Signature/ConstructorTest.java ! test/tools/javac/classfiles/attributes/Signature/EnumTest.java ! test/tools/javac/classfiles/attributes/Signature/ExceptionTest.java ! test/tools/javac/classfiles/attributes/Signature/FieldTest.java ! test/tools/javac/classfiles/attributes/Signature/InnerClassTest.java ! test/tools/javac/classfiles/attributes/Signature/MethodParameterTest.java ! test/tools/javac/classfiles/attributes/Signature/MethodTypeBoundTest.java ! test/tools/javac/classfiles/attributes/Signature/ReturnTypeTest.java ! test/tools/javac/classfiles/attributes/SourceFile/AnonymousClassTest.java ! test/tools/javac/classfiles/attributes/SourceFile/InnerClassTest.java ! test/tools/javac/classfiles/attributes/SourceFile/LocalClassTest.java ! test/tools/javac/classfiles/attributes/SourceFile/MixTest.java + test/tools/javac/classfiles/attributes/SourceFile/ModuleInfoTest.java ! test/tools/javac/classfiles/attributes/SourceFile/NoSourceFileAttribute.java ! test/tools/javac/classfiles/attributes/SourceFile/SourceFileTestBase.java ! test/tools/javac/classfiles/attributes/SourceFile/SyntheticClassTest.java ! test/tools/javac/classfiles/attributes/SourceFile/TopLevelClassesOneFileTest.java ! test/tools/javac/classfiles/attributes/Synthetic/AccessToPrivateInnerClassMembersTest.java ! test/tools/javac/classfiles/attributes/Synthetic/AccessToPrivateSiblingsTest.java ! test/tools/javac/classfiles/attributes/Synthetic/AssertFieldTest.java ! test/tools/javac/classfiles/attributes/Synthetic/BridgeMethodForGenericMethodTest.java ! test/tools/javac/classfiles/attributes/Synthetic/BridgeMethodsForLambdaTest.java ! test/tools/javac/classfiles/attributes/Synthetic/EnumTest.java ! test/tools/javac/classfiles/attributes/Synthetic/PackageInfoTest.java ! test/tools/javac/classfiles/attributes/Synthetic/ThisFieldTest.java ! test/tools/javac/classfiles/attributes/annotations/RuntimeAnnotationsForGenericMethodTest.java ! test/tools/javac/classfiles/attributes/annotations/RuntimeAnnotationsForInnerAnnotationTest.java ! test/tools/javac/classfiles/attributes/annotations/RuntimeAnnotationsForInnerClassTest.java ! test/tools/javac/classfiles/attributes/annotations/RuntimeAnnotationsForInnerEnumTest.java ! test/tools/javac/classfiles/attributes/annotations/RuntimeAnnotationsForInnerInterfaceTest.java ! test/tools/javac/classfiles/attributes/annotations/RuntimeAnnotationsForTopLevelClassTest.java ! test/tools/javac/classfiles/attributes/annotations/RuntimeParameterAnnotationsForGenericMethodTest.java ! test/tools/javac/classfiles/attributes/annotations/RuntimeParameterAnnotationsForLambdaTest.java ! test/tools/javac/classfiles/attributes/annotations/RuntimeParameterAnnotationsTest.java ! test/tools/javac/classfiles/attributes/deprecated/DeprecatedPackageTest.java ! test/tools/javac/classfiles/attributes/deprecated/DeprecatedTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerAnnotationsInInnerAnnotationTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerAnnotationsInInnerClassTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerAnnotationsInInnerEnumTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerAnnotationsInInnerInterfaceTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerClassesHierarchyTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerClassesInAnonymousClassTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerClassesInInnerAnnotationTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerClassesInInnerClassTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerClassesInInnerEnumTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerClassesInInnerInterfaceTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerClassesInLocalClassTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerClassesIndexTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerClassesTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerEnumInInnerAnnotationTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerEnumInInnerEnumTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerEnumInInnerInterfaceTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerEnumsInInnerClassTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerInterfacesInInnerAnnotationTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerInterfacesInInnerClassTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerInterfacesInInnerEnumTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerInterfacesInInnerInterfaceTest.java ! test/tools/javac/classfiles/attributes/innerclasses/NoInnerClassesTest.java ! test/tools/javac/classfiles/attributes/lib/TestResult.java ! test/tools/javac/code/ArrayClone.java ! test/tools/javac/defaultMethods/AssertionsTest.java ! test/tools/javac/defaultMethods/BadClassfile.java ! test/tools/javac/defaultMethodsVisibility/DefaultMethodsNotVisibleForSourceLessThan8Test.java ! test/tools/javac/diags/CheckExamples.java ! test/tools/javac/diags/CheckResourceKeys.java ! test/tools/javac/diags/DocCommentProcessor.java ! test/tools/javac/diags/Example.java ! test/tools/javac/diags/FileManager.java ! test/tools/javac/diags/examples.not-yet.txt ! test/tools/javac/diags/examples/DirPathElementNotFound.java ! test/tools/javac/diags/examples/InvalidDefaultInterface/InvalidDefaultInterface.java ! test/tools/javac/diags/examples/InvalidDefaultInterface/processors/CreateBadClassFile.java ! test/tools/javac/diags/examples/InvalidStaticInterface/InvalidStaticInterface.java ! test/tools/javac/diags/examples/InvalidStaticInterface/processors/CreateBadClassFile.java ! test/tools/javac/diags/examples/NoJavaLang.java ! test/tools/javac/diags/examples/NoSuperclass.java ! test/tools/javac/doctree/ReferenceTest.java ! test/tools/javac/fatalErrors/NoJavaLangTest.java ! test/tools/javac/file/ExplodedImage.java ! test/tools/javac/file/T7018098.java ! test/tools/javac/generics/diamond/neg/T8078473_2.java ! test/tools/javac/importscope/CompletionFailureDuringImport.java ! test/tools/javac/importscope/ImportDependenciesTest.java ! test/tools/javac/importscope/ImportMembersTest.java ! test/tools/javac/importscope/NegativeCyclicDependencyTest.java ! test/tools/javac/innerClassFile/InnerClassFileTest.java ! test/tools/javac/javazip/JavaZipTest.java ! test/tools/javac/lambda/AvoidInfiniteReattribution.java ! test/tools/javac/lambda/LambdaInnerTypeVarReflect.java ! test/tools/javac/lambda/T8129740/SourceToSourceTranslationTest.java ! test/tools/javac/lambda/TestBootstrapMethodsCount.java ! test/tools/javac/lambda/bridge/TestMetafactoryBridges.java ! test/tools/javac/lambda/bridge/template_tests/TEST.properties ! test/tools/javac/lambda/lambdaNaming/TestNonSerializableLambdaNameStability.java ! test/tools/javac/lambda/lambdaNaming/TestSerializedLambdaNameStability.java ! test/tools/javac/lambdaShapes/TEST.properties ! test/tools/javac/lib/DPrinter.java ! test/tools/javac/lib/JavacTestingAbstractProcessor.java ! test/tools/javac/lib/combo/ReusableContext.java ! test/tools/javac/limits/NumArgsTest.java ! test/tools/javac/links/LinksTest.java + test/tools/javac/modules/AbstractOrInnerClassServiceImplTest.java + test/tools/javac/modules/AddLimitMods.java + test/tools/javac/modules/AddReadsTest.java + test/tools/javac/modules/AnnotationProcessing.java + test/tools/javac/modules/AnnotationProcessorsInModulesTest.java + test/tools/javac/modules/AutomaticModules.java + test/tools/javac/modules/DoclintOtherModules.java + test/tools/javac/modules/DuplicateClassTest.java + test/tools/javac/modules/EdgeCases.java + test/tools/javac/modules/GraphsTest.java + test/tools/javac/modules/HelloWorldTest.java + test/tools/javac/modules/MOptionTest.java + test/tools/javac/modules/ModuleFinderTest.java + test/tools/javac/modules/ModuleInfoTest.java + test/tools/javac/modules/ModulePathTest.java + test/tools/javac/modules/ModuleSourcePathTest.java + test/tools/javac/modules/ModuleTestBase.java + test/tools/javac/modules/ModulesAndClassPathTest.java + test/tools/javac/modules/MultiModuleModeTest.java + test/tools/javac/modules/NPEEmptyFileTest.java + test/tools/javac/modules/OutputDirTest.java + test/tools/javac/modules/PackageConflictTest.java + test/tools/javac/modules/PackageMultipleModules.java + test/tools/javac/modules/PluginsInModulesTest.java + test/tools/javac/modules/ProvidesTest.java + test/tools/javac/modules/QueryBeforeEnter.java + test/tools/javac/modules/RepeatedUsesAndProvidesTest.java + test/tools/javac/modules/ReportNonExistentPackageTest.java + test/tools/javac/modules/RequiresPublicTest.java + test/tools/javac/modules/ResolveTest.java + test/tools/javac/modules/ServiceInStaticClassErrorTest.java + test/tools/javac/modules/ServiceProvidedButNotExportedOrUsedTest.java + test/tools/javac/modules/SingleModuleModeTest.java + test/tools/javac/modules/SubpackageTest.java + test/tools/javac/modules/UpgradeModulePathTest.java + test/tools/javac/modules/UsesTest.java + test/tools/javac/modules/XModuleTest.java ! test/tools/javac/newlines/NewLineTest.java ! test/tools/javac/options/modes/Tester.java ! test/tools/javac/options/xprefer/XPreferTest.java ! test/tools/javac/platform/PlatformProviderTest.java ! test/tools/javac/plugin/showtype/Test.java ! test/tools/javac/processing/T8142931.java ! test/tools/javac/processing/environment/ProcessingEnvAnnoDiscovery.java ! test/tools/javac/processing/errors/EnsureAnnotationTypeMismatchException/Processor.java ! test/tools/javac/processing/errors/EnsureAnnotationTypeMismatchException/Source.java ! test/tools/javac/processing/errors/EnsureMirroredTypeException/Processor.java ! test/tools/javac/processing/errors/EnsureMirroredTypeException/Source.java ! test/tools/javac/processing/errors/StopOnInapplicableAnnotations/GenerateFunctionalInterface.java ! test/tools/javac/processing/errors/StopOnInapplicableAnnotations/GenerateSuperInterfaceProcessor.java ! test/tools/javac/processing/errors/TestBadProcessor.java ! test/tools/javac/processing/loader/testClose/TestClose.java ! test/tools/javac/processing/loader/testClose/TestClose2.java ! test/tools/javac/processing/messager/MessagerDiags.java ! test/tools/javac/processing/model/TestSymtabItems.java ! test/tools/javac/processing/model/element/8009367/TestQualifiedNameUsed.java ! test/tools/javac/processing/model/element/TestEmptyContainer.java ! test/tools/javac/processing/model/element/TestMissingElement/TestMissingElement.java ! test/tools/javac/processing/model/element/TestNonInherited.java ! test/tools/javac/processing/model/inheritedByType/EnsureOrder.java ! test/tools/javac/processing/model/testgetallmembers/Main.java ! test/tools/javac/processing/model/type/BasicAnnoTests.java ! test/tools/javac/processing/model/type/BoundsTest.java ! test/tools/javac/processing/model/type/NoTypes.java ! test/tools/javac/processing/rounds/BaseClassesNotReRead.java ! test/tools/javac/processing/rounds/CompleteOnClosed.java ! test/tools/javac/processing/rounds/OverwriteBetweenCompilations.java - test/tools/javac/profiles/ProfileTest.java - test/tools/javac/proprietary/WarnClass.java - test/tools/javac/proprietary/WarnClass.out - test/tools/javac/proprietary/WarnImport.java - test/tools/javac/proprietary/WarnImport.out - test/tools/javac/proprietary/WarnMethod.java - test/tools/javac/proprietary/WarnMethod.out - test/tools/javac/proprietary/WarnStaticImport.java - test/tools/javac/proprietary/WarnStaticImport.out - test/tools/javac/proprietary/WarnVariable.java - test/tools/javac/proprietary/WarnVariable.out - test/tools/javac/proprietary/WarnWildcard.java - test/tools/javac/proprietary/WarnWildcard.out + test/tools/javac/redefineObject/Object1-test.java + test/tools/javac/redefineObject/Object1.out + test/tools/javac/redefineObject/Object2-test.java + test/tools/javac/redefineObject/Object2.out + test/tools/javac/redefineObject/java.base/Object1.java + test/tools/javac/redefineObject/java.base/Object2.java ! test/tools/javac/resolve/BitWiseOperators.java ! test/tools/javac/scope/DupUnsharedTest.java ! test/tools/javac/scope/HashCollisionTest.java ! test/tools/javac/scope/RemoveSymbolUnitTest.java ! test/tools/javac/scope/StarImportTest.java ! test/tools/javac/stackmap/StackMapTest.java ! test/tools/javac/sym/ElementStructureTest.java - test/tools/javac/synthesize/Boolean.java - test/tools/javac/synthesize/Byte.java - test/tools/javac/synthesize/Character.java - test/tools/javac/synthesize/Cloneable.java - test/tools/javac/synthesize/Double.java - test/tools/javac/synthesize/Float.java - test/tools/javac/synthesize/Integer.java - test/tools/javac/synthesize/Long.java ! test/tools/javac/synthesize/Main.java - test/tools/javac/synthesize/Number.java - test/tools/javac/synthesize/Object.java - test/tools/javac/synthesize/Serializable.java - test/tools/javac/synthesize/Short.java - test/tools/javac/synthesize/Test.java - test/tools/javac/synthesize/Void.java + test/tools/javac/synthesize/src/Boolean.java + test/tools/javac/synthesize/src/Byte.java + test/tools/javac/synthesize/src/Character.java + test/tools/javac/synthesize/src/Cloneable.java + test/tools/javac/synthesize/src/Double.java + test/tools/javac/synthesize/src/Float.java + test/tools/javac/synthesize/src/Integer.java + test/tools/javac/synthesize/src/Long.java + test/tools/javac/synthesize/src/Number.java + test/tools/javac/synthesize/src/Object.java + test/tools/javac/synthesize/src/Serializable.java + test/tools/javac/synthesize/src/Short.java + test/tools/javac/synthesize/src/Test.java + test/tools/javac/synthesize/src/Void.java + test/tools/javac/synthesize/src/module-info.java ! test/tools/javac/tree/8067914/NukeExtraCast.java ! test/tools/javac/tree/ArrayTypeToString.java ! test/tools/javac/tree/MakeTypeTest.java ! test/tools/javac/tree/ScopeTest.java ! test/tools/javac/treeannotests/AnnoTreeTests.java ! test/tools/javac/treeannotests/TestProcessor.java ! test/tools/javac/types/ScopeListenerTest.java ! test/tools/javac/types/TestComparisons.java ! test/tools/javac/util/T6597678.java ! test/tools/javac/warnings/6594914/T6594914b.out ! test/tools/javac/warnings/VerifyLintDescriptions.java ! test/tools/javadoc/6227454/Test.java ! test/tools/javadoc/6964914/Test.java ! test/tools/javadoc/6964914/TestStdDoclet.java ! test/tools/javadoc/6964914/TestUserDoclet.java ! test/tools/javadoc/CheckResourceKeys.java ! test/tools/javadoc/CompletionError.java ! test/tools/javadoc/api/basic/TagletPathTest.java ! test/tools/javah/6257087/T6257087.java + test/tools/javah/ModuleClass.java ! test/tools/javah/T4942232/MissingParamClassTest.java ! test/tools/javah/constMacroTest/ConstMacroTest.java ! test/tools/javap/4111861/T4111861.java ! test/tools/javap/4798312/JavapShouldLoadClassesFromRTJarTest.java ! test/tools/javap/4866831/PublicInterfaceTest.java ! test/tools/javap/4870651/T4870651.java ! test/tools/javap/6937244/T6937244.java ! test/tools/javap/6937244/T6937244A.java ! test/tools/javap/8006334/JavapTaskCtorFailWithNPE.java ! test/tools/javap/8007907/JavapReturns0AfterClassNotFoundTest.java ! test/tools/javap/AccessModifiers.java ! test/tools/javap/BadAttributeLength.java ! test/tools/javap/BoundsTypeVariableTest.java ! test/tools/javap/DescriptorTest.java ! test/tools/javap/ExtPath.java ! test/tools/javap/InvalidOptions.java ! test/tools/javap/MethodParameters.java ! test/tools/javap/StackMapTableTest.java ! test/tools/javap/T4075403.java ! test/tools/javap/T4459541.java ! test/tools/javap/T4501660.java ! test/tools/javap/T4501661.java ! test/tools/javap/T4777949.java ! test/tools/javap/T4876942.java ! test/tools/javap/T4880663.java ! test/tools/javap/T4880672.java ! test/tools/javap/T4884240.java ! test/tools/javap/T4975569.java ! test/tools/javap/T6271787.java ! test/tools/javap/T6474890.java ! test/tools/javap/T6587786.java ! test/tools/javap/T6622216.java ! test/tools/javap/T6622232.java ! test/tools/javap/T6622260.java ! test/tools/javap/T6715251.java ! test/tools/javap/T6715753.java ! test/tools/javap/T6715767.java ! test/tools/javap/T6729471.java ! test/tools/javap/T6824493.java ! test/tools/javap/T6863746.java ! test/tools/javap/T6866657.java ! test/tools/javap/T6868539.java ! test/tools/javap/T6879371.java ! test/tools/javap/T6980017.java ! test/tools/javap/T7004698.java ! test/tools/javap/T7186925.java ! test/tools/javap/T7190862.java ! test/tools/javap/T8032814.java ! test/tools/javap/T8032819.java ! test/tools/javap/T8033180.java ! test/tools/javap/T8033711.java ! test/tools/javap/T8035104.java ! test/tools/javap/T8038414.java ! test/tools/javap/TestSuperclass.java ! test/tools/javap/WhitespaceTest.java ! test/tools/javap/classfile/6888367/T6888367.java ! test/tools/javap/stackmap/StackmapTest.java ! test/tools/javap/typeAnnotations/T6855990.java ! test/tools/jdeps/APIDeps.java ! test/tools/jdeps/Basic.java + test/tools/jdeps/CompilerUtils.java ! test/tools/jdeps/DotFileTest.java ! test/tools/jdeps/VerboseFormat/JdepsDependencyClosure.java + test/tools/jdeps/VerboseFormat/use/indirect/DontUseJdkInternal2.java - test/tools/jdeps/VerboseFormat/use/indirect/DontUseUnsafe2.java + test/tools/jdeps/VerboseFormat/use/indirect/UseJdkInternalIndirectly.java - test/tools/jdeps/VerboseFormat/use/indirect/UseUnsafeIndirectly.java + test/tools/jdeps/VerboseFormat/use/indirect2/DontUseJdkInternal3.java - test/tools/jdeps/VerboseFormat/use/indirect2/DontUseUnsafe3.java + test/tools/jdeps/VerboseFormat/use/indirect2/UseJdkInternalIndirectly2.java - test/tools/jdeps/VerboseFormat/use/indirect2/UseUnsafeIndirectly2.java + test/tools/jdeps/VerboseFormat/use/internal/DontUseJdkInternal.java + test/tools/jdeps/VerboseFormat/use/internal/UseClassWithJdkInternal.java + test/tools/jdeps/VerboseFormat/use/internal/UseJdkInternalClass.java + test/tools/jdeps/VerboseFormat/use/internal/UseJdkInternalClass2.java - test/tools/jdeps/VerboseFormat/use/unsafe/DontUseUnsafe.java - test/tools/jdeps/VerboseFormat/use/unsafe/UseClassWithUnsafe.java - test/tools/jdeps/VerboseFormat/use/unsafe/UseUnsafeClass.java - test/tools/jdeps/VerboseFormat/use/unsafe/UseUnsafeClass2.java ! test/tools/jdeps/f/F.java - test/tools/jdeps/javax/activity/NotCompactProfile.java + test/tools/jdeps/jdk.unsupported/Foo.java + test/tools/jdeps/jdk.unsupported/JDKUnsupportedTest.java + test/tools/jdeps/modules/GenModuleInfo.java + test/tools/jdeps/modules/ModuleTest.java + test/tools/jdeps/modules/src/m1/module-info.java + test/tools/jdeps/modules/src/m1/p1/Goo.java + test/tools/jdeps/modules/src/m1/p1/Lib.java + test/tools/jdeps/modules/src/m1/p1/S.java + test/tools/jdeps/modules/src/m1/p1/internal/Impl.java + test/tools/jdeps/modules/src/m2/module-info.java + test/tools/jdeps/modules/src/m2/p2/Bar.java + test/tools/jdeps/modules/src/m2/p2/internal/T2.java + test/tools/jdeps/modules/src/m3/module-info.java + test/tools/jdeps/modules/src/m3/p3/Foo.java + test/tools/jdeps/modules/src/m3/p3/Main.java + test/tools/jdeps/modules/src/m4/module-info.java + test/tools/jdeps/modules/src/m4/p4/Lib.java + test/tools/jdeps/modules/src/m4/p4/internal/Impl.java + test/tools/jdeps/modules/src/unsupported/module-info.java + test/tools/jdeps/modules/src/unsupported/q/Counter.java ! test/tools/jdeps/p/Bar.java ! test/tools/lib/ToolBox.java ! test/tools/sjavac/ApiExtraction.java ! test/tools/sjavac/ClasspathDependencies.java ! test/tools/sjavac/CompileCircularSources.java ! test/tools/sjavac/CompileExcludingDependency.java ! test/tools/sjavac/CompileWithAtFile.java ! test/tools/sjavac/CompileWithInvisibleSources.java ! test/tools/sjavac/CompileWithOverrideSources.java ! test/tools/sjavac/HiddenFiles.java ! test/tools/sjavac/IncCompInheritance.java ! test/tools/sjavac/IncCompileChangeNative.java ! test/tools/sjavac/IncCompileDropClasses.java ! test/tools/sjavac/IncCompileFullyQualifiedRef.java ! test/tools/sjavac/IncCompileNoChanges.java ! test/tools/sjavac/IncCompileUpdateNative.java ! test/tools/sjavac/IncCompileWithChanges.java ! test/tools/sjavac/IncludeExcludePatterns.java ! test/tools/sjavac/NoState.java ! test/tools/sjavac/OverlappingSrcDst.java ! test/tools/sjavac/PackagePathMismatch.java ! test/tools/sjavac/ParallelCompilations.java ! test/tools/sjavac/PermittedArtifact.java ! test/tools/sjavac/StateDir.java Changeset: 447f26d4b506 Author: lana Date: 2016-03-23 19:33 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/447f26d4b506 Added tag jdk-9+111 for changeset 9adfb22ff08f ! .hgtags Changeset: e096d5faa384 Author: alanb Date: 2016-03-24 07:18 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/e096d5faa384 Merge ! .hgtags ! make/CompileInterim.gmk ! make/build.properties ! make/build.xml ! make/gendata/Gendata-jdk.compiler.gmk ! make/intellij/ant.xml ! make/intellij/build.xml ! make/launcher.sh-template ! make/netbeans/langtools/build.xml ! make/netbeans/langtools/nbproject/project.xml ! make/tools/crules/CodingRulesAnalyzerPlugin.java ! src/java.compiler/share/classes/javax/lang/model/element/ElementKind.java ! src/java.compiler/share/classes/javax/lang/model/element/ElementVisitor.java ! src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java ! src/java.compiler/share/classes/javax/lang/model/type/TypeKind.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor6.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor9.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementFilter.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor9.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementScanner9.java ! src/java.compiler/share/classes/javax/lang/model/util/Elements.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor9.java ! src/java.compiler/share/classes/javax/tools/ForwardingJavaFileManager.java ! src/java.compiler/share/classes/javax/tools/JavaFileManager.java ! src/java.compiler/share/classes/javax/tools/StandardLocation.java ! src/java.compiler/share/classes/javax/tools/ToolProvider.java ! src/java.compiler/share/classes/module-info.java ! src/jdk.compiler/share/classes/com/sun/source/tree/DirectiveTree.java ! src/jdk.compiler/share/classes/com/sun/source/tree/ExportsTree.java ! src/jdk.compiler/share/classes/com/sun/source/tree/ModuleTree.java ! src/jdk.compiler/share/classes/com/sun/source/tree/ProvidesTree.java ! src/jdk.compiler/share/classes/com/sun/source/tree/RequiresTree.java ! src/jdk.compiler/share/classes/com/sun/source/tree/Tree.java ! src/jdk.compiler/share/classes/com/sun/source/tree/TreeVisitor.java ! src/jdk.compiler/share/classes/com/sun/source/tree/UsesTree.java ! src/jdk.compiler/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java ! src/jdk.compiler/share/classes/com/sun/tools/doclint/DocLint.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/BasicJavacTask.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/ClientCodeWrapper.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/ClassFinder.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Directive.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Kinds.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/ModuleFinder.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Printer.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeTag.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/BaseFileManager.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/JRTIndex.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/ModuleNameReader.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassFile.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/JNIWriter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Arguments.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Main.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/model/JavacElements.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/ModuleHelper.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/ModuleWrappers.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java ! src/jdk.compiler/share/classes/com/sun/tools/javah/JavahTask.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/PubApiExtractor.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/Source.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/SjavacImpl.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/SmartFileManager.java ! src/jdk.compiler/share/classes/module-info.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/AbstractPackageIndexWriter.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/WriterFactoryImpl.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlConstants.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlStyle.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/WriterFactory.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/builders/BuilderFactory.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclet.xml ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets.properties ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFileFactory.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPaths.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/util/MetaKeywords.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/util/StandardDocFileFactory.java ! src/jdk.javadoc/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/jdk.javadoc/share/classes/com/sun/tools/javadoc/DocEnv.java ! src/jdk.javadoc/share/classes/com/sun/tools/javadoc/DocletInvoker.java ! src/jdk.javadoc/share/classes/com/sun/tools/javadoc/JavadocTool.java ! src/jdk.javadoc/share/classes/com/sun/tools/javadoc/Start.java ! src/jdk.javadoc/share/classes/com/sun/tools/javadoc/ToolOption.java ! src/jdk.javadoc/share/classes/com/sun/tools/javadoc/resources/javadoc.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractModuleIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractPackageIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConfigurationImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleIndexFrameWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModulePackageIndexFrameWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageIndexFrameWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/WriterFactoryImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlConstants.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/AbstractDoclet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/Configuration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/ModuleSummaryWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/WriterFactory.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/BuilderFactory.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ModuleSummaryBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclet.xml ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletManager.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocPaths.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/MetaKeywords.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/StandardDocFileFactory.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/DocEnv.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/JavadocClassFinder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/JavadocTool.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ToolOption.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/resources/javadoc.properties ! src/jdk.javadoc/share/classes/module-info.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/AccessFlags.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/Attribute.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/ClassWriter.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/ConcealedPackages_attribute.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/Hashes_attribute.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/MainClass_attribute.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/Module_attribute.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/Version_attribute.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/JavapTask.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap.properties ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Analyzer.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Archive.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ClassFileReader.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/DependencyFinder.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsTask.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsWriter.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Module.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleAnalyzer.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleInfoBuilder.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModulePaths.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Profile.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps.properties ! src/jdk.jdeps/share/classes/module-info.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/remote/RemoteAgent.java ! src/jdk.jshell/share/classes/jdk/jshell/ExecutionControl.java ! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java ! src/jdk.jshell/share/classes/jdk/jshell/TaskFactory.java ! test/Makefile ! test/ProblemList.txt ! test/com/sun/javadoc/testCustomTag/taglets/CustomTag.java ! test/com/sun/javadoc/testHtmlVersion/TestHtmlVersion.java ! test/com/sun/javadoc/testLinkOption/jdk/package-list ! test/com/sun/javadoc/testLinkOption/mylib/lang/StringBuilderChild.java ! test/com/sun/javadoc/testNestedInlineTag/testtaglets/BoldTaglet.java ! test/com/sun/javadoc/testNestedInlineTag/testtaglets/GreenTaglet.java ! test/com/sun/javadoc/testNestedInlineTag/testtaglets/UnderlineTaglet.java ! test/com/sun/javadoc/testSubTitle/TestSubTitle.java ! test/com/sun/javadoc/testTaglets/taglets/Foo.java ! test/jdk/javadoc/doclet/testAnnotationTypes/TestAnnotationTypes.java ! test/jdk/javadoc/doclet/testHtmlVersion/TestHtmlVersion.java ! test/jdk/javadoc/doclet/testJavaFX/TestJavaFX.java ! test/jdk/javadoc/doclet/testJavascript/TestJavascript.java ! test/jdk/javadoc/doclet/testLinkOption/TestLinkOption.java ! test/jdk/javadoc/doclet/testLinkOption/jdk/package-list ! test/jdk/javadoc/doclet/testLinkOption/mylib/lang/StringBuilderChild.java ! test/jdk/javadoc/doclet/testNavigation/TestNavigation.java ! test/jdk/javadoc/doclet/testRepeatedAnnotations/TestRepeatedAnnotations.java ! test/jdk/javadoc/doclet/testSubTitle/TestSubTitle.java ! test/jdk/javadoc/doclet/testTypeAnnotations/TestTypeAnnotations.java ! test/jdk/javadoc/tool/6227454/Test.java ! test/jdk/javadoc/tool/6964914/Test.java ! test/jdk/javadoc/tool/6964914/TestStdDoclet.java ! test/jdk/javadoc/tool/6964914/TestUserDoclet.java ! test/jdk/javadoc/tool/CheckResourceKeys.java ! test/jdk/javadoc/tool/doclint/DocLintTest.java ! test/jdk/jshell/CommandCompletionTest.java ! test/jdk/jshell/CompletionSuggestionTest.java ! test/jdk/jshell/ComputeFQNsTest.java ! test/jdk/jshell/InferTypeTest.java ! test/jdk/jshell/T8146368/JShellToolTest8146368.java ! test/jdk/jshell/ToolFormatTest.java ! test/lib/annotations/annotations/classfile/ClassfileInspector.java ! test/tools/all/RunCodingRules.java ! test/tools/doclint/tool/PathsTest.java ! test/tools/javac/6330997/T6330997.java ! test/tools/javac/6589361/T6589361.java ! test/tools/javac/6627362/T6627362.java ! test/tools/javac/ExtDirs/ExtDirTest.java ! test/tools/javac/MethodParameters/AttributeVisitor.java ! test/tools/javac/T4093617/java.base/Object.java ! test/tools/javac/T6358024.java ! test/tools/javac/T6358166.java ! test/tools/javac/T6403466.java ! test/tools/javac/T6406771.java ! test/tools/javac/T6435291/T6435291.java ! test/tools/javac/T6942649.java ! test/tools/javac/T6972327.java ! test/tools/javac/T6993301.java ! test/tools/javac/T8003967/DetectMutableStaticFields.java ! test/tools/javac/T8010737/ParameterNamesAreNotCopiedToAnonymousInitTest.java ! test/tools/javac/TryWithResources/TwrForVariable3.out ! test/tools/javac/VersionOpt.java ! test/tools/javac/annotations/SyntheticParameters.java ! test/tools/javac/annotations/typeAnnotations/TypeProcOnly.java ! test/tools/javac/annotations/typeAnnotations/packageanno/PackageProcessor.java ! test/tools/javac/api/6400303/T6400303.java ! test/tools/javac/api/6440528/T6440528.java ! test/tools/javac/api/6557752/T6557752.java ! test/tools/javac/api/T6358786.java ! test/tools/javac/api/T6412669.java ! test/tools/javac/api/TestClientCodeWrapper.java ! test/tools/javac/api/TestJavacTaskScanner.java ! test/tools/javac/api/TestResolveIdent.java ! test/tools/javac/api/TestTrees.java ! test/tools/javac/api/taskListeners/CompileEvent.java ! test/tools/javac/boxing/IncrementBoxedAndAccess.java ! test/tools/javac/cast/intersection/model/ModelChecker.java ! test/tools/javac/classfiles/attributes/Module/ModuleFlagTest.java ! test/tools/javac/classfiles/attributes/Module/ModuleTest.java ! test/tools/javac/classfiles/attributes/Module/ModuleTestBase.java ! test/tools/javac/classfiles/attributes/SourceFile/ModuleInfoTest.java ! test/tools/javac/classfiles/attributes/Synthetic/AccessToPrivateInnerClassMembersTest.java ! test/tools/javac/classfiles/attributes/Synthetic/AccessToPrivateSiblingsTest.java ! test/tools/javac/classfiles/attributes/Synthetic/AssertFieldTest.java ! test/tools/javac/classfiles/attributes/Synthetic/BridgeMethodForGenericMethodTest.java ! test/tools/javac/classfiles/attributes/Synthetic/BridgeMethodsForLambdaTest.java ! test/tools/javac/classfiles/attributes/Synthetic/EnumTest.java ! test/tools/javac/classfiles/attributes/Synthetic/PackageInfoTest.java ! test/tools/javac/classfiles/attributes/Synthetic/ThisFieldTest.java ! test/tools/javac/classfiles/attributes/annotations/RuntimeAnnotationsForGenericMethodTest.java ! test/tools/javac/classfiles/attributes/annotations/RuntimeAnnotationsForInnerAnnotationTest.java ! test/tools/javac/classfiles/attributes/annotations/RuntimeAnnotationsForInnerClassTest.java ! test/tools/javac/classfiles/attributes/annotations/RuntimeAnnotationsForInnerEnumTest.java ! test/tools/javac/classfiles/attributes/annotations/RuntimeAnnotationsForInnerInterfaceTest.java ! test/tools/javac/classfiles/attributes/annotations/RuntimeAnnotationsForTopLevelClassTest.java ! test/tools/javac/classfiles/attributes/annotations/RuntimeParameterAnnotationsForGenericMethodTest.java ! test/tools/javac/classfiles/attributes/annotations/RuntimeParameterAnnotationsForLambdaTest.java ! test/tools/javac/classfiles/attributes/annotations/RuntimeParameterAnnotationsTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerClassesTest.java ! test/tools/javac/classfiles/attributes/innerclasses/InnerEnumInInnerAnnotationTest.java ! test/tools/javac/classfiles/attributes/lib/TestResult.java ! test/tools/javac/defaultMethods/BadClassfile.java ! test/tools/javac/diags/CheckExamples.java ! test/tools/javac/diags/CheckResourceKeys.java ! test/tools/javac/diags/Example.java ! test/tools/javac/diags/examples/InvalidDefaultInterface/InvalidDefaultInterface.java ! test/tools/javac/diags/examples/InvalidDefaultInterface/processors/CreateBadClassFile.java ! test/tools/javac/diags/examples/InvalidStaticInterface/InvalidStaticInterface.java ! test/tools/javac/diags/examples/InvalidStaticInterface/processors/CreateBadClassFile.java ! test/tools/javac/fatalErrors/NoJavaLangTest.java ! test/tools/javac/file/ExplodedImage.java ! test/tools/javac/file/T7018098.java ! test/tools/javac/generics/diamond/neg/T8078473_2.java ! test/tools/javac/importscope/CompletionFailureDuringImport.java ! test/tools/javac/lib/DPrinter.java ! test/tools/javac/lib/JavacTestingAbstractProcessor.java ! test/tools/javac/lib/combo/ReusableContext.java ! test/tools/javac/modules/AbstractOrInnerClassServiceImplTest.java ! test/tools/javac/modules/AddLimitMods.java ! test/tools/javac/modules/AddReadsTest.java ! test/tools/javac/modules/AnnotationProcessing.java ! test/tools/javac/modules/AnnotationProcessorsInModulesTest.java ! test/tools/javac/modules/AutomaticModules.java ! test/tools/javac/modules/DoclintOtherModules.java ! test/tools/javac/modules/DuplicateClassTest.java ! test/tools/javac/modules/EdgeCases.java ! test/tools/javac/modules/GraphsTest.java ! test/tools/javac/modules/HelloWorldTest.java ! test/tools/javac/modules/MOptionTest.java ! test/tools/javac/modules/ModuleFinderTest.java ! test/tools/javac/modules/ModuleInfoTest.java ! test/tools/javac/modules/ModulePathTest.java ! test/tools/javac/modules/ModuleSourcePathTest.java ! test/tools/javac/modules/ModuleTestBase.java ! test/tools/javac/modules/ModulesAndClassPathTest.java ! test/tools/javac/modules/MultiModuleModeTest.java ! test/tools/javac/modules/NPEEmptyFileTest.java ! test/tools/javac/modules/OutputDirTest.java ! test/tools/javac/modules/PackageConflictTest.java ! test/tools/javac/modules/PackageMultipleModules.java ! test/tools/javac/modules/PluginsInModulesTest.java ! test/tools/javac/modules/ProvidesTest.java ! test/tools/javac/modules/QueryBeforeEnter.java ! test/tools/javac/modules/RepeatedUsesAndProvidesTest.java ! test/tools/javac/modules/ReportNonExistentPackageTest.java ! test/tools/javac/modules/RequiresPublicTest.java ! test/tools/javac/modules/ResolveTest.java ! test/tools/javac/modules/ServiceInStaticClassErrorTest.java ! test/tools/javac/modules/ServiceProvidedButNotExportedOrUsedTest.java ! test/tools/javac/modules/SingleModuleModeTest.java ! test/tools/javac/modules/SubpackageTest.java ! test/tools/javac/modules/UpgradeModulePathTest.java ! test/tools/javac/modules/UsesTest.java ! test/tools/javac/modules/XModuleTest.java ! test/tools/javac/options/modes/Tester.java ! test/tools/javac/platform/PlatformProviderTest.java ! test/tools/javac/plugin/showtype/Test.java ! test/tools/javac/processing/environment/ProcessingEnvAnnoDiscovery.java ! test/tools/javac/processing/errors/EnsureAnnotationTypeMismatchException/Processor.java ! test/tools/javac/processing/errors/EnsureMirroredTypeException/Processor.java ! test/tools/javac/processing/errors/StopOnInapplicableAnnotations/GenerateSuperInterfaceProcessor.java ! test/tools/javac/processing/loader/testClose/TestClose.java ! test/tools/javac/processing/loader/testClose/TestClose2.java ! test/tools/javac/processing/messager/MessagerDiags.java ! test/tools/javac/processing/model/TestSymtabItems.java ! test/tools/javac/processing/model/element/8009367/TestQualifiedNameUsed.java ! test/tools/javac/processing/model/element/TestEmptyContainer.java ! test/tools/javac/processing/model/element/TestMissingElement/TestMissingElement.java ! test/tools/javac/processing/model/element/TestNonInherited.java ! test/tools/javac/processing/model/inheritedByType/EnsureOrder.java ! test/tools/javac/processing/model/testgetallmembers/Main.java ! test/tools/javac/processing/model/type/BasicAnnoTests.java ! test/tools/javac/processing/rounds/OverwriteBetweenCompilations.java ! test/tools/javac/redefineObject/Object1-test.java ! test/tools/javac/redefineObject/Object1.out ! test/tools/javac/redefineObject/Object2-test.java ! test/tools/javac/redefineObject/Object2.out ! test/tools/javac/redefineObject/java.base/Object1.java ! test/tools/javac/redefineObject/java.base/Object2.java ! test/tools/javac/resolve/BitWiseOperators.java ! test/tools/javac/scope/DupUnsharedTest.java ! test/tools/javac/scope/HashCollisionTest.java ! test/tools/javac/scope/RemoveSymbolUnitTest.java ! test/tools/javac/scope/StarImportTest.java ! test/tools/javac/sym/ElementStructureTest.java ! test/tools/javac/synthesize/Main.java ! test/tools/javac/synthesize/src/Boolean.java ! test/tools/javac/synthesize/src/Byte.java ! test/tools/javac/synthesize/src/Character.java ! test/tools/javac/synthesize/src/Cloneable.java ! test/tools/javac/synthesize/src/Double.java ! test/tools/javac/synthesize/src/Float.java ! test/tools/javac/synthesize/src/Integer.java ! test/tools/javac/synthesize/src/Long.java ! test/tools/javac/synthesize/src/Number.java ! test/tools/javac/synthesize/src/Object.java ! test/tools/javac/synthesize/src/Serializable.java ! test/tools/javac/synthesize/src/Short.java ! test/tools/javac/synthesize/src/Test.java ! test/tools/javac/synthesize/src/Void.java ! test/tools/javac/tree/ArrayTypeToString.java ! test/tools/javac/tree/MakeTypeTest.java ! test/tools/javac/treeannotests/TestProcessor.java ! test/tools/javac/types/ScopeListenerTest.java ! test/tools/javac/util/T6597678.java ! test/tools/javac/warnings/VerifyLintDescriptions.java ! test/tools/javadoc/6964914/TestStdDoclet.java ! test/tools/javadoc/6964914/TestUserDoclet.java ! test/tools/javadoc/CheckResourceKeys.java ! test/tools/javah/ModuleClass.java ! test/tools/javap/classfile/6888367/T6888367.java ! test/tools/jdeps/APIDeps.java ! test/tools/jdeps/Basic.java ! test/tools/jdeps/CompilerUtils.java ! test/tools/jdeps/DotFileTest.java ! test/tools/jdeps/VerboseFormat/JdepsDependencyClosure.java ! test/tools/jdeps/VerboseFormat/use/indirect/DontUseJdkInternal2.java ! test/tools/jdeps/VerboseFormat/use/indirect/UseJdkInternalIndirectly.java ! test/tools/jdeps/VerboseFormat/use/indirect2/DontUseJdkInternal3.java ! test/tools/jdeps/VerboseFormat/use/indirect2/UseJdkInternalIndirectly2.java ! test/tools/jdeps/VerboseFormat/use/internal/DontUseJdkInternal.java ! test/tools/jdeps/VerboseFormat/use/internal/UseClassWithJdkInternal.java ! test/tools/jdeps/VerboseFormat/use/internal/UseJdkInternalClass.java ! test/tools/jdeps/VerboseFormat/use/internal/UseJdkInternalClass2.java ! test/tools/jdeps/f/F.java ! test/tools/jdeps/modules/GenModuleInfo.java ! test/tools/lib/ToolBox.java ! test/tools/sjavac/OverlappingSrcDst.java From alan.bateman at oracle.com Thu Mar 24 08:52:05 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 24 Mar 2016 08:52:05 +0000 Subject: hg: jigsaw/jake/jdk: 3 new changesets Message-ID: <201603240852.u2O8q62i001400@aojmv0008.oracle.com> Changeset: b2a69d66dc65 Author: alanb Date: 2016-03-17 19:04 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b2a69d66dc65 8142968: Module System implementation Summary: Initial integration of JEP 200, JEP 260, JEP 261, and JEP 282 Reviewed-by: alanb, mchung, naoto, rriggs, psandoz, plevart, mullan, ascarpino, vinnie, prr, sherman, dfuchs, mhaupt Contributed-by: alan.bateman at oracle.com, alex.buckley at oracle.com, jonathan.gibbons at oracle.com, karen.kinnear at oracle.com, mandy.chung at oracle.com, mark.reinhold at oracle.com, chris.hegarty at oracle.com, alexandr.scherbatiy at oracle.com, amy.lu at oracle.com, calvin.cheung at oracle.com, daniel.fuchs at oracle.com, erik.joelsson at oracle.com, harold.seigel at oracle.com, jaroslav.bachorik at oracle.com, jean-francois.denise at oracle.com, jan.lahoda at oracle.com, james.laskey at oracle.com, lois.foltan at oracle.com, miroslav.kos at oracle.com, huaming.li at oracle.com, sean.mullan at oracle.com, naoto.sato at oracle.com, masayoshi.okutsu at oracle.com, peter.levart at gmail.com, philip.race at oracle.com, claes.redestad at oracle.com, sergey.bylokhov at oracle.com, alexandre.iline at oracle.com, volker.simonis at gmail.com, staffan.larsen at oracle.com, stuart.marks at oracle.com, semyon.sadetsky at oracle.com, serguei.spitsyn at oracle.com, sundararajan.athijegannathan at oracle.com, valerie.peng at oracle.com, vincent.x.ryan at oracle.com, weijun.wang at oracle.co! m, yuri.nesterenko at oracle.com, yekaterina.kantserova at oracle.com, alexander.kulyakhtin at oracle.com, felix.yang at oracle.com, andrei.eremeev at oracle.com, frank.yuan at oracle.com, sergei.pikalev at oracle.com, sibabrata.sahoo at oracle.com, tiantian.du at oracle.com, sha.jiang at oracle.com ! make/CompileInterimRmic.gmk ! make/CompileTools.gmk + make/GenerateModuleSummary.gmk + make/ModuleTools.gmk ! make/Tools.gmk ! make/copy/Copy-java.base.gmk ! make/data/jdwp/jdwp.spec - make/gendata/Gendata-jdk.jdeps.gmk ! make/gendata/GendataBreakIterator.gmk ! make/gensrc/Gensrc-java.base.gmk - make/gensrc/Gensrc-jdk.dev.gmk ! make/gensrc/Gensrc-jdk.jdi.gmk + make/gensrc/Gensrc-jdk.jlink.gmk - make/gensrc/Gensrc-jdk.jvmstat.gmk ! make/gensrc/GensrcLocaleData.gmk + make/gensrc/GensrcModuleLoaderMap.gmk ! make/launcher/Launcher-java.desktop.gmk - make/launcher/Launcher-jdk.dev.gmk + make/launcher/Launcher-jdk.jlink.gmk ! make/launcher/Launcher-jdk.pack200.gmk ! make/launcher/Launcher-jdk.rmic.gmk ! make/launcher/LauncherCommon.gmk ! make/lib/CoreLibraries.gmk ! make/lib/Lib-java.instrument.gmk ! make/mapfiles/libjava/mapfile-vers ! make/mapfiles/libjimage/mapfile-vers ! make/rmic/Rmic-java.management.gmk ! make/rmic/RmicCommon.gmk - make/scripts/localelist.sh ! make/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java ! make/src/classes/build/tools/generatebreakiteratordata/GenerateBreakIteratorData.java + make/src/classes/build/tools/jdwpgen/ModuleTypeNode.java ! make/src/classes/build/tools/jdwpgen/Parse.java + make/src/classes/build/tools/jigsaw/GenGraphs.java + make/src/classes/build/tools/jigsaw/Graph.java + make/src/classes/build/tools/jigsaw/ModuleSummary.java + make/src/classes/build/tools/jigsaw/technology-summary.html - make/src/classes/build/tools/module/GenJdepsModulesXml.java + make/src/classes/build/tools/module/GenModuleInfoSource.java + make/src/classes/build/tools/module/GenModuleLoaderMap.java - make/src/classes/build/tools/module/GenModulesList.java - make/src/classes/build/tools/module/ImageBuilder.java ! make/src/classes/build/tools/module/Module.java - make/src/classes/build/tools/module/ModuleArchive.java + make/src/classes/build/tools/module/ModuleInfoReader.java - make/src/classes/build/tools/module/boot.modules - make/src/classes/build/tools/module/ext.modules ! src/demo/share/java2d/J2DBench/src/j2dbench/ResultSet.java + src/java.base/macosx/classes/module-info.java.extra ! src/java.base/share/classes/com/sun/java/util/jar/pack/intrinsic.properties ! src/java.base/share/classes/java/io/ObjectInputStream.java ! 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/NamedPackage.java ! src/java.base/share/classes/java/lang/Package.java ! src/java.base/share/classes/java/lang/StackFrameInfo.java ! src/java.base/share/classes/java/lang/StackTraceElement.java ! src/java.base/share/classes/java/lang/StackWalker.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/java.base/share/classes/java/lang/invoke/MemberName.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java + src/java.base/share/classes/java/lang/module/Configuration.java + src/java.base/share/classes/java/lang/module/Dependence.java + src/java.base/share/classes/java/lang/module/FindException.java + src/java.base/share/classes/java/lang/module/InvalidModuleDescriptorException.java + src/java.base/share/classes/java/lang/module/ModuleDescriptor.java + src/java.base/share/classes/java/lang/module/ModuleFinder.java + src/java.base/share/classes/java/lang/module/ModuleInfo.java + src/java.base/share/classes/java/lang/module/ModulePath.java + src/java.base/share/classes/java/lang/module/ModuleReader.java + src/java.base/share/classes/java/lang/module/ModuleReference.java + src/java.base/share/classes/java/lang/module/ModuleReferences.java + src/java.base/share/classes/java/lang/module/ResolutionException.java + src/java.base/share/classes/java/lang/module/ResolvedModule.java + src/java.base/share/classes/java/lang/module/Resolver.java + src/java.base/share/classes/java/lang/module/SystemModuleFinder.java + src/java.base/share/classes/java/lang/module/package-info.java ! src/java.base/share/classes/java/lang/ref/Finalizer.java ! src/java.base/share/classes/java/lang/reflect/AccessibleObject.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/InaccessibleObjectException.java + src/java.base/share/classes/java/lang/reflect/Layer.java + src/java.base/share/classes/java/lang/reflect/LayerInstantiationException.java ! src/java.base/share/classes/java/lang/reflect/Method.java + src/java.base/share/classes/java/lang/reflect/Module.java ! src/java.base/share/classes/java/lang/reflect/Proxy.java ! src/java.base/share/classes/java/lang/reflect/package-info.java ! src/java.base/share/classes/java/net/URL.java ! src/java.base/share/classes/java/net/URLClassLoader.java ! src/java.base/share/classes/java/nio/Bits.java ! src/java.base/share/classes/java/nio/file/FileSystems.java ! src/java.base/share/classes/java/nio/file/Files.java ! src/java.base/share/classes/java/util/ResourceBundle.java ! src/java.base/share/classes/java/util/ServiceLoader.java + src/java.base/share/classes/java/util/spi/AbstractResourceBundleProvider.java ! src/java.base/share/classes/java/util/spi/ResourceBundleControlProvider.java + src/java.base/share/classes/java/util/spi/ResourceBundleProvider.java ! src/java.base/share/classes/javax/crypto/JceSecurity.java ! src/java.base/share/classes/javax/crypto/SealedObject.java - src/java.base/share/classes/jdk/internal/jimage/Archive.java ! src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java - src/java.base/share/classes/jdk/internal/jimage/BasicImageWriter.java - src/java.base/share/classes/jdk/internal/jimage/ExternalFilesWriter.java ! src/java.base/share/classes/jdk/internal/jimage/ImageBufferCache.java - src/java.base/share/classes/jdk/internal/jimage/ImageFileCreator.java ! src/java.base/share/classes/jdk/internal/jimage/ImageHeader.java - src/java.base/share/classes/jdk/internal/jimage/ImageJavaSubstrate.java ! src/java.base/share/classes/jdk/internal/jimage/ImageLocation.java - src/java.base/share/classes/jdk/internal/jimage/ImageLocationBase.java - src/java.base/share/classes/jdk/internal/jimage/ImageLocationWriter.java - src/java.base/share/classes/jdk/internal/jimage/ImageModuleData.java - src/java.base/share/classes/jdk/internal/jimage/ImageModuleDataWriter.java - src/java.base/share/classes/jdk/internal/jimage/ImageNativeSubstrate.java ! src/java.base/share/classes/jdk/internal/jimage/ImageReader.java ! src/java.base/share/classes/jdk/internal/jimage/ImageReaderFactory.java - src/java.base/share/classes/jdk/internal/jimage/ImageResourcesTree.java ! src/java.base/share/classes/jdk/internal/jimage/ImageStream.java ! src/java.base/share/classes/jdk/internal/jimage/ImageStrings.java ! src/java.base/share/classes/jdk/internal/jimage/ImageStringsReader.java - src/java.base/share/classes/jdk/internal/jimage/ImageStringsWriter.java - src/java.base/share/classes/jdk/internal/jimage/ImageSubstrate.java + src/java.base/share/classes/jdk/internal/jimage/NativeImageBuffer.java - src/java.base/share/classes/jdk/internal/jimage/PerfectHashBuilder.java - src/java.base/share/classes/jdk/internal/jimage/ResourcePool.java - src/java.base/share/classes/jdk/internal/jimage/ResourcePoolImpl.java - src/java.base/share/classes/jdk/internal/jimage/StringTable.java - src/java.base/share/classes/jdk/internal/jimage/UTF8String.java + src/java.base/share/classes/jdk/internal/jimage/decompressor/CompressIndexes.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/CompressedResourceHeader.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/Decompressor.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/ResourceDecompressor.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/ResourceDecompressorFactory.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/ResourceDecompressorRepository.java + src/java.base/share/classes/jdk/internal/jimage/decompressor/SignatureParser.java + src/java.base/share/classes/jdk/internal/jimage/decompressor/StringSharingDecompressor.java + src/java.base/share/classes/jdk/internal/jimage/decompressor/StringSharingDecompressorFactory.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/ZipDecompressor.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/ZipDecompressorFactory.java + src/java.base/share/classes/jdk/internal/jrtfs/AbstractJrtFileAttributes.java + src/java.base/share/classes/jdk/internal/jrtfs/AbstractJrtFileSystem.java + src/java.base/share/classes/jdk/internal/jrtfs/AbstractJrtPath.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtDirectoryStream.java + src/java.base/share/classes/jdk/internal/jrtfs/JrtExplodedFileAttributes.java + src/java.base/share/classes/jdk/internal/jrtfs/JrtExplodedFileSystem.java + src/java.base/share/classes/jdk/internal/jrtfs/JrtExplodedPath.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtFileAttributeView.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtFileAttributes.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtFileStore.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtFileSystem.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtFileSystemProvider.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtPath.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtUtils.java ! src/java.base/share/classes/jdk/internal/jrtfs/SystemImages.java ! src/java.base/share/classes/jdk/internal/jrtfs/jrtfsviewer.js ! src/java.base/share/classes/jdk/internal/jrtfs/jrtls.js + src/java.base/share/classes/jdk/internal/loader/BootLoader.java + src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java + src/java.base/share/classes/jdk/internal/loader/ClassLoaders.java + src/java.base/share/classes/jdk/internal/loader/Loader.java + src/java.base/share/classes/jdk/internal/loader/LoaderPool.java ! src/java.base/share/classes/jdk/internal/misc/JavaLangAccess.java + src/java.base/share/classes/jdk/internal/misc/JavaLangModuleAccess.java + src/java.base/share/classes/jdk/internal/misc/JavaLangReflectModuleAccess.java + src/java.base/share/classes/jdk/internal/misc/JavaUtilResourceBundleAccess.java ! src/java.base/share/classes/jdk/internal/misc/SharedSecrets.java ! src/java.base/share/classes/jdk/internal/misc/VM.java + src/java.base/share/classes/jdk/internal/module/Builder.java + src/java.base/share/classes/jdk/internal/module/Checks.java + src/java.base/share/classes/jdk/internal/module/ClassFileAttributes.java + src/java.base/share/classes/jdk/internal/module/ClassFileConstants.java + src/java.base/share/classes/jdk/internal/module/ConfigurableModuleFinder.java + src/java.base/share/classes/jdk/internal/module/Hasher.java + src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java + src/java.base/share/classes/jdk/internal/module/ModuleInfoExtender.java + src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java + src/java.base/share/classes/jdk/internal/module/ModuleLoaderMap.java + src/java.base/share/classes/jdk/internal/module/ModulePatcher.java + src/java.base/share/classes/jdk/internal/module/Modules.java + src/java.base/share/classes/jdk/internal/module/ServicesCatalog.java + src/java.base/share/classes/jdk/internal/module/SystemModules.java ! src/java.base/share/classes/jdk/internal/perf/PerfCounter.java + src/java.base/share/classes/jdk/internal/vm/cds/resources/ModuleLoaderMap.dat + src/java.base/share/classes/module-info.java ! src/java.base/share/classes/sun/invoke/util/VerifyAccess.java ! src/java.base/share/classes/sun/launcher/LauncherHelper.java ! src/java.base/share/classes/sun/launcher/resources/launcher.properties - src/java.base/share/classes/sun/misc/Launcher.java ! src/java.base/share/classes/sun/misc/URLClassPath.java + src/java.base/share/classes/sun/net/www/protocol/jmod/Handler.java ! src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java ! src/java.base/share/classes/sun/reflect/Reflection.java ! src/java.base/share/classes/sun/reflect/misc/MethodUtil.java ! src/java.base/share/classes/sun/reflect/misc/ReflectUtil.java ! src/java.base/share/classes/sun/security/jca/ProviderList.java ! src/java.base/share/classes/sun/security/jca/Providers.java ! src/java.base/share/classes/sun/security/provider/PolicyFile.java ! src/java.base/share/classes/sun/security/util/SecurityConstants.java + src/java.base/share/classes/sun/text/resources/BreakIteratorInfoProvider.java + src/java.base/share/classes/sun/text/resources/BreakIteratorRulesProvider.java + src/java.base/share/classes/sun/text/resources/CollationDataProvider.java + src/java.base/share/classes/sun/text/resources/FormatDataProvider.java + src/java.base/share/classes/sun/text/resources/JavaTimeSupplementaryProvider.java + src/java.base/share/classes/sun/text/resources/cldr/FormatDataProvider.java - src/java.base/share/classes/sun/util/CoreResourceBundleControl-XLocales.java.template ! src/java.base/share/classes/sun/util/locale/provider/BreakDictionary.java ! src/java.base/share/classes/sun/util/locale/provider/BreakIteratorProviderImpl.java ! src/java.base/share/classes/sun/util/locale/provider/DictionaryBasedBreakIterator.java ! src/java.base/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java ! src/java.base/share/classes/sun/util/locale/provider/LocaleResources.java + src/java.base/share/classes/sun/util/locale/provider/ResourceBundleProviderSupport.java ! src/java.base/share/classes/sun/util/locale/provider/RuleBasedBreakIterator.java + src/java.base/share/classes/sun/util/resources/Bundles.java + src/java.base/share/classes/sun/util/resources/CalendarDataProvider.java + src/java.base/share/classes/sun/util/resources/CurrencyNamesProvider.java ! src/java.base/share/classes/sun/util/resources/LocaleData.java + src/java.base/share/classes/sun/util/resources/LocaleDataProvider.java + src/java.base/share/classes/sun/util/resources/LocaleNamesProvider.java + src/java.base/share/classes/sun/util/resources/TimeZoneNamesProvider.java + src/java.base/share/classes/sun/util/resources/cldr/CalendarDataProvider.java + src/java.base/share/classes/sun/util/resources/cldr/CurrencyNamesProvider.java + src/java.base/share/classes/sun/util/resources/cldr/LocaleNamesProvider.java + src/java.base/share/classes/sun/util/resources/cldr/TimeZoneNamesProvider.java ! src/java.base/share/conf/security/java.policy ! src/java.base/share/conf/security/java.security ! src/java.base/share/native/include/jni.h ! src/java.base/share/native/include/jvm.h ! src/java.base/share/native/include/jvmti.h ! src/java.base/share/native/launcher/defines.h ! src/java.base/share/native/launcher/main.c + src/java.base/share/native/libjava/BootLoader.c + src/java.base/share/native/libjava/Module.c - src/java.base/share/native/libjava/Package.c - src/java.base/share/native/libjava/Proxy.c ! src/java.base/share/native/libjava/Reflection.c - src/java.base/share/native/libjimage/ImageNativeSubstrate.cpp + src/java.base/share/native/libjimage/NativeImageBuffer.cpp ! src/java.base/share/native/libjimage/imageDecompressor.cpp ! src/java.base/share/native/libjimage/imageDecompressor.hpp ! src/java.base/share/native/libjimage/imageFile.cpp ! src/java.base/share/native/libjimage/imageFile.hpp ! src/java.base/share/native/libjimage/jimage.cpp ! src/java.base/share/native/libjimage/jimage.hpp ! src/java.base/share/native/libjli/args.c ! src/java.base/share/native/libjli/emessages.h ! src/java.base/share/native/libjli/java.c ! src/java.base/share/native/libjli/java.h + src/java.base/solaris/classes/module-info.java.extra + src/java.base/windows/classes/module-info.java.extra + src/java.compact1/share/classes/module-info.java + src/java.compact2/share/classes/module-info.java + src/java.compact3/share/classes/module-info.java + src/java.datatransfer/share/classes/module-info.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaUtils.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/LWCToolkit.java - src/java.desktop/share/classes/META-INF/services/java.net.ContentHandlerFactory - src/java.desktop/share/classes/META-INF/services/javax.print.PrintServiceLookup - src/java.desktop/share/classes/META-INF/services/javax.print.StreamPrintServiceFactory - src/java.desktop/share/classes/META-INF/services/javax.sound.midi.spi.MidiDeviceProvider - src/java.desktop/share/classes/META-INF/services/javax.sound.midi.spi.MidiFileReader - src/java.desktop/share/classes/META-INF/services/javax.sound.midi.spi.MidiFileWriter - src/java.desktop/share/classes/META-INF/services/javax.sound.midi.spi.SoundbankReader - src/java.desktop/share/classes/META-INF/services/javax.sound.sampled.spi.AudioFileReader - src/java.desktop/share/classes/META-INF/services/javax.sound.sampled.spi.AudioFileWriter - src/java.desktop/share/classes/META-INF/services/javax.sound.sampled.spi.FormatConversionProvider - src/java.desktop/share/classes/META-INF/services/javax.sound.sampled.spi.MixerProvider - src/java.desktop/share/classes/META-INF/services/sun.datatransfer.DesktopDatatransferService ! src/java.desktop/share/classes/com/sun/beans/finder/ConstructorFinder.java ! src/java.desktop/share/classes/com/sun/beans/finder/FieldFinder.java + src/java.desktop/share/classes/com/sun/beans/finder/FinderUtils.java ! src/java.desktop/share/classes/com/sun/beans/finder/MethodFinder.java ! src/java.desktop/share/classes/com/sun/media/sound/JARSoundbankReader.java ! src/java.desktop/share/classes/java/awt/Component.java ! src/java.desktop/share/classes/java/awt/Toolkit.java ! src/java.desktop/share/classes/java/awt/Window.java ! src/java.desktop/share/classes/javax/imageio/ImageReader.java ! src/java.desktop/share/classes/javax/imageio/ImageWriter.java ! src/java.desktop/share/classes/javax/imageio/metadata/IIOMetadata.java ! src/java.desktop/share/classes/javax/imageio/metadata/IIOMetadataFormat.java ! src/java.desktop/share/classes/javax/imageio/metadata/IIOMetadataFormatImpl.java ! src/java.desktop/share/classes/javax/imageio/spi/ImageReaderWriterSpi.java ! src/java.desktop/share/classes/javax/swing/UIDefaults.java ! src/java.desktop/share/classes/javax/swing/text/DefaultFormatter.java ! src/java.desktop/share/classes/javax/swing/text/html/ObjectView.java + src/java.desktop/share/classes/module-info.java ! src/java.desktop/share/classes/sun/applet/AppletSecurity.java ! src/java.desktop/share/classes/sun/awt/datatransfer/TransferableProxy.java + src/java.httpclient/share/classes/module-info.java ! src/java.instrument/share/classes/java/lang/instrument/ClassFileTransformer.java ! src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java ! src/java.instrument/share/classes/java/lang/instrument/package.html + src/java.instrument/share/classes/module-info.java ! src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java ! src/java.instrument/share/classes/sun/instrument/TransformerManager.java ! src/java.instrument/share/native/libinstrument/JPLISAgent.c ! src/java.instrument/share/native/libinstrument/JPLISAgent.h - src/java.logging/share/classes/META-INF/services/jdk.internal.logger.DefaultLoggerFinder ! src/java.logging/share/classes/java/util/logging/Level.java ! src/java.logging/share/classes/java/util/logging/Logger.java + src/java.logging/share/classes/module-info.java ! src/java.management/share/classes/javax/management/remote/rmi/RMIConnector.java + src/java.management/share/classes/module-info.java ! src/java.management/share/classes/sun/management/RuntimeImpl.java ! src/java.management/share/classes/sun/management/StackTraceElementCompositeData.java ! src/java.management/share/classes/sun/management/ThreadInfoCompositeData.java + src/java.management/share/classes/sun/management/TypeVersionMapper.java ! src/java.management/share/classes/sun/management/VMManagementImpl.java ! src/java.management/share/native/include/jmm.h ! src/java.management/share/native/libmanagement/VMManagementImpl.c ! src/java.naming/share/classes/com/sun/jndi/ldap/Obj.java ! src/java.naming/share/classes/com/sun/naming/internal/VersionHelper.java ! src/java.naming/share/classes/javax/naming/ldap/ControlFactory.java ! src/java.naming/share/classes/javax/naming/spi/NamingManager.java ! src/java.naming/share/classes/javax/naming/spi/ObjectFactory.java ! src/java.naming/share/classes/javax/naming/spi/StateFactory.java + src/java.naming/share/classes/module-info.java ! src/java.naming/share/classes/sun/security/provider/certpath/ldap/LDAPCertStoreImpl.java + src/java.prefs/share/classes/module-info.java ! src/java.rmi/share/classes/java/rmi/activation/ActivationID.java + src/java.rmi/share/classes/module-info.java ! src/java.scripting/share/classes/com/sun/tools/script/shell/Main.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.security.jgss/share/classes/META-INF/services/sun.security.ssl.ClientKeyExchangeService + 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/com/sun/rowset/CachedRowSetImpl.java ! src/java.sql.rowset/share/classes/com/sun/rowset/JdbcRowSetResourceBundle.java ! src/java.sql.rowset/share/classes/com/sun/rowset/internal/CachedRowSetWriter.java ! src/java.sql.rowset/share/classes/javax/sql/rowset/RowSetProvider.java ! src/java.sql.rowset/share/classes/javax/sql/rowset/serial/SQLInputImpl.java ! src/java.sql.rowset/share/classes/javax/sql/rowset/spi/SyncFactory.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.accessibility/windows/classes/META-INF/services/javax.accessibility.AccessibilityProvider + src/jdk.accessibility/windows/classes/module-info.java.extra - src/jdk.attach/share/classes/META-INF/services/com.sun.tools.attach.spi.AttachProvider + src/jdk.attach/share/classes/module-info.java - src/jdk.charsets/share/classes/META-INF/services/java.nio.charset.spi.CharsetProvider + src/jdk.charsets/share/classes/module-info.java ! src/jdk.compiler/share/classes/sun/tools/serialver/SerialVer.java + src/jdk.crypto.ec/share/classes/module-info.java + src/jdk.crypto.mscapi/windows/classes/module-info.java ! src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/RSAKeyPairGenerator.java + src/jdk.crypto.pkcs11/share/classes/module-info.java ! src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/SunPKCS11.java + src/jdk.crypto.ucrypto/solaris/classes/module-info.java + src/jdk.deploy.osx/macosx/classes/module-info.java - src/jdk.dev/share/classes/jdk/tools/jimage/ExtractedImage.java - src/jdk.dev/share/classes/jdk/tools/jimage/JImageTask.java - src/jdk.dev/share/classes/jdk/tools/jimage/Main.java - src/jdk.dev/share/classes/jdk/tools/jimage/TaskHelper.java - src/jdk.dev/share/classes/jdk/tools/jimage/resources/jimage.properties + src/jdk.httpserver/share/classes/module-info.java + src/jdk.internal.le/share/classes/module-info.java + src/jdk.internal.opt/share/classes/module-info.java + src/jdk.jartool/share/classes/module-info.java + src/jdk.jartool/share/classes/sun/tools/jar/GNUStyleOptions.java ! src/jdk.jartool/share/classes/sun/tools/jar/Main.java ! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties + src/jdk.jcmd/share/classes/jdk/internal/vm/agent/spi/ToolProvider.java + src/jdk.jcmd/share/classes/jdk/internal/vm/agent/spi/ToolProviderFinder.java + src/jdk.jcmd/share/classes/module-info.java ! src/jdk.jcmd/share/classes/sun/tools/jinfo/JInfo.java ! src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java ! src/jdk.jcmd/share/classes/sun/tools/jstack/JStack.java + src/jdk.jconsole/share/classes/module-info.java - src/jdk.jdi/share/classes/META-INF/services/com.sun.jdi.connect.Connector - src/jdk.jdi/share/classes/META-INF/services/com.sun.jdi.connect.spi.TransportService + src/jdk.jdi/share/classes/com/sun/jdi/InvalidModuleException.java + src/jdk.jdi/share/classes/com/sun/jdi/ModuleReference.java ! src/jdk.jdi/share/classes/com/sun/jdi/ReferenceType.java ! src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/JDWPException.java + src/jdk.jdi/share/classes/com/sun/tools/jdi/ModuleReferenceImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/PacketStream.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ReferenceTypeImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java + src/jdk.jdi/share/classes/module-info.java + src/jdk.jdi/windows/classes/module-info.java.extra + src/jdk.jdwp.agent/share/classes/module-info.java ! src/jdk.jdwp.agent/share/native/libjdwp/JDWP.h + src/jdk.jdwp.agent/share/native/libjdwp/ModuleReferenceImpl.c + src/jdk.jdwp.agent/share/native/libjdwp/ModuleReferenceImpl.h ! src/jdk.jdwp.agent/share/native/libjdwp/ReferenceTypeImpl.c ! src/jdk.jdwp.agent/share/native/libjdwp/VirtualMachineImpl.c ! src/jdk.jdwp.agent/share/native/libjdwp/debugDispatch.c ! src/jdk.jdwp.agent/share/native/libjdwp/inStream.c ! src/jdk.jdwp.agent/share/native/libjdwp/inStream.h ! src/jdk.jdwp.agent/share/native/libjdwp/outStream.c ! src/jdk.jdwp.agent/share/native/libjdwp/outStream.h ! src/jdk.jdwp.agent/share/native/libjdwp/util.c ! src/jdk.jdwp.agent/share/native/libjdwp/util.h + src/jdk.jlink/share/classes/jdk/tools/jimage/ExtractedImage.java + src/jdk.jlink/share/classes/jdk/tools/jimage/JImageTask.java + src/jdk.jlink/share/classes/jdk/tools/jimage/Main.java + src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage.properties + src/jdk.jlink/share/classes/jdk/tools/jlink/Jlink.java + src/jdk.jlink/share/classes/jdk/tools/jlink/JlinkPermission.java + src/jdk.jlink/share/classes/jdk/tools/jlink/builder/DefaultImageBuilder.java + src/jdk.jlink/share/classes/jdk/tools/jlink/builder/ImageBuilder.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Archive.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/BasicImageWriter.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/DirArchive.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageFileCreator.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageLocationWriter.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginConfiguration.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginStack.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageResourcesTree.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageStringsWriter.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JarArchive.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JmodArchive.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Main.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ModularJarArchive.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/PerfectHashBuilder.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/PluginContextImpl.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/PluginOrderingGraph.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/PluginRepository.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/PoolImpl.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ResourcePrevisitor.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/StringTable.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Utils.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/DefaultCompressPlugin.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ExcludeFilesPlugin.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ExcludePlugin.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ExcludeVMPlugin.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/FileCopierPlugin.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/IncludeLocalesPlugin.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/OptimizationPlugin.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/PluginsResourceBundle.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ReleaseInfoPlugin.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ResourceFilter.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SortResourcesPlugin.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/StringSharingPlugin.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/StripDebugPlugin.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/StripNativeCommandsPlugin.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModuleDescriptorPlugin.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ZipPlugin.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/asm/AsmGlobalPool.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/asm/AsmModulePool.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/asm/AsmPlugin.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/asm/AsmPool.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/asm/AsmPoolImpl.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/asm/AsmPools.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/optim/ControlFlow.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/optim/ForNameFolding.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/optim/ReflectionOptimizer.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/optim/Utils.java + src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/ExecutableImage.java + src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/Plugin.java + src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/PluginContext.java + src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/PluginException.java + src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/Pool.java + src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/PostProcessorPlugin.java + src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/TransformerPlugin.java + src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties + src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties + src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java + src/jdk.jlink/share/classes/jdk/tools/jmod/Main.java + src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod.properties + src/jdk.jlink/share/classes/module-info.java + src/jdk.jsobject/share/classes/module-info.java - src/jdk.jvmstat.rmi/share/classes/META-INF/services/sun.jvmstat.monitor.MonitoredHostService + src/jdk.jvmstat.rmi/share/classes/module-info.java - src/jdk.jvmstat/share/classes/META-INF/services/sun.jvmstat.monitor.MonitoredHostService + src/jdk.jvmstat/share/classes/module-info.java - src/jdk.localedata/share/classes/META-INF/services/sun.util.locale.provider.LocaleDataMetaInfo + src/jdk.localedata/share/classes/module-info.java + src/jdk.localedata/share/classes/sun/util/resources/provider/LocaleDataProvider.java + src/jdk.localedata/share/classes/sun/util/resources/provider/SupplementaryLocaleDataProvider.java - src/jdk.management/share/classes/META-INF/services/sun.management.spi.PlatformMBeanProvider + src/jdk.management/share/classes/module-info.java - src/jdk.naming.dns/share/classes/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor + src/jdk.naming.dns/share/classes/module-info.java + src/jdk.naming.rmi/share/classes/module-info.java + src/jdk.pack200/share/classes/module-info.java + src/jdk.policytool/share/classes/module-info.java + src/jdk.rmic/share/classes/jdk/rmi/rmic/Main.java + src/jdk.rmic/share/classes/module-info.java ! src/jdk.rmic/share/classes/sun/rmi/rmic/BatchEnvironment.java ! src/jdk.rmic/share/classes/sun/tools/java/ClassPath.java + src/jdk.sctp/share/classes/module-info.java ! src/jdk.security.auth/share/classes/com/sun/security/auth/SolarisNumericGroupPrincipal.java ! src/jdk.security.auth/share/classes/com/sun/security/auth/SolarisNumericUserPrincipal.java ! src/jdk.security.auth/share/classes/com/sun/security/auth/SolarisPrincipal.java ! src/jdk.security.auth/share/classes/com/sun/security/auth/X500Principal.java ! src/jdk.security.auth/share/classes/com/sun/security/auth/module/JndiLoginModule.java ! src/jdk.security.auth/share/classes/com/sun/security/auth/module/KeyStoreLoginModule.java ! src/jdk.security.auth/share/classes/com/sun/security/auth/module/Krb5LoginModule.java ! src/jdk.security.auth/share/classes/com/sun/security/auth/module/LdapLoginModule.java + src/jdk.security.auth/share/classes/module-info.java + src/jdk.security.jgss/share/classes/module-info.java - src/jdk.zipfs/share/classes/META-INF/services/java.nio.file.spi.FileSystemProvider + src/jdk.zipfs/share/classes/module-info.java ! test/Makefile ! test/ProblemList.txt ! test/TEST.ROOT ! test/TEST.groups ! test/com/sun/jdi/EarlyReturnNegativeTest.java ! test/com/sun/jdi/EarlyReturnTest.java ! test/com/sun/jdi/ImmutableResourceTest.sh ! test/com/sun/jdi/MethodExitReturnValuesTest.java + test/com/sun/jdi/ModulesTest.java ! test/com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java ! test/java/awt/Focus/AutoRequestFocusTest/AutoRequestFocusToFrontTest.java ! test/java/awt/Focus/FocusEmbeddedFrameTest/FocusEmbeddedFrameTest.java ! test/java/awt/Mixing/AWT_Mixing/JButtonInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JButtonOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JColorChooserOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JEditorPaneInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JEditorPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JLabelInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JLabelOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JListInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JListOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JPanelInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JPanelOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JProgressBarInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JProgressBarOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JScrollBarInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JScrollBarOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JSliderInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JSliderOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JSpinnerInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JSpinnerOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JTableInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JTableOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JTextAreaInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JTextAreaOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JTextFieldInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JTextFieldOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JToggleButtonInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JToggleButtonOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/MixingFrameResizing.java ! test/java/awt/Mixing/AWT_Mixing/OverlappingTestBase.java ! test/java/awt/Toolkit/Headless/WrappedToolkitTest/WrappedToolkitTest.sh ! test/java/awt/TrayIcon/ActionCommand/ActionCommand.java ! test/java/awt/TrayIcon/ActionEventMask/ActionEventMask.java ! test/java/awt/TrayIcon/ModalityTest/ModalityTest.java ! test/java/awt/TrayIcon/MouseEventMask/MouseEventMaskTest.java ! test/java/awt/TrayIcon/SecurityCheck/FunctionalityCheck/FunctionalityCheck.java ! test/java/awt/TrayIcon/SystemTrayIconHelper.java ! test/java/awt/TrayIcon/TrayIconEventModifiers/TrayIconEventModifiersTest.java ! test/java/awt/TrayIcon/TrayIconEvents/TrayIconEventsTest.java ! test/java/awt/TrayIcon/TrayIconMouseTest/TrayIconMouseTest.java ! test/java/awt/TrayIcon/TrayIconPopup/TrayIconPopupTest.java + test/java/awt/datatransfer/ConstructFlavoredObjectTest/ConstructFlavoredObjectTest.java + test/java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java ! test/java/awt/grab/EmbeddedFrameTest1/EmbeddedFrameTest1.java + test/java/awt/patchlib/java.desktop/java/awt/Helper.java ! test/java/awt/regtesthelpers/Util.java ! test/java/awt/regtesthelpers/UtilInternal.java ! test/java/awt/xembed/server/TesterClient.java ! test/java/beans/XMLEncoder/sun_swing_PrintColorUIResource.java + test/java/lang/Class/Foo.java + test/java/lang/Class/GetModuleTest.java + test/java/lang/Class/GetPackageTest.java + test/java/lang/Class/forName/modules/TestDriver.java + test/java/lang/Class/forName/modules/TestLayer.java + test/java/lang/Class/forName/modules/TestMain.java + test/java/lang/Class/forName/modules/policy + test/java/lang/Class/forName/modules/policy.denied + test/java/lang/Class/forName/modules/src/m1/module-info.java + test/java/lang/Class/forName/modules/src/m1/p1/A.java + test/java/lang/Class/forName/modules/src/m1/p1/Initializer.java + test/java/lang/Class/forName/modules/src/m1/p1/internal/B.java + test/java/lang/Class/forName/modules/src/m2/module-info.java + test/java/lang/Class/forName/modules/src/m2/p2/C.java + test/java/lang/Class/forName/modules/src/m2/p2/test/Main.java + test/java/lang/Class/forName/modules/src/m3/module-info.java + test/java/lang/Class/forName/modules/src/m3/p3/NoAccess.java + test/java/lang/Class/forName/modules/src/m3/p3/NoGetClassLoaderAccess.java + test/java/lang/Class/forName/modules/src/m3/p3/internal/Foo.java ! test/java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java + test/java/lang/Class/getPackageName/Basic.java + test/java/lang/Class/getResource/Main.java + test/java/lang/Class/getResource/ResourcesTest.java + test/java/lang/Class/getResource/src/m1/module-info.java + test/java/lang/Class/getResource/src/m1/p1/Main.java + test/java/lang/Class/getResource/src/m2/module-info.java + test/java/lang/Class/getResource/src/m2/p2/Main.java + test/java/lang/Class/getResource/src/m3/module-info.java + test/java/lang/Class/getResource/src/m3/p3/Main.java ! test/java/lang/ClassLoader/GetSystemPackage.java ! test/java/lang/ClassLoader/findSystemClass/Loader.java ! test/java/lang/ClassLoader/getResource/GetResource.sh + test/java/lang/ClassLoader/getResource/modules/Main.java + test/java/lang/ClassLoader/getResource/modules/ResourcesTest.java + test/java/lang/ClassLoader/getResource/modules/src/m1/module-info.java + test/java/lang/ClassLoader/getResource/modules/src/m1/p1/Main.java + test/java/lang/ClassLoader/getResource/modules/src/m2/module-info.java + test/java/lang/ClassLoader/getResource/modules/src/m2/p2/Main.java + test/java/lang/ClassLoader/getResource/modules/src/m3/module-info.java + test/java/lang/ClassLoader/getResource/modules/src/m3/p3/Main.java + test/java/lang/ClassLoader/platformClassLoader/DefinePlatformClass.java + test/java/lang/ClassLoader/platformClassLoader/jdk.zipfs/java/fake/Fake.java + test/java/lang/Package/Foo.java + test/java/lang/Package/GetPackages.java + test/java/lang/Package/annotation/PackageInfoTest.java + test/java/lang/Package/annotation/jdk.xml.dom/org/w3c/dom/css/Fake.java + test/java/lang/Package/annotation/jdk.xml.dom/org/w3c/dom/css/FakePackage.java + test/java/lang/Package/annotation/jdk.xml.dom/org/w3c/dom/css/package-info.java + test/java/lang/Package/annotation/package-info.java + test/java/lang/Package/annotation/src/p/Bar.java + test/java/lang/Package/annotation/src/p/Duplicate.java + test/java/lang/Package/annotation/src/p/package-info.java ! test/java/lang/SecurityManager/RestrictedPackages.java + test/java/lang/SecurityManager/modules/CustomSecurityManager.sh + test/java/lang/SecurityManager/modules/Test.java + test/java/lang/SecurityManager/modules/m/module-info.java + test/java/lang/SecurityManager/modules/m/p/CustomSecurityManager.java + test/java/lang/SecurityManager/modules/test.policy + test/java/lang/StackTraceElement/ModuleFrames.java ! test/java/lang/StackTraceElement/PublicConstructor.java ! test/java/lang/StackWalker/VerifyStackTrace.java ! test/java/lang/instrument/ATransformerManagementTestCase.java ! test/java/lang/instrument/BootClassPath/Agent.java ! test/java/lang/instrument/MakeJAR2.sh ! test/java/lang/instrument/RedefineClassWithNativeMethodAgent.java ! test/java/lang/instrument/RetransformAgent.java ! test/java/lang/instrument/SimpleIdentityTransformer.java ! test/java/lang/invoke/AccessControlTest.java ! test/java/lang/invoke/CustomizedLambdaFormTest.java ! test/java/lang/invoke/MethodHandlesTest.java ! test/java/lang/invoke/VarargsArrayTest.java + test/java/lang/invoke/java.base/java/lang/invoke/MethodHandleHelper.java ! test/java/lang/invoke/lambda/LambdaAccessControlDoPrivilegedTest.java + test/java/lang/invoke/modules/ModuleAccessControlTest.java + test/java/lang/invoke/modules/src/m1/module-info.java + test/java/lang/invoke/modules/src/m1/p1/Main.java + test/java/lang/invoke/modules/src/m1/p1/Type1.java + test/java/lang/invoke/modules/src/m1/p2/Type2.java + test/java/lang/invoke/modules/src/m2/module-info.java + test/java/lang/invoke/modules/src/m2/q1/Type1.java + test/java/lang/invoke/modules/src/m2/q2/Type2.java ! test/java/lang/management/CompositeData/ThreadInfoCompositeData.java ! test/java/lang/management/MemoryMXBean/PendingAllGC.sh + test/java/lang/module/AutomaticModulesTest.java + test/java/lang/module/ConfigurationTest.java + test/java/lang/module/ModuleDescriptorTest.java + test/java/lang/module/ModuleFinderTest.java + test/java/lang/module/ModuleReader/ModuleReaderTest.java + test/java/lang/module/ModuleReader/src/m/module-info.java + test/java/lang/module/ModuleReader/src/m/p/Main.java + test/java/lang/module/ModuleReferenceTest.java + test/java/lang/module/VersionTest.java + test/java/lang/reflect/AccessibleObject/ModuleSetAccessibleTest.java + test/java/lang/reflect/Layer/BasicLayerTest.java + test/java/lang/reflect/Layer/LayerAndLoadersTest.java + test/java/lang/reflect/Layer/layertest/Test.java + test/java/lang/reflect/Layer/src/m1/module-info.java + test/java/lang/reflect/Layer/src/m1/p/Main.java + test/java/lang/reflect/Layer/src/m1/p/Service.java + test/java/lang/reflect/Layer/src/m2/module-info.java + test/java/lang/reflect/Layer/src/m2/q/Hello.java + test/java/lang/reflect/Layer/src/m3/module-info.java + test/java/lang/reflect/Layer/src/m3/w/Hello.java + test/java/lang/reflect/Layer/src/m4/impl/ServiceImpl.java + test/java/lang/reflect/Layer/src/m4/module-info.java + test/java/lang/reflect/Module/AddExportsTest.java + test/java/lang/reflect/Module/BasicModuleTest.java + test/java/lang/reflect/Module/access/AccessTest.java + test/java/lang/reflect/Module/access/src/target/module-info.java + test/java/lang/reflect/Module/access/src/target/p/Exported.java + test/java/lang/reflect/Module/access/src/target/p/Helper.java + test/java/lang/reflect/Module/access/src/target/q/Internal.java + test/java/lang/reflect/Module/access/src/test/module-info.java + test/java/lang/reflect/Module/access/src/test/test/Main.java ! test/java/lang/reflect/Proxy/Basic1.java ! test/java/lang/reflect/Proxy/NullClassLoader.java + test/java/lang/reflect/Proxy/ProxyClassAccessTest.java + test/java/lang/reflect/Proxy/ProxyForMethodHandle.java + test/java/lang/reflect/Proxy/ProxyLayerTest.java + test/java/lang/reflect/Proxy/ProxyModuleMapping.java + test/java/lang/reflect/Proxy/ProxyTest.java + test/java/lang/reflect/Proxy/q/NP.java + test/java/lang/reflect/Proxy/q/U.java + test/java/lang/reflect/Proxy/src/m1/module-info.java + test/java/lang/reflect/Proxy/src/m1/p/one/I.java + test/java/lang/reflect/Proxy/src/m1/p/one/internal/J.java + test/java/lang/reflect/Proxy/src/m2/module-info.java + test/java/lang/reflect/Proxy/src/m2/p/two/A.java + test/java/lang/reflect/Proxy/src/m2/p/two/B.java + test/java/lang/reflect/Proxy/src/m2/p/two/Bar.java + test/java/lang/reflect/Proxy/src/m2/p/two/internal/C.java + test/java/lang/reflect/Proxy/src/m3/module-info.java + test/java/lang/reflect/Proxy/src/m3/p/three/P.java + test/java/lang/reflect/Proxy/src/m3/p/three/internal/Q.java + test/java/lang/reflect/Proxy/src/test/jdk/test/Main.java + test/java/lang/reflect/Proxy/src/test/jdk/test/NP.java + test/java/lang/reflect/Proxy/src/test/jdk/test/ProxyClassAccess.java + test/java/lang/reflect/Proxy/src/test/jdk/test/ProxyTest.java + test/java/lang/reflect/Proxy/src/test/jdk/test/internal/R.java + test/java/lang/reflect/Proxy/src/test/jdk/test/internal/RImpl.java + test/java/lang/reflect/Proxy/src/test/jdk/test/internal/foo/Foo.java + test/java/lang/reflect/Proxy/src/test/jdk/test/internal/foo/FooException.java + test/java/lang/reflect/Proxy/src/test/module-info.java ! test/java/net/Authenticator/B4933582.sh ! test/java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.java - test/java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.sh + test/java/net/DatagramSocket/SetDatagramSocketImplFactory/java.base/java/net/MyDatagramSocketImplFactory.java - test/java/net/DatagramSocket/SetDatagramSocketImplFactory/java/net/MyDatagramSocketImplFactory.java ! test/java/net/NetworkInterface/NetworkInterfaceStreamTest.java ! test/java/net/URI/URItoURLTest.java ! test/java/net/URLPermission/nstest/lookup.sh + test/java/net/httpclient/whitebox/Driver.java - test/java/net/httpclient/whitebox/TEST.properties + test/java/net/httpclient/whitebox/java.httpclient/java/net/http/SelectorTest.java - test/java/net/httpclient/whitebox/java/net/http/SelectorTest.java ! test/java/nio/Buffer/LimitDirectMemory.sh ! test/java/nio/channels/spi/SelectorProvider/inheritedChannel/run_tests.sh ! test/java/nio/file/Files/StreamLinesTest.java ! test/java/nio/file/spi/SetDefaultProvider.java ! test/java/nio/file/spi/TestProvider.java ! test/java/rmi/activation/Activatable/extLoadedImpl/ext.sh ! test/java/rmi/activation/ActivationGroup/downloadActivationGroup/DownloadActivationGroup.java ! test/java/rmi/activation/ActivationSystem/stubClassesPermitted/StubClassesPermitted.java ! test/java/rmi/activation/ActivationSystem/stubClassesPermitted/rmid.security.policy ! test/java/rmi/activation/rmidViaInheritedChannel/InheritedChannelNotServerSocket.java ! test/java/rmi/activation/rmidViaInheritedChannel/RmidViaInheritedChannel.java ! test/java/rmi/dgc/dgcAckFailure/DGCAckFailure.java ! test/java/rmi/registry/readTest/readTest.sh ! test/java/rmi/reliability/benchmark/bench/HtmlReporter.java ! test/java/rmi/reliability/benchmark/bench/TextReporter.java ! test/java/rmi/testlibrary/JavaVM.java ! test/java/rmi/transport/checkFQDN/CheckFQDN.java ! test/java/rmi/transport/dgcDeadLock/DGCDeadLock.java ! test/java/security/PermissionCollection/PermissionCollectionStreamTest.java + test/java/security/Provider/DefaultProviderList.java + test/java/security/Provider/SecurityProviderModularTest.java + test/java/security/Provider/TestSecurityProvider.java + test/java/security/Provider/TestSecurityProviderClient.java ! test/java/security/cert/X509Certificate/EmptySubject.java + test/java/security/modules/ModularTest.java ! test/java/security/testlibrary/Proc.java ! test/java/util/Calendar/GenericTimeZoneNamesTest.sh ! test/java/util/Currency/CheckDataVersion.java ! test/java/util/Currency/CurrencyTest.java ! test/java/util/Formatter/Basic.sh ! test/java/util/Locale/LocaleProviders.sh ! test/java/util/PluggableLocale/ExecTest.sh ! test/java/util/PluggableLocale/ProviderTest.java ! test/java/util/ResourceBundle/Bug4168625Test.java ! test/java/util/ResourceBundle/Bug6299235Test.java ! test/java/util/ResourceBundle/Bug6299235Test.sh + test/java/util/ResourceBundle/modules/appbasic/src/asiabundles/jdk/test/resources/asia/MyResourcesAsia.java + test/java/util/ResourceBundle/modules/appbasic/src/asiabundles/jdk/test/resources/asia/MyResources_ja.properties + test/java/util/ResourceBundle/modules/appbasic/src/asiabundles/jdk/test/resources/asia/MyResources_zh.properties + test/java/util/ResourceBundle/modules/appbasic/src/asiabundles/jdk/test/resources/asia/MyResources_zh_TW.properties + 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/jdk/test/resources/eu/MyResources_de.java + test/java/util/ResourceBundle/modules/appbasic/src/eubundles/jdk/test/resources/eu/MyResources_fr.java + test/java/util/ResourceBundle/modules/appbasic/src/eubundles/module-info.java + test/java/util/ResourceBundle/modules/appbasic/src/test/jdk/test/Main.java + test/java/util/ResourceBundle/modules/appbasic/src/test/jdk/test/resources/MyControl.java + test/java/util/ResourceBundle/modules/appbasic/src/test/jdk/test/resources/MyResources.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/MyResources_en.java + test/java/util/ResourceBundle/modules/appbasic/src/test/module-info.java + test/java/util/ResourceBundle/modules/appbasic2/appbasic2.sh + test/java/util/ResourceBundle/modules/appbasic2/src/asiabundles/jdk/test/resources/asia/MyResourcesAsia.java + test/java/util/ResourceBundle/modules/appbasic2/src/asiabundles/jdk/test/resources/asia/MyResources_ja.properties + test/java/util/ResourceBundle/modules/appbasic2/src/asiabundles/jdk/test/resources/asia/MyResources_zh.properties + test/java/util/ResourceBundle/modules/appbasic2/src/asiabundles/jdk/test/resources/asia/MyResources_zh_TW.properties + 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/jdk/test/resources/eu/MyResources_de.java + test/java/util/ResourceBundle/modules/appbasic2/src/eubundles/jdk/test/resources/eu/MyResources_fr.java + test/java/util/ResourceBundle/modules/appbasic2/src/eubundles/module-info.java + test/java/util/ResourceBundle/modules/appbasic2/src/test/jdk/test/Main.java + test/java/util/ResourceBundle/modules/appbasic2/src/test/jdk/test/resources/MyResources.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/MyResources_en.java + test/java/util/ResourceBundle/modules/appbasic2/src/test/module-info.java + test/java/util/ResourceBundle/modules/basic/basic.sh + test/java/util/ResourceBundle/modules/basic/src/asiabundles/jdk/test/resources/MyResources_ja_JP.properties + test/java/util/ResourceBundle/modules/basic/src/asiabundles/jdk/test/resources/asia/MyResourcesAsia.java + test/java/util/ResourceBundle/modules/basic/src/asiabundles/jdk/test/resources/asia/MyResources_ja.properties + test/java/util/ResourceBundle/modules/basic/src/asiabundles/jdk/test/resources/asia/MyResources_zh.properties + test/java/util/ResourceBundle/modules/basic/src/asiabundles/jdk/test/resources/asia/MyResources_zh_TW.properties + 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/jdk/test/resources/eu/MyResources_de.java + test/java/util/ResourceBundle/modules/basic/src/eubundles/jdk/test/resources/eu/MyResources_fr.java + test/java/util/ResourceBundle/modules/basic/src/eubundles/module-info.java + test/java/util/ResourceBundle/modules/basic/src/extra/jdk/test/resources/asia/MyResources_vi.properties + test/java/util/ResourceBundle/modules/basic/src/extra/jdk/test/resources/eu/MyResources_es.java + test/java/util/ResourceBundle/modules/basic/src/mainbundles/jdk/test/resources/MyResources.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/MyResources_en.java + test/java/util/ResourceBundle/modules/basic/src/mainbundles/module-info.java + test/java/util/ResourceBundle/modules/basic/src/test/jdk/test/Main.java + test/java/util/ResourceBundle/modules/basic/src/test/module-info.java + test/java/util/ResourceBundle/modules/modlocal/modlocal.sh + test/java/util/ResourceBundle/modules/modlocal/src/extra/jdk/test/resources/MyResources_vi.properties + test/java/util/ResourceBundle/modules/modlocal/src/test/jdk/test/Main.java + test/java/util/ResourceBundle/modules/modlocal/src/test/jdk/test/resources/MyResources.java + test/java/util/ResourceBundle/modules/modlocal/src/test/jdk/test/resources/MyResources_de.java + test/java/util/ResourceBundle/modules/modlocal/src/test/jdk/test/resources/MyResources_en.java + test/java/util/ResourceBundle/modules/modlocal/src/test/jdk/test/resources/MyResources_fr.java + test/java/util/ResourceBundle/modules/modlocal/src/test/jdk/test/resources/MyResources_ja.properties + test/java/util/ResourceBundle/modules/modlocal/src/test/jdk/test/resources/MyResources_zh.properties + test/java/util/ResourceBundle/modules/modlocal/src/test/jdk/test/resources/MyResources_zh_TW.properties + test/java/util/ResourceBundle/modules/modlocal/src/test/module-info.java + test/java/util/ResourceBundle/modules/security/TestPermission.java + test/java/util/ResourceBundle/modules/security/src/m1/module-info.java + test/java/util/ResourceBundle/modules/security/src/m1/p1/Bundle.java + test/java/util/ResourceBundle/modules/security/src/m1/p1/resources/MyResources.java + test/java/util/ResourceBundle/modules/security/src/test/jdk/test/Main.java + test/java/util/ResourceBundle/modules/security/src/test/jdk/test/resources/TestResources.java + test/java/util/ResourceBundle/modules/security/src/test/module-info.java + test/java/util/ResourceBundle/modules/simple/simple.sh + test/java/util/ResourceBundle/modules/simple/src/bundles/jdk/test/resources/MyResources.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/MyResources_de.java + test/java/util/ResourceBundle/modules/simple/src/bundles/jdk/test/resources/MyResources_en.java + test/java/util/ResourceBundle/modules/simple/src/bundles/jdk/test/resources/MyResources_fr.java + test/java/util/ResourceBundle/modules/simple/src/bundles/jdk/test/resources/MyResources_ja.properties + test/java/util/ResourceBundle/modules/simple/src/bundles/jdk/test/resources/MyResources_zh.properties + test/java/util/ResourceBundle/modules/simple/src/bundles/jdk/test/resources/MyResources_zh_TW.properties + test/java/util/ResourceBundle/modules/simple/src/bundles/module-info.java + test/java/util/ResourceBundle/modules/simple/src/test/jdk/test/Main.java + test/java/util/ResourceBundle/modules/simple/src/test/module-info.java + test/java/util/ResourceBundle/modules/visibility/src/embargo/jdk/embargo/TestWithNoModuleArg.java + test/java/util/ResourceBundle/modules/visibility/src/embargo/jdk/embargo/TestWithUnnamedModuleArg.java + test/java/util/ResourceBundle/modules/visibility/src/embargo/module-info.java + test/java/util/ResourceBundle/modules/visibility/src/exported.named.bundles/jdk/test/resources/exported/classes/MyResources.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/props/MyResources.properties + 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/MyResources.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/MyResources.properties + test/java/util/ResourceBundle/modules/visibility/src/named.bundles/jdk/test/resources/props/MyResourcesProvider.java + test/java/util/ResourceBundle/modules/visibility/src/named.bundles/module-info.java + test/java/util/ResourceBundle/modules/visibility/src/pkg/jdk/pkg/resources/classes/MyResources.java + test/java/util/ResourceBundle/modules/visibility/src/pkg/jdk/pkg/resources/props/MyResources.properties + test/java/util/ResourceBundle/modules/visibility/src/pkg/jdk/pkg/test/Main.java + test/java/util/ResourceBundle/modules/visibility/src/test/jdk/test/TestWithNoModuleArg.java + test/java/util/ResourceBundle/modules/visibility/src/test/jdk/test/TestWithUnnamedModuleArg.java + test/java/util/ResourceBundle/modules/visibility/src/test/module-info.java + test/java/util/ResourceBundle/modules/visibility/visibility.sh + test/java/util/ResourceBundle/modules/xmlformat/src/bundles/jdk/test/resources/MyResources.xml + test/java/util/ResourceBundle/modules/xmlformat/src/bundles/jdk/test/resources/MyResourcesProvider.java + test/java/util/ResourceBundle/modules/xmlformat/src/bundles/jdk/test/resources/MyResources_de.xml + test/java/util/ResourceBundle/modules/xmlformat/src/bundles/jdk/test/resources/MyResources_en.xml + test/java/util/ResourceBundle/modules/xmlformat/src/bundles/jdk/test/resources/MyResources_fr.xml + test/java/util/ResourceBundle/modules/xmlformat/src/bundles/jdk/test/resources/MyResources_ja.xml + test/java/util/ResourceBundle/modules/xmlformat/src/bundles/jdk/test/resources/MyResources_zh.xml + test/java/util/ResourceBundle/modules/xmlformat/src/bundles/jdk/test/resources/MyResources_zh_TW.xml + test/java/util/ResourceBundle/modules/xmlformat/src/bundles/module-info.java + test/java/util/ResourceBundle/modules/xmlformat/src/test/jdk/test/Main.java + test/java/util/ResourceBundle/modules/xmlformat/src/test/module-info.java + test/java/util/ResourceBundle/modules/xmlformat/xmlformat.sh ! test/java/util/Scanner/ScannerStreamTest.java + test/java/util/ServiceLoader/TwoIterators.java + test/java/util/ServiceLoader/modules/BasicTest.java + test/java/util/ServiceLoader/modules/ServicesTest.java + test/java/util/ServiceLoader/modules/src/bananascript/module-info.java + test/java/util/ServiceLoader/modules/src/bananascript/org/banana/BananaScript.java + test/java/util/ServiceLoader/modules/src/bananascript/org/banana/BananaScriptEngineFactory.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/src/test/module-info.java + test/java/util/ServiceLoader/modules/src/test/test/Main.java ! test/java/util/logging/LocalizedLevelName.java + test/java/util/logging/modules/GetResourceBundleTest.java + test/java/util/logging/modules/pkgs/p3/resource/ClassResource.java + test/java/util/logging/modules/pkgs/p3/resource/p.properties + test/java/util/logging/modules/pkgs/p3/test/ResourceBundleTest.java + test/java/util/logging/modules/src/m1/module-info.java + test/java/util/logging/modules/src/m1/p1/resource/ClassResource.java + test/java/util/logging/modules/src/m1/p1/resource/p.properties + test/java/util/logging/modules/src/m2/module-info.java + test/java/util/logging/modules/src/m2/p2/resource/ClassResource.java + test/java/util/logging/modules/src/m2/p2/resource/p.properties + test/java/util/logging/modules/src/m2/p2/test/ModuleLoggerAccess.java ! test/java/util/regex/PatternStreamTest.java - test/java/util/stream/bootlib/TEST.properties ! test/java/util/stream/boottest/TEST.properties ! test/java/util/stream/test/TEST.properties ! test/javax/crypto/NullCipher/TestWithoutInit.java + test/javax/imageio/plugins/external_plugin_tests/TestClassPathPlugin.sh + test/javax/imageio/plugins/external_plugin_tests/src/simp/META-INF/services/javax.imageio.spi.ImageReaderSpi + test/javax/imageio/plugins/external_plugin_tests/src/simp/SIMPImageReader.java + test/javax/imageio/plugins/external_plugin_tests/src/simp/SIMPImageReaderSpi.java + test/javax/imageio/plugins/external_plugin_tests/src/simp/SIMPMetadata.java + test/javax/imageio/plugins/external_plugin_tests/src/simp/SIMPMetadataFormat.java + test/javax/imageio/plugins/external_plugin_tests/src/simp/module-info.java + test/javax/imageio/plugins/external_plugin_tests/src/simptest/TestSIMPPlugin.java ! test/javax/imageio/stream/StreamCloserLeak/run_test.sh ! test/javax/management/MBeanInfo/NotificationInfoTest.java + test/javax/naming/module/basic.sh + test/javax/naming/module/src/authz/module-info.java + test/javax/naming/module/src/authz/org/example/authz/AuthzIdRequestControl.java + test/javax/naming/module/src/authz/org/example/authz/AuthzIdResponseControl.java + test/javax/naming/module/src/authz/org/example/authz/AuthzIdResponseControlFactory.java + test/javax/naming/module/src/foo/module-info.java + test/javax/naming/module/src/foo/org/example/foo/FooControl.java + test/javax/naming/module/src/fruit/module-info.java + test/javax/naming/module/src/fruit/org/example/fruit/Fruit.java + test/javax/naming/module/src/fruit/org/example/fruit/FruitFactory.java + test/javax/naming/module/src/hello/module-info.java + test/javax/naming/module/src/hello/org/example/hello/Hello.java + test/javax/naming/module/src/hello/org/example/hello/HelloImpl.java + test/javax/naming/module/src/ldapv4/module-info.java + test/javax/naming/module/src/ldapv4/org/example/ldapv4/ldapv4URLContext.java + test/javax/naming/module/src/ldapv4/org/example/ldapv4/ldapv4URLContextFactory.java + test/javax/naming/module/src/person/module-info.java + test/javax/naming/module/src/person/org/example/person/Person.java + test/javax/naming/module/src/person/org/example/person/PersonFactory.java + test/javax/naming/module/src/test/module-info.java + test/javax/naming/module/src/test/test/ConnectWithAuthzId.java + test/javax/naming/module/src/test/test/ConnectWithAuthzId.ldap + test/javax/naming/module/src/test/test/ConnectWithFoo.java + test/javax/naming/module/src/test/test/ConnectWithFoo.ldap + test/javax/naming/module/src/test/test/LDAPServer.java + test/javax/naming/module/src/test/test/ReadByUrl.java + test/javax/naming/module/src/test/test/ReadByUrl.ldap + test/javax/naming/module/src/test/test/StoreFruit.java + test/javax/naming/module/src/test/test/StoreFruit.ldap + test/javax/naming/module/src/test/test/StoreObject.java + test/javax/naming/module/src/test/test/StoreObject.ldap + test/javax/naming/module/src/test/test/StorePerson.java + test/javax/naming/module/src/test/test/StorePerson.ldap + test/javax/naming/module/src/test/test/StoreRemote.java + test/javax/naming/module/src/test/test/StoreRemote.ldap + test/javax/net/ssl/Stapling/TEST.properties + test/javax/security/auth/login/modules/JaasClient.java + test/javax/security/auth/login/modules/JaasModularClientTest.java + test/javax/security/auth/login/modules/TEST.properties + test/javax/security/auth/login/modules/TestLoginModule.java + test/javax/security/auth/login/modules/jaas.conf + test/javax/swing/JComboBox/8080972/TestBasicComboBoxEditor.java + test/javax/swing/JEditorPane/8080972/TestJEditor.java + test/javax/swing/JFormattedTextField/8080972/TestDefaultFormatter.java + test/javax/swing/JTable/8080972/TestJTableCellEditor.java + test/javax/swing/UIDefaults/8080972/TestProxyLazyValue.java + test/javax/swing/dnd/8080972/TestTransferHandler.java + test/javax/swing/plaf/nimbus/8080972/TestAbstractRegionPainter.java + test/javax/swing/text/View/8080972/TestObjectView.java ! test/javax/xml/jaxp/Encodings/CheckEncodingPropertiesFile.java ! test/javax/xml/jaxp/common/8035437/run.sh + test/javax/xml/soap/XmlTest.java ! test/jdk/asm/AsmSanity.java - test/jdk/internal/jimage/ExecutableTest.java ! test/jdk/internal/jimage/JImageReadTest.java - test/jdk/internal/jimage/JImageTest.java + test/jdk/internal/jimage/TEST.properties - test/jdk/internal/jimage/VerifyJimage.java ! test/jdk/internal/jrtfs/Basic.java ! test/jdk/internal/ref/Cleaner/ExitOnThrow.java + test/jdk/modules/etc/VerifyModuleDelegation.java + test/jdk/modules/scenarios/automaticmodules/RunWithAutomaticModules.java + test/jdk/modules/scenarios/automaticmodules/src/bananascript/META-INF/services/javax.script.ScriptEngineFactory + test/jdk/modules/scenarios/automaticmodules/src/bananascript/org/banana/BananaScript.java + test/jdk/modules/scenarios/automaticmodules/src/bananascript/org/banana/BananaScriptEngineFactory.java + test/jdk/modules/scenarios/automaticmodules/src/basictest/module-info.java + test/jdk/modules/scenarios/automaticmodules/src/basictest/test/Main.java + test/jdk/modules/scenarios/automaticmodules/src/httpserver/http/HttpServer.java + test/jdk/modules/scenarios/automaticmodules/src/httpserver/http/spi/HttpServerProvider.java + test/jdk/modules/scenarios/automaticmodules/src/logging/logging/Logger.java + test/jdk/modules/scenarios/automaticmodules/src/sptest/module-info.java + test/jdk/modules/scenarios/automaticmodules/src/sptest/test/Main.java + test/jdk/modules/scenarios/container/ContainerTest.java + test/jdk/modules/scenarios/container/src/app1/app1/Main.java + test/jdk/modules/scenarios/container/src/app1/module-info.java + test/jdk/modules/scenarios/container/src/app2/app2/Main.java + test/jdk/modules/scenarios/container/src/app2/module-info.java + test/jdk/modules/scenarios/container/src/container/container/Main.java + test/jdk/modules/scenarios/container/src/container/module-info.java + test/jdk/modules/scenarios/container/src/java.ws.rs/javax/ws/rs/Client.java + test/jdk/modules/scenarios/container/src/java.ws.rs/module-info.java + test/jdk/modules/scenarios/container/src/java.xml.ws/javax/xml/ws/WebService.java + test/jdk/modules/scenarios/container/src/java.xml.ws/module-info.java + test/jdk/modules/scenarios/overlappingpackages/OverlappingPackagesTest.java + test/jdk/modules/scenarios/overlappingpackages/src/m1/module-info.java + test/jdk/modules/scenarios/overlappingpackages/src/m1/p/C1.java + test/jdk/modules/scenarios/overlappingpackages/src/m2/module-info.java + test/jdk/modules/scenarios/overlappingpackages/src/m2/p/C2.java + test/jdk/modules/scenarios/overlappingpackages/src/misc/module-info.java + test/jdk/modules/scenarios/overlappingpackages/src/misc/sun/misc/Unsafe.java + test/jdk/modules/scenarios/overlappingpackages/src/test/module-info.java + test/jdk/modules/scenarios/overlappingpackages/src/test/test/Main.java + test/lib/testlibrary/CompilerUtils.java + test/lib/testlibrary/JarUtils.java + test/lib/testlibrary/ModuleUtils.java ! test/lib/testlibrary/jdk/testlibrary/OutputAnalyzer.java ! test/lib/testlibrary/jdk/testlibrary/ProcessTools.java ! test/sun/awt/shell/ShellFolderMemoryLeak.java + test/sun/management/StackTraceElementCompositeData/CompatibilityTest.java ! test/sun/management/jmxremote/bootstrap/CustomLauncherTest.java ! test/sun/management/jmxremote/bootstrap/LocalManagementTest.java ! test/sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh ! test/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh ! test/sun/management/jmxremote/bootstrap/RmiSslNoKeyStoreTest.sh ! test/sun/management/jmxremote/startstop/JMXStatusPerfCountersTest.java ! test/sun/net/idn/TestStringPrep.java ! test/sun/net/util/IPAddressUtilTest.java ! test/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh ! test/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxyWithAuth.sh ! test/sun/net/www/protocol/jrt/Basic.java + test/sun/net/www/protocol/jrt/OtherResources.java ! test/sun/net/www/protocol/jrt/WithSecurityManager.java + test/sun/net/www/protocol/jrt/other_resources.sh ! test/sun/reflect/Reflection/GetCallerClassTest.sh ! test/sun/reflect/constantPool/ConstantPoolTest.java ! test/sun/rmi/runtime/Log/6409194/NoConsoleOutput.java ! test/sun/security/krb5/auto/HttpNegotiateServer.java ! test/sun/security/krb5/config/ConfPlusProp.java ! test/sun/security/krb5/config/DNS.java - test/sun/security/krb5/config/NamingManager.java - test/sun/security/krb5/config/dns.sh + test/sun/security/krb5/config/java.naming/javax/naming/spi/NamingManager.java ! test/sun/security/krb5/tools/ktcheck.sh ! test/sun/security/mscapi/IsSunMSCAPIAvailable.java - test/sun/security/mscapi/IsSunMSCAPIAvailable.sh ! test/sun/security/mscapi/PublicKeyInterop.sh ! test/sun/security/mscapi/ShortRSAKey1024.sh ! test/sun/security/pkcs11/KeyStore/ClientAuth.sh ! test/sun/security/pkcs11/Provider/Login.policy + test/sun/security/provider/PolicyFile/Modules.java + test/sun/security/provider/PolicyFile/modules.policy ! test/sun/security/provider/certpath/OCSP/OCSPSingleExtensions.java - test/sun/security/ssl/StatusStapling/BogusStatusRequest.java - test/sun/security/ssl/StatusStapling/CertStatusReqExtensionTests.java - test/sun/security/ssl/StatusStapling/CertStatusReqItemV2Tests.java - test/sun/security/ssl/StatusStapling/CertStatusReqListV2ExtensionTests.java - test/sun/security/ssl/StatusStapling/OCSPStatusRequestTests.java - test/sun/security/ssl/StatusStapling/StatusResponseManagerTests.java ! test/sun/security/ssl/StatusStapling/TEST.properties - test/sun/security/ssl/StatusStapling/TestCase.java + test/sun/security/ssl/StatusStapling/TestRun.java - test/sun/security/ssl/StatusStapling/TestUtils.java + test/sun/security/ssl/StatusStapling/java.base/sun/security/ssl/BogusStatusRequest.java + test/sun/security/ssl/StatusStapling/java.base/sun/security/ssl/CertStatusReqExtensionTests.java + test/sun/security/ssl/StatusStapling/java.base/sun/security/ssl/CertStatusReqItemV2Tests.java + test/sun/security/ssl/StatusStapling/java.base/sun/security/ssl/CertStatusReqListV2ExtensionTests.java + test/sun/security/ssl/StatusStapling/java.base/sun/security/ssl/OCSPStatusRequestTests.java + test/sun/security/ssl/StatusStapling/java.base/sun/security/ssl/StatusResponseManagerTests.java + test/sun/security/ssl/StatusStapling/java.base/sun/security/ssl/TestCase.java + test/sun/security/ssl/StatusStapling/java.base/sun/security/ssl/TestUtils.java ! test/sun/security/tools/jarsigner/ts.sh ! test/sun/security/tools/keytool/autotest.sh ! test/sun/security/tools/keytool/standard.sh ! test/sun/security/util/Oid/OidEquals.java ! test/sun/security/validator/certreplace.sh ! test/sun/security/validator/samedn.sh ! test/sun/security/x509/URICertStore/ExtensionsWithLDAP.java ! test/sun/tools/jconsole/ResourceCheckTest.java ! test/sun/tools/jhsdb/SAGetoptTest.java ! test/sun/util/resources/TimeZone/Bug4640234.java + test/tools/jar/compat/CLICompatibility.java + test/tools/jar/modularJar/Basic.java + test/tools/jar/modularJar/src/bar/jdk/test/bar/Bar.java + test/tools/jar/modularJar/src/bar/jdk/test/bar/internal/Message.java + test/tools/jar/modularJar/src/bar/module-info.java + test/tools/jar/modularJar/src/baz/jdk/test/baz/BazService.java + test/tools/jar/modularJar/src/baz/jdk/test/baz/internal/BazServiceImpl.java + test/tools/jar/modularJar/src/baz/module-info.java + test/tools/jar/modularJar/src/foo/jdk/test/foo/Foo.java + test/tools/jar/modularJar/src/foo/jdk/test/foo/internal/Message.java + test/tools/jar/modularJar/src/foo/module-info.java + test/tools/jimage/JImageTest.java + test/tools/jimage/JImageToolTest.java + test/tools/jimage/VerifyJimage.java + test/tools/jlink/CheckExecutable.java + test/tools/jlink/CustomPluginTest.java + test/tools/jlink/DefaultProviderTest.java + test/tools/jlink/ImageFileCreatorTest.java + test/tools/jlink/ImageFilePoolTest.java + test/tools/jlink/IntegrationTest.java + test/tools/jlink/JLink2Test.java + test/tools/jlink/JLinkNegativeTest.java + test/tools/jlink/JLinkOptimTest.java + test/tools/jlink/JLinkOptionsTest.java + test/tools/jlink/JLinkPluginsTest.java + test/tools/jlink/JLinkPostProcessingTest.java + test/tools/jlink/JLinkTest.java + test/tools/jlink/NativeTest.java + test/tools/jlink/ResourcePoolTest.java + test/tools/jlink/SecurityTest.java + test/tools/jlink/asmplugin/AddForgetResourcesTest.java + test/tools/jlink/asmplugin/AsmPluginTestBase.java + test/tools/jlink/asmplugin/BasicTest.java + test/tools/jlink/asmplugin/IdentityPluginTest.java + test/tools/jlink/asmplugin/NegativeTest.java + test/tools/jlink/asmplugin/PackageMappingTest.java + test/tools/jlink/asmplugin/SortingTest.java + test/tools/jlink/asmplugin/VisitorTest.java + test/tools/jlink/basic/BasicTest.java + test/tools/jlink/basic/src/test/jdk/test/Test.java + test/tools/jlink/basic/src/test/module-info.java + test/tools/jlink/customplugin/module-info.java + test/tools/jlink/customplugin/plugin/CustomPlugin.java + test/tools/jlink/customplugin/plugin/HelloPlugin.java + test/tools/jlink/hashes/HashesTest.java + test/tools/jlink/hashes/newsrc/m2/module-info.java + test/tools/jlink/hashes/newsrc/m2/org/m2/Util.java + test/tools/jlink/hashes/newsrc/not_matched/module-info.java + test/tools/jlink/hashes/newsrc/not_matched/org/not_matched/Name.java + test/tools/jlink/hashes/src/m1/module-info.java + test/tools/jlink/hashes/src/m1/org/m1/Main.java + test/tools/jlink/hashes/src/m2/module-info.java + test/tools/jlink/hashes/src/m2/org/m2/Util.java + test/tools/jlink/hashes/src/not_matched/module-info.java + test/tools/jlink/hashes/src/not_matched/org/not_matched/Name.java + test/tools/jlink/optimplugin/module-info.java + test/tools/jlink/optimplugin/optim/AType.java + test/tools/jlink/optimplugin/optim/ForNameTestCase.java + test/tools/jlink/plugins/CompressIndexesTest.java + test/tools/jlink/plugins/CompressorPluginTest.java + test/tools/jlink/plugins/ExcludeFilesPluginTest.java + test/tools/jlink/plugins/ExcludePluginTest.java + test/tools/jlink/plugins/ExcludeVMPluginTest.java + test/tools/jlink/plugins/FileCopierPluginTest.java + test/tools/jlink/plugins/GetAvailableLocales.java + test/tools/jlink/plugins/IncludeLocalesPluginTest.java + test/tools/jlink/plugins/InstalledModuleDescriptors/InstalledModulesTest.java + test/tools/jlink/plugins/InstalledModuleDescriptors/UserModuleTest.java + test/tools/jlink/plugins/InstalledModuleDescriptors/src/m1/module-info.java + test/tools/jlink/plugins/InstalledModuleDescriptors/src/m1/p1/Main.java + test/tools/jlink/plugins/InstalledModuleDescriptors/src/m1/p2/T.java + test/tools/jlink/plugins/InstalledModuleDescriptors/src/m2/module-info.java + test/tools/jlink/plugins/InstalledModuleDescriptors/src/m2/q/S1.java + test/tools/jlink/plugins/InstalledModuleDescriptors/src/m2/q/S2.java + test/tools/jlink/plugins/InstalledModuleDescriptors/src/m3/module-info.java + test/tools/jlink/plugins/LastSorterTest.java + test/tools/jlink/plugins/PluginOrderTest.java + test/tools/jlink/plugins/PluginsNegativeTest.java + test/tools/jlink/plugins/PrevisitorTest.java + test/tools/jlink/plugins/ResourceFilterTest.java + test/tools/jlink/plugins/SignatureParserTest.java + test/tools/jlink/plugins/SorterPluginTest.java + test/tools/jlink/plugins/StringSharingPluginTest.java + test/tools/jlink/plugins/StripDebugPluginTest.java + test/tools/jmod/JmodNegativeTest.java + test/tools/jmod/JmodTest.java + test/tools/jmod/src/foo/jdk/test/foo/Foo.java + test/tools/jmod/src/foo/jdk/test/foo/internal/Message.java + test/tools/jmod/src/foo/module-info.java ! test/tools/launcher/MiscTests.java ! test/tools/launcher/ToolsOpts.java ! test/tools/launcher/VersionCheck.java + test/tools/launcher/modules/addexports/AddExportsTest.java + test/tools/launcher/modules/addexports/src/java.transaction/javax/transaction/Transaction.java + test/tools/launcher/modules/addexports/src/java.transaction/javax/transaction/internal/Helper.java + test/tools/launcher/modules/addexports/src/java.transaction/module-info.java + test/tools/launcher/modules/addexports/src/m1/jdk/test1/Main.java + test/tools/launcher/modules/addexports/src/m1/module-info.java + test/tools/launcher/modules/addexports/src/m2/jdk/test2/Main.java + test/tools/launcher/modules/addexports/src/m2/module-info.java + test/tools/launcher/modules/addexports/src/m3/jdk/test3/Main.java + test/tools/launcher/modules/addexports/src/m3/module-info.java + test/tools/launcher/modules/addexports/src/m4/jdk/test4/Type.java + test/tools/launcher/modules/addexports/src/m4/module-info.java + test/tools/launcher/modules/addmods/AddModsTest.java + test/tools/launcher/modules/addmods/src/app/Main.java + test/tools/launcher/modules/addmods/src/lib/jdk/lib/Util.java + test/tools/launcher/modules/addmods/src/lib/module-info.java + test/tools/launcher/modules/addreads/AddReadsTest.java + test/tools/launcher/modules/addreads/src/junit/org/junit/Assert.java + test/tools/launcher/modules/addreads/src/m1/module-info.java + test/tools/launcher/modules/addreads/src/m1/p/Main.java + test/tools/launcher/modules/basic/BasicTest.java + test/tools/launcher/modules/basic/src/test/jdk/test/Main.java + test/tools/launcher/modules/basic/src/test/module-info.java + test/tools/launcher/modules/limitmods/LimitModsTest.java + test/tools/launcher/modules/limitmods/src/test/jdk/test/UseAWT.java + test/tools/launcher/modules/limitmods/src/test/module-info.java + test/tools/launcher/modules/listmods/ListModsTest.java + test/tools/launcher/modules/listmods/src/java.transaction/javax/transaction/Transaction.java + test/tools/launcher/modules/listmods/src/java.transaction/javax/transaction/atomic/Atomic.java + test/tools/launcher/modules/listmods/src/java.transaction/module-info.java + test/tools/launcher/modules/listmods/src/m1/module-info.java + test/tools/launcher/modules/patch/PatchTest.java + test/tools/launcher/modules/patch/src/test/jdk/test/Main.java + test/tools/launcher/modules/patch/src/test/module-info.java + test/tools/launcher/modules/patch/src1/java.base/java/text/Annotation.java + test/tools/launcher/modules/patch/src1/java.base/java/text/AnnotationBuddy.java + test/tools/launcher/modules/patch/src1/jdk.compiler/com/sun/tools/javac/Main.java + test/tools/launcher/modules/patch/src1/jdk.compiler/com/sun/tools/javac/MainBuddy.java + test/tools/launcher/modules/patch/src1/jdk.naming.dns/com/sun/jndi/dns/DnsClient.java + test/tools/launcher/modules/patch/src1/jdk.naming.dns/com/sun/jndi/dns/DnsClientBuddy.java + test/tools/launcher/modules/patch/src2/java.base/java/lang2/Object.java + test/tools/launcher/modules/patch/src2/jdk.compiler/com/sun/tools/javac2/Main.java + test/tools/launcher/modules/patch/src2/jdk.naming.dns/com/sun/jndi/dns2/Zone.java + test/tools/launcher/modules/upgrademodulepath/UpgradeModulePathTest.java + test/tools/launcher/modules/upgrademodulepath/src/java.enterprise/javax/enterprise/context/Scope.java + test/tools/launcher/modules/upgrademodulepath/src/java.enterprise/module-info.java + test/tools/launcher/modules/upgrademodulepath/src/java.transaction/javax/transaction/Transaction.java + test/tools/launcher/modules/upgrademodulepath/src/java.transaction/module-info.java + test/tools/launcher/modules/upgrademodulepath/src/test/jdk/test/Main.java + test/tools/launcher/modules/upgrademodulepath/src/test/module-info.java + test/tools/lib/tests/Helper.java + test/tools/lib/tests/JImageGenerator.java + test/tools/lib/tests/JImageValidator.java + test/tools/lib/tests/Result.java + test/tools/pack200/ModuleAttributes.java ! test/tools/pack200/Utils.java ! test/tools/pack200/pack200-verifier/make/build.xml ! test/tools/pack200/pack200-verifier/src/xmlkit/ClassReader.java Changeset: 589795e4cd38 Author: lana Date: 2016-03-23 19:33 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/589795e4cd38 Added tag jdk-9+111 for changeset b2a69d66dc65 ! .hgtags Changeset: 06668ef5bfca Author: alanb Date: 2016-03-24 07:03 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/06668ef5bfca Merge ! .hgtags ! make/CompileInterimRmic.gmk ! make/GenerateModuleSummary.gmk ! make/ModuleTools.gmk ! make/Tools.gmk ! make/copy/Copy-java.base.gmk ! make/data/jdwp/jdwp.spec ! make/gendata/GendataBreakIterator.gmk ! make/gensrc/Gensrc-java.base.gmk ! make/gensrc/Gensrc-jdk.jdi.gmk ! make/gensrc/Gensrc-jdk.jlink.gmk ! make/gensrc/GensrcLocaleData.gmk ! make/gensrc/GensrcModuleLoaderMap.gmk ! make/launcher/Launcher-java.desktop.gmk ! make/launcher/Launcher-jdk.jlink.gmk ! make/launcher/Launcher-jdk.pack200.gmk ! make/launcher/Launcher-jdk.rmic.gmk ! make/launcher/LauncherCommon.gmk ! make/lib/CoreLibraries.gmk ! make/lib/Lib-java.instrument.gmk ! make/mapfiles/libjava/mapfile-vers ! make/mapfiles/libjimage/mapfile-vers ! make/rmic/Rmic-java.management.gmk ! make/rmic/RmicCommon.gmk ! make/src/classes/build/tools/generatebreakiteratordata/GenerateBreakIteratorData.java ! make/src/classes/build/tools/jigsaw/GenGraphs.java ! make/src/classes/build/tools/jigsaw/Graph.java ! make/src/classes/build/tools/jigsaw/ModuleSummary.java ! make/src/classes/build/tools/jigsaw/technology-summary.html ! make/src/classes/build/tools/module/GenModuleInfoSource.java ! make/src/classes/build/tools/module/GenModuleLoaderMap.java ! make/src/classes/build/tools/module/Module.java ! make/src/classes/build/tools/module/ModuleInfoReader.java ! src/java.base/macosx/classes/module-info.java.extra ! src/java.base/share/classes/com/sun/java/util/jar/pack/intrinsic.properties ! src/java.base/share/classes/java/io/ObjectInputStream.java ! 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/NamedPackage.java ! src/java.base/share/classes/java/lang/Package.java ! src/java.base/share/classes/java/lang/StackTraceElement.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/java.base/share/classes/java/lang/invoke/MemberName.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java ! src/java.base/share/classes/java/lang/module/Configuration.java ! src/java.base/share/classes/java/lang/module/Dependence.java ! src/java.base/share/classes/java/lang/module/FindException.java ! src/java.base/share/classes/java/lang/module/InvalidModuleDescriptorException.java ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java ! src/java.base/share/classes/java/lang/module/ModuleFinder.java ! src/java.base/share/classes/java/lang/module/ModuleInfo.java ! src/java.base/share/classes/java/lang/module/ModulePath.java ! src/java.base/share/classes/java/lang/module/ModuleReader.java ! src/java.base/share/classes/java/lang/module/ModuleReference.java ! src/java.base/share/classes/java/lang/module/ModuleReferences.java ! src/java.base/share/classes/java/lang/module/ResolutionException.java ! src/java.base/share/classes/java/lang/module/ResolvedModule.java ! src/java.base/share/classes/java/lang/module/Resolver.java ! src/java.base/share/classes/java/lang/module/SystemModuleFinder.java ! src/java.base/share/classes/java/lang/module/package-info.java ! src/java.base/share/classes/java/lang/ref/Finalizer.java ! src/java.base/share/classes/java/lang/reflect/AccessibleObject.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/InaccessibleObjectException.java ! src/java.base/share/classes/java/lang/reflect/Layer.java ! src/java.base/share/classes/java/lang/reflect/LayerInstantiationException.java ! src/java.base/share/classes/java/lang/reflect/Method.java ! src/java.base/share/classes/java/lang/reflect/Module.java ! src/java.base/share/classes/java/lang/reflect/Proxy.java ! src/java.base/share/classes/java/net/URL.java ! src/java.base/share/classes/java/net/URLClassLoader.java ! src/java.base/share/classes/java/nio/Bits.java ! src/java.base/share/classes/java/nio/file/FileSystems.java ! src/java.base/share/classes/java/nio/file/Files.java ! src/java.base/share/classes/java/util/ResourceBundle.java ! src/java.base/share/classes/java/util/ServiceLoader.java ! src/java.base/share/classes/java/util/spi/AbstractResourceBundleProvider.java ! src/java.base/share/classes/java/util/spi/ResourceBundleControlProvider.java ! src/java.base/share/classes/java/util/spi/ResourceBundleProvider.java ! src/java.base/share/classes/javax/crypto/JceSecurity.java ! src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java ! src/java.base/share/classes/jdk/internal/jimage/ImageBufferCache.java ! src/java.base/share/classes/jdk/internal/jimage/ImageHeader.java ! src/java.base/share/classes/jdk/internal/jimage/ImageLocation.java ! src/java.base/share/classes/jdk/internal/jimage/ImageReader.java ! src/java.base/share/classes/jdk/internal/jimage/ImageReaderFactory.java ! src/java.base/share/classes/jdk/internal/jimage/ImageStream.java ! src/java.base/share/classes/jdk/internal/jimage/ImageStrings.java ! src/java.base/share/classes/jdk/internal/jimage/ImageStringsReader.java ! src/java.base/share/classes/jdk/internal/jimage/NativeImageBuffer.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/CompressIndexes.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/CompressedResourceHeader.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/Decompressor.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/ResourceDecompressor.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/ResourceDecompressorFactory.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/ResourceDecompressorRepository.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/SignatureParser.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/StringSharingDecompressor.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/StringSharingDecompressorFactory.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/ZipDecompressor.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/ZipDecompressorFactory.java ! src/java.base/share/classes/jdk/internal/jrtfs/AbstractJrtFileAttributes.java ! src/java.base/share/classes/jdk/internal/jrtfs/AbstractJrtFileSystem.java ! src/java.base/share/classes/jdk/internal/jrtfs/AbstractJrtPath.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtDirectoryStream.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtExplodedFileAttributes.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtExplodedFileSystem.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtExplodedPath.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtFileAttributeView.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtFileAttributes.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtFileStore.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtFileSystem.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtFileSystemProvider.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtPath.java ! src/java.base/share/classes/jdk/internal/jrtfs/SystemImages.java ! src/java.base/share/classes/jdk/internal/loader/BootLoader.java ! src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java ! src/java.base/share/classes/jdk/internal/loader/ClassLoaders.java ! src/java.base/share/classes/jdk/internal/loader/Loader.java ! src/java.base/share/classes/jdk/internal/loader/LoaderPool.java ! src/java.base/share/classes/jdk/internal/misc/JavaLangAccess.java ! src/java.base/share/classes/jdk/internal/misc/JavaLangModuleAccess.java ! src/java.base/share/classes/jdk/internal/misc/JavaLangReflectModuleAccess.java ! src/java.base/share/classes/jdk/internal/misc/JavaUtilResourceBundleAccess.java ! src/java.base/share/classes/jdk/internal/misc/SharedSecrets.java ! src/java.base/share/classes/jdk/internal/misc/VM.java ! src/java.base/share/classes/jdk/internal/module/Builder.java ! src/java.base/share/classes/jdk/internal/module/Checks.java ! src/java.base/share/classes/jdk/internal/module/ClassFileAttributes.java ! src/java.base/share/classes/jdk/internal/module/ClassFileConstants.java ! src/java.base/share/classes/jdk/internal/module/Hasher.java ! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java ! src/java.base/share/classes/jdk/internal/module/ModuleInfoExtender.java ! src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java ! src/java.base/share/classes/jdk/internal/module/ModuleLoaderMap.java ! src/java.base/share/classes/jdk/internal/module/ModulePatcher.java ! src/java.base/share/classes/jdk/internal/module/Modules.java ! src/java.base/share/classes/jdk/internal/module/ServicesCatalog.java ! src/java.base/share/classes/jdk/internal/module/SystemModules.java ! src/java.base/share/classes/jdk/internal/perf/PerfCounter.java ! src/java.base/share/classes/jdk/internal/vm/cds/resources/ModuleLoaderMap.dat ! src/java.base/share/classes/module-info.java ! src/java.base/share/classes/sun/invoke/util/VerifyAccess.java ! src/java.base/share/classes/sun/launcher/LauncherHelper.java ! src/java.base/share/classes/sun/launcher/resources/launcher.properties ! src/java.base/share/classes/sun/misc/URLClassPath.java ! src/java.base/share/classes/sun/net/www/protocol/jmod/Handler.java ! src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java ! src/java.base/share/classes/sun/reflect/Reflection.java ! src/java.base/share/classes/sun/reflect/misc/MethodUtil.java ! src/java.base/share/classes/sun/reflect/misc/ReflectUtil.java ! src/java.base/share/classes/sun/security/jca/ProviderList.java ! src/java.base/share/classes/sun/security/jca/Providers.java ! src/java.base/share/classes/sun/security/provider/PolicyFile.java ! src/java.base/share/classes/sun/util/locale/provider/BreakDictionary.java ! src/java.base/share/classes/sun/util/locale/provider/BreakIteratorProviderImpl.java ! src/java.base/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java ! src/java.base/share/classes/sun/util/locale/provider/LocaleResources.java ! src/java.base/share/classes/sun/util/locale/provider/ResourceBundleProviderSupport.java ! src/java.base/share/classes/sun/util/locale/provider/RuleBasedBreakIterator.java ! src/java.base/share/classes/sun/util/resources/Bundles.java ! src/java.base/share/classes/sun/util/resources/LocaleData.java ! src/java.base/share/conf/security/java.policy ! src/java.base/share/conf/security/java.security ! src/java.base/share/native/include/jni.h ! src/java.base/share/native/include/jvm.h ! src/java.base/share/native/include/jvmti.h ! src/java.base/share/native/launcher/defines.h ! src/java.base/share/native/launcher/main.c ! src/java.base/share/native/libjava/BootLoader.c ! src/java.base/share/native/libjava/Module.c ! src/java.base/share/native/libjava/Reflection.c ! src/java.base/share/native/libjimage/NativeImageBuffer.cpp ! src/java.base/share/native/libjimage/imageDecompressor.cpp ! src/java.base/share/native/libjimage/imageDecompressor.hpp ! src/java.base/share/native/libjimage/imageFile.cpp ! src/java.base/share/native/libjimage/imageFile.hpp ! src/java.base/share/native/libjimage/jimage.cpp ! src/java.base/share/native/libjimage/jimage.hpp ! src/java.base/share/native/libjli/emessages.h ! src/java.base/share/native/libjli/java.c ! src/java.base/share/native/libjli/java.h ! src/java.base/solaris/classes/module-info.java.extra ! src/java.base/windows/classes/module-info.java.extra ! src/java.compact1/share/classes/module-info.java ! src/java.compact3/share/classes/module-info.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaUtils.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/java.desktop/share/classes/com/sun/beans/finder/ConstructorFinder.java ! src/java.desktop/share/classes/com/sun/beans/finder/FieldFinder.java ! src/java.desktop/share/classes/com/sun/beans/finder/FinderUtils.java ! src/java.desktop/share/classes/com/sun/beans/finder/MethodFinder.java ! src/java.desktop/share/classes/com/sun/media/sound/JARSoundbankReader.java ! src/java.desktop/share/classes/java/awt/Component.java ! src/java.desktop/share/classes/java/awt/Toolkit.java ! src/java.desktop/share/classes/java/awt/Window.java ! src/java.desktop/share/classes/javax/imageio/ImageReader.java ! src/java.desktop/share/classes/javax/imageio/ImageWriter.java ! src/java.desktop/share/classes/javax/imageio/metadata/IIOMetadata.java ! src/java.desktop/share/classes/javax/imageio/metadata/IIOMetadataFormat.java ! src/java.desktop/share/classes/javax/imageio/metadata/IIOMetadataFormatImpl.java ! src/java.desktop/share/classes/javax/imageio/spi/ImageReaderWriterSpi.java ! src/java.desktop/share/classes/javax/swing/UIDefaults.java ! src/java.desktop/share/classes/javax/swing/text/DefaultFormatter.java ! src/java.desktop/share/classes/javax/swing/text/html/ObjectView.java ! src/java.desktop/share/classes/module-info.java ! src/java.desktop/share/classes/sun/applet/AppletSecurity.java ! src/java.instrument/share/classes/java/lang/instrument/ClassFileTransformer.java ! src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java ! src/java.instrument/share/classes/java/lang/instrument/package.html ! src/java.instrument/share/classes/module-info.java ! src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java ! src/java.instrument/share/native/libinstrument/JPLISAgent.c ! src/java.logging/share/classes/java/util/logging/Level.java ! src/java.logging/share/classes/java/util/logging/Logger.java ! src/java.logging/share/classes/module-info.java ! src/java.management/share/classes/javax/management/remote/rmi/RMIConnector.java ! src/java.management/share/classes/module-info.java ! src/java.management/share/classes/sun/management/ThreadInfoCompositeData.java ! src/java.management/share/classes/sun/management/TypeVersionMapper.java ! src/java.management/share/classes/sun/management/VMManagementImpl.java ! src/java.management/share/native/include/jmm.h ! src/java.management/share/native/libmanagement/VMManagementImpl.c ! src/java.naming/share/classes/javax/naming/spi/NamingManager.java ! src/java.naming/share/classes/module-info.java ! src/java.prefs/share/classes/module-info.java ! src/java.rmi/share/classes/java/rmi/activation/ActivationID.java ! src/java.rmi/share/classes/module-info.java ! src/java.scripting/share/classes/com/sun/tools/script/shell/Main.java ! src/java.scripting/share/classes/module-info.java ! src/java.se/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/com/sun/rowset/CachedRowSetImpl.java ! src/java.sql.rowset/share/classes/com/sun/rowset/internal/CachedRowSetWriter.java ! src/java.sql.rowset/share/classes/javax/sql/rowset/RowSetProvider.java ! src/java.sql.rowset/share/classes/javax/sql/rowset/serial/SQLInputImpl.java ! src/java.sql.rowset/share/classes/javax/sql/rowset/spi/SyncFactory.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.accessibility/windows/classes/module-info.java.extra ! src/jdk.attach/share/classes/module-info.java ! src/jdk.charsets/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.mscapi/windows/classes/sun/security/mscapi/RSAKeyPairGenerator.java ! src/jdk.crypto.pkcs11/share/classes/module-info.java ! src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/SunPKCS11.java ! src/jdk.crypto.ucrypto/solaris/classes/module-info.java ! src/jdk.deploy.osx/macosx/classes/module-info.java ! src/jdk.httpserver/share/classes/module-info.java ! src/jdk.internal.le/share/classes/module-info.java ! src/jdk.internal.opt/share/classes/module-info.java ! src/jdk.jartool/share/classes/module-info.java ! src/jdk.jartool/share/classes/sun/tools/jar/GNUStyleOptions.java ! src/jdk.jartool/share/classes/sun/tools/jar/Main.java ! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties ! src/jdk.jcmd/share/classes/module-info.java ! src/jdk.jconsole/share/classes/module-info.java ! src/jdk.jdi/share/classes/com/sun/jdi/InvalidModuleException.java ! src/jdk.jdi/share/classes/com/sun/jdi/ModuleReference.java ! src/jdk.jdi/share/classes/com/sun/jdi/ReferenceType.java ! src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java ! src/jdk.jdi/share/classes/module-info.java ! src/jdk.jdi/windows/classes/module-info.java.extra ! src/jdk.jdwp.agent/share/classes/module-info.java ! src/jdk.jdwp.agent/share/native/libjdwp/VirtualMachineImpl.c ! src/jdk.jdwp.agent/share/native/libjdwp/util.c ! src/jdk.jdwp.agent/share/native/libjdwp/util.h ! src/jdk.jlink/share/classes/jdk/tools/jimage/ExtractedImage.java ! src/jdk.jlink/share/classes/jdk/tools/jimage/JImageTask.java ! src/jdk.jlink/share/classes/jdk/tools/jimage/Main.java ! src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage.properties ! src/jdk.jlink/share/classes/jdk/tools/jlink/Jlink.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/JlinkPermission.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/builder/DefaultImageBuilder.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/builder/ImageBuilder.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Archive.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/BasicImageWriter.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/DirArchive.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageFileCreator.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageLocationWriter.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginConfiguration.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginStack.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageResourcesTree.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageStringsWriter.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JarArchive.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JmodArchive.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Main.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ModularJarArchive.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/PerfectHashBuilder.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/PluginContextImpl.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/PluginRepository.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/PoolImpl.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ResourcePrevisitor.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/StringTable.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Utils.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/DefaultCompressPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ExcludeFilesPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ExcludePlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ExcludeVMPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/FileCopierPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/OptimizationPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/PluginsResourceBundle.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ReleaseInfoPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ResourceFilter.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SortResourcesPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/StringSharingPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/StripDebugPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/StripNativeCommandsPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModuleDescriptorPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ZipPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/asm/AsmGlobalPool.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/asm/AsmModulePool.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/asm/AsmPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/asm/AsmPool.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/asm/AsmPoolImpl.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/asm/AsmPools.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/optim/ControlFlow.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/optim/ForNameFolding.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/optim/ReflectionOptimizer.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/optim/Utils.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/ExecutableImage.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/Plugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/PluginException.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/Pool.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/PostProcessorPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/TransformerPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties ! src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java ! src/jdk.jlink/share/classes/jdk/tools/jmod/Main.java ! src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod.properties ! src/jdk.jlink/share/classes/module-info.java ! src/jdk.jsobject/share/classes/module-info.java ! src/jdk.jvmstat/share/classes/module-info.java ! src/jdk.localedata/share/classes/module-info.java ! src/jdk.localedata/share/classes/sun/util/resources/provider/LocaleDataProvider.java ! src/jdk.localedata/share/classes/sun/util/resources/provider/SupplementaryLocaleDataProvider.java ! src/jdk.naming.dns/share/classes/module-info.java ! src/jdk.naming.rmi/share/classes/module-info.java ! src/jdk.pack200/share/classes/module-info.java ! src/jdk.policytool/share/classes/module-info.java ! src/jdk.rmic/share/classes/module-info.java ! src/jdk.rmic/share/classes/sun/tools/java/ClassPath.java ! src/jdk.sctp/share/classes/module-info.java ! src/jdk.security.auth/share/classes/com/sun/security/auth/SolarisNumericGroupPrincipal.java ! src/jdk.security.auth/share/classes/com/sun/security/auth/SolarisNumericUserPrincipal.java ! src/jdk.security.auth/share/classes/com/sun/security/auth/SolarisPrincipal.java ! src/jdk.security.auth/share/classes/com/sun/security/auth/X500Principal.java ! src/jdk.security.auth/share/classes/com/sun/security/auth/module/JndiLoginModule.java ! src/jdk.security.auth/share/classes/com/sun/security/auth/module/KeyStoreLoginModule.java ! src/jdk.security.auth/share/classes/com/sun/security/auth/module/Krb5LoginModule.java ! src/jdk.security.auth/share/classes/com/sun/security/auth/module/LdapLoginModule.java ! src/jdk.security.auth/share/classes/module-info.java ! src/jdk.security.jgss/share/classes/module-info.java ! src/jdk.zipfs/share/classes/module-info.java ! test/Makefile ! test/ProblemList.txt ! test/TEST.groups ! test/com/sun/jdi/ImmutableResourceTest.sh ! test/com/sun/jdi/ModulesTest.java ! test/com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java ! test/java/awt/Focus/AutoRequestFocusTest/AutoRequestFocusToFrontTest.java ! test/java/awt/Focus/FocusEmbeddedFrameTest/FocusEmbeddedFrameTest.java ! test/java/awt/Mixing/AWT_Mixing/JButtonInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JButtonOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JColorChooserOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JEditorPaneInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JEditorPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JLabelInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JLabelOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JListInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JListOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JPanelInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JPanelOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JProgressBarInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JProgressBarOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JScrollBarInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JScrollBarOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JSliderInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JSliderOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JSpinnerInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JSpinnerOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JTableInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JTableOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JTextAreaInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JTextAreaOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JTextFieldInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JTextFieldOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JToggleButtonInGlassPaneOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/JToggleButtonOverlapping.java ! test/java/awt/Mixing/AWT_Mixing/MixingFrameResizing.java ! test/java/awt/Mixing/AWT_Mixing/OverlappingTestBase.java ! test/java/awt/TrayIcon/ActionCommand/ActionCommand.java ! test/java/awt/TrayIcon/ActionEventMask/ActionEventMask.java ! test/java/awt/TrayIcon/ModalityTest/ModalityTest.java ! test/java/awt/TrayIcon/MouseEventMask/MouseEventMaskTest.java ! test/java/awt/TrayIcon/SecurityCheck/FunctionalityCheck/FunctionalityCheck.java ! test/java/awt/TrayIcon/SystemTrayIconHelper.java ! test/java/awt/TrayIcon/TrayIconEventModifiers/TrayIconEventModifiersTest.java ! test/java/awt/TrayIcon/TrayIconEvents/TrayIconEventsTest.java ! test/java/awt/TrayIcon/TrayIconMouseTest/TrayIconMouseTest.java ! test/java/awt/TrayIcon/TrayIconPopup/TrayIconPopupTest.java ! test/java/awt/grab/EmbeddedFrameTest1/EmbeddedFrameTest1.java ! test/java/awt/patchlib/java.desktop/java/awt/Helper.java ! test/java/awt/regtesthelpers/UtilInternal.java ! test/java/beans/XMLEncoder/sun_swing_PrintColorUIResource.java ! test/java/lang/Class/GetModuleTest.java ! test/java/lang/Class/forName/modules/TestDriver.java ! test/java/lang/Class/forName/modules/TestLayer.java ! test/java/lang/Class/forName/modules/src/m3/p3/NoAccess.java ! test/java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java ! test/java/lang/Class/getResource/Main.java ! test/java/lang/Class/getResource/ResourcesTest.java ! test/java/lang/Class/getResource/src/m1/module-info.java ! test/java/lang/Class/getResource/src/m1/p1/Main.java ! test/java/lang/Class/getResource/src/m2/module-info.java ! test/java/lang/Class/getResource/src/m2/p2/Main.java ! test/java/lang/Class/getResource/src/m3/module-info.java ! test/java/lang/Class/getResource/src/m3/p3/Main.java ! test/java/lang/ClassLoader/GetSystemPackage.java ! test/java/lang/ClassLoader/getResource/GetResource.sh ! test/java/lang/ClassLoader/getResource/modules/Main.java ! test/java/lang/ClassLoader/getResource/modules/ResourcesTest.java ! test/java/lang/Package/GetPackages.java ! test/java/lang/Package/annotation/PackageInfoTest.java ! test/java/lang/Package/annotation/jdk.xml.dom/org/w3c/dom/css/Fake.java ! test/java/lang/Package/annotation/jdk.xml.dom/org/w3c/dom/css/FakePackage.java ! test/java/lang/Package/annotation/jdk.xml.dom/org/w3c/dom/css/package-info.java ! test/java/lang/StackTraceElement/ModuleFrames.java ! test/java/lang/StackTraceElement/PublicConstructor.java ! test/java/lang/StackWalker/VerifyStackTrace.java ! test/java/lang/instrument/MakeJAR2.sh ! test/java/lang/instrument/RedefineClassWithNativeMethodAgent.java ! test/java/lang/instrument/RetransformAgent.java ! test/java/lang/invoke/AccessControlTest.java ! test/java/lang/invoke/MethodHandlesTest.java ! test/java/lang/invoke/java.base/java/lang/invoke/MethodHandleHelper.java ! test/java/lang/invoke/lambda/LambdaAccessControlDoPrivilegedTest.java ! test/java/lang/invoke/modules/ModuleAccessControlTest.java ! test/java/lang/invoke/modules/src/m1/module-info.java ! test/java/lang/invoke/modules/src/m1/p1/Main.java ! test/java/lang/invoke/modules/src/m1/p1/Type1.java ! test/java/lang/invoke/modules/src/m1/p2/Type2.java ! test/java/lang/invoke/modules/src/m2/module-info.java ! test/java/lang/invoke/modules/src/m2/q1/Type1.java ! test/java/lang/invoke/modules/src/m2/q2/Type2.java ! test/java/lang/management/CompositeData/ThreadInfoCompositeData.java ! test/java/lang/management/MemoryMXBean/PendingAllGC.sh ! test/java/lang/module/AutomaticModulesTest.java ! test/java/lang/module/ConfigurationTest.java ! test/java/lang/module/ModuleDescriptorTest.java ! test/java/lang/module/ModuleFinderTest.java ! test/java/lang/module/ModuleReader/ModuleReaderTest.java ! test/java/lang/module/ModuleReader/src/m/module-info.java ! test/java/lang/module/ModuleReader/src/m/p/Main.java ! test/java/lang/module/ModuleReferenceTest.java ! test/java/lang/module/VersionTest.java ! test/java/lang/reflect/AccessibleObject/ModuleSetAccessibleTest.java ! test/java/lang/reflect/Layer/BasicLayerTest.java ! test/java/lang/reflect/Layer/LayerAndLoadersTest.java ! test/java/lang/reflect/Layer/layertest/Test.java ! test/java/lang/reflect/Layer/src/m1/module-info.java ! test/java/lang/reflect/Layer/src/m1/p/Main.java ! test/java/lang/reflect/Layer/src/m1/p/Service.java ! test/java/lang/reflect/Layer/src/m2/module-info.java ! test/java/lang/reflect/Layer/src/m2/q/Hello.java ! test/java/lang/reflect/Layer/src/m3/module-info.java ! test/java/lang/reflect/Layer/src/m3/w/Hello.java ! test/java/lang/reflect/Layer/src/m4/impl/ServiceImpl.java ! test/java/lang/reflect/Layer/src/m4/module-info.java ! test/java/lang/reflect/Module/AddExportsTest.java ! test/java/lang/reflect/Module/BasicModuleTest.java ! test/java/lang/reflect/Module/access/AccessTest.java ! test/java/lang/reflect/Module/access/src/target/module-info.java ! test/java/lang/reflect/Module/access/src/target/p/Exported.java ! test/java/lang/reflect/Module/access/src/target/p/Helper.java ! test/java/lang/reflect/Module/access/src/target/q/Internal.java ! test/java/lang/reflect/Module/access/src/test/module-info.java ! test/java/lang/reflect/Module/access/src/test/test/Main.java ! test/java/lang/reflect/Proxy/NullClassLoader.java ! test/java/lang/reflect/Proxy/ProxyClassAccessTest.java ! test/java/lang/reflect/Proxy/ProxyForMethodHandle.java ! test/java/lang/reflect/Proxy/ProxyLayerTest.java ! test/java/lang/reflect/Proxy/ProxyModuleMapping.java ! test/java/lang/reflect/Proxy/ProxyTest.java ! test/java/lang/reflect/Proxy/q/NP.java ! test/java/lang/reflect/Proxy/q/U.java ! test/java/lang/reflect/Proxy/src/m1/module-info.java ! test/java/lang/reflect/Proxy/src/m1/p/one/I.java ! test/java/lang/reflect/Proxy/src/m1/p/one/internal/J.java ! test/java/lang/reflect/Proxy/src/m2/module-info.java ! test/java/lang/reflect/Proxy/src/m2/p/two/A.java ! test/java/lang/reflect/Proxy/src/m2/p/two/B.java ! test/java/lang/reflect/Proxy/src/m2/p/two/Bar.java ! test/java/lang/reflect/Proxy/src/m2/p/two/internal/C.java ! test/java/lang/reflect/Proxy/src/m3/module-info.java ! test/java/lang/reflect/Proxy/src/m3/p/three/P.java ! test/java/lang/reflect/Proxy/src/m3/p/three/internal/Q.java ! test/java/lang/reflect/Proxy/src/test/jdk/test/Main.java ! test/java/lang/reflect/Proxy/src/test/jdk/test/NP.java ! test/java/lang/reflect/Proxy/src/test/jdk/test/ProxyClassAccess.java ! test/java/lang/reflect/Proxy/src/test/jdk/test/ProxyTest.java ! test/java/lang/reflect/Proxy/src/test/jdk/test/internal/R.java ! test/java/lang/reflect/Proxy/src/test/jdk/test/internal/RImpl.java ! test/java/lang/reflect/Proxy/src/test/jdk/test/internal/foo/Foo.java ! test/java/lang/reflect/Proxy/src/test/jdk/test/internal/foo/FooException.java ! test/java/lang/reflect/Proxy/src/test/module-info.java ! test/java/net/Authenticator/B4933582.sh ! test/java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.java ! test/java/net/DatagramSocket/SetDatagramSocketImplFactory/java.base/java/net/MyDatagramSocketImplFactory.java ! test/java/net/NetworkInterface/NetworkInterfaceStreamTest.java ! test/java/net/URI/URItoURLTest.java ! test/java/net/URLPermission/nstest/lookup.sh ! test/java/net/httpclient/whitebox/java.httpclient/java/net/http/SelectorTest.java ! test/java/nio/Buffer/LimitDirectMemory.sh ! test/java/rmi/activation/Activatable/extLoadedImpl/ext.sh ! test/java/rmi/activation/ActivationGroup/downloadActivationGroup/DownloadActivationGroup.java ! test/java/rmi/activation/ActivationSystem/stubClassesPermitted/StubClassesPermitted.java ! test/java/rmi/activation/ActivationSystem/stubClassesPermitted/rmid.security.policy ! test/java/rmi/activation/rmidViaInheritedChannel/InheritedChannelNotServerSocket.java ! test/java/rmi/activation/rmidViaInheritedChannel/RmidViaInheritedChannel.java ! test/java/rmi/registry/readTest/readTest.sh ! test/java/rmi/transport/checkFQDN/CheckFQDN.java ! test/java/security/Provider/SecurityProviderModularTest.java ! test/java/security/modules/ModularTest.java ! test/java/security/testlibrary/Proc.java ! test/java/util/Calendar/GenericTimeZoneNamesTest.sh ! test/java/util/Currency/CheckDataVersion.java ! test/java/util/Formatter/Basic.sh ! test/java/util/Locale/LocaleProviders.sh ! test/java/util/PluggableLocale/ExecTest.sh ! test/java/util/ResourceBundle/Bug6299235Test.sh ! test/java/util/ResourceBundle/modules/appbasic/src/asiabundles/jdk/test/resources/asia/MyResources_ja.properties ! test/java/util/ResourceBundle/modules/appbasic/src/asiabundles/jdk/test/resources/asia/MyResources_zh.properties ! test/java/util/ResourceBundle/modules/appbasic/src/asiabundles/jdk/test/resources/asia/MyResources_zh_TW.properties ! test/java/util/ResourceBundle/modules/appbasic2/appbasic2.sh ! test/java/util/ResourceBundle/modules/appbasic2/src/asiabundles/jdk/test/resources/asia/MyResourcesAsia.java ! test/java/util/ResourceBundle/modules/appbasic2/src/asiabundles/jdk/test/resources/asia/MyResources_ja.properties ! test/java/util/ResourceBundle/modules/appbasic2/src/asiabundles/jdk/test/resources/asia/MyResources_zh.properties ! test/java/util/ResourceBundle/modules/appbasic2/src/asiabundles/jdk/test/resources/asia/MyResources_zh_TW.properties ! 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/basic/basic.sh ! test/java/util/ResourceBundle/modules/basic/src/asiabundles/jdk/test/resources/asia/MyResourcesAsia.java ! test/java/util/ResourceBundle/modules/basic/src/asiabundles/jdk/test/resources/asia/MyResources_ja.properties ! test/java/util/ResourceBundle/modules/basic/src/asiabundles/jdk/test/resources/asia/MyResources_zh.properties ! test/java/util/ResourceBundle/modules/basic/src/asiabundles/jdk/test/resources/asia/MyResources_zh_TW.properties ! 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/module-info.java ! test/java/util/ResourceBundle/modules/modlocal/modlocal.sh ! test/java/util/ResourceBundle/modules/simple/simple.sh ! test/java/util/ResourceBundle/modules/simple/src/bundles/jdk/test/resources/MyResourcesProvider.java ! test/java/util/ResourceBundle/modules/simple/src/bundles/jdk/test/resources/MyResources_en.java ! test/java/util/ResourceBundle/modules/simple/src/bundles/jdk/test/resources/MyResources_ja.properties ! test/java/util/ResourceBundle/modules/simple/src/bundles/jdk/test/resources/MyResources_zh.properties ! test/java/util/ResourceBundle/modules/simple/src/bundles/jdk/test/resources/MyResources_zh_TW.properties ! test/java/util/ResourceBundle/modules/visibility/src/exported.named.bundles/module-info.java ! test/java/util/ServiceLoader/modules/BasicTest.java ! test/java/util/ServiceLoader/modules/ServicesTest.java ! test/java/util/ServiceLoader/modules/src/bananascript/module-info.java ! test/java/util/ServiceLoader/modules/src/bananascript/org/banana/BananaScript.java ! test/java/util/ServiceLoader/modules/src/bananascript/org/banana/BananaScriptEngineFactory.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/src/test/module-info.java ! test/java/util/ServiceLoader/modules/src/test/test/Main.java ! test/java/util/logging/modules/GetResourceBundleTest.java ! test/java/util/logging/modules/pkgs/p3/test/ResourceBundleTest.java ! test/java/util/regex/PatternStreamTest.java ! test/javax/imageio/plugins/external_plugin_tests/src/simp/SIMPImageReader.java ! test/javax/imageio/plugins/external_plugin_tests/src/simp/SIMPImageReaderSpi.java ! test/javax/imageio/plugins/external_plugin_tests/src/simp/SIMPMetadata.java ! test/javax/imageio/plugins/external_plugin_tests/src/simp/SIMPMetadataFormat.java ! test/javax/imageio/plugins/external_plugin_tests/src/simp/module-info.java ! test/javax/imageio/plugins/external_plugin_tests/src/simptest/TestSIMPPlugin.java ! test/javax/imageio/stream/StreamCloserLeak/run_test.sh ! test/javax/management/MBeanInfo/NotificationInfoTest.java ! test/javax/naming/module/basic.sh ! test/javax/naming/module/src/test/test/StoreObject.java ! test/javax/naming/module/src/test/test/StoreObject.ldap ! test/javax/security/auth/login/modules/JaasClient.java ! test/javax/security/auth/login/modules/JaasModularClientTest.java ! test/javax/security/auth/login/modules/TestLoginModule.java ! test/javax/security/auth/login/modules/jaas.conf ! test/javax/swing/JFormattedTextField/8080972/TestDefaultFormatter.java ! test/javax/swing/UIDefaults/8080972/TestProxyLazyValue.java ! test/javax/xml/jaxp/common/8035437/run.sh ! test/jdk/asm/AsmSanity.java ! test/jdk/internal/jimage/JImageReadTest.java ! test/jdk/internal/jrtfs/Basic.java ! test/jdk/modules/etc/VerifyModuleDelegation.java ! test/jdk/modules/scenarios/automaticmodules/RunWithAutomaticModules.java ! test/jdk/modules/scenarios/automaticmodules/src/bananascript/META-INF/services/javax.script.ScriptEngineFactory ! test/jdk/modules/scenarios/automaticmodules/src/bananascript/org/banana/BananaScript.java ! test/jdk/modules/scenarios/automaticmodules/src/bananascript/org/banana/BananaScriptEngineFactory.java ! test/jdk/modules/scenarios/automaticmodules/src/basictest/module-info.java ! test/jdk/modules/scenarios/automaticmodules/src/basictest/test/Main.java ! test/jdk/modules/scenarios/automaticmodules/src/httpserver/http/HttpServer.java ! test/jdk/modules/scenarios/automaticmodules/src/httpserver/http/spi/HttpServerProvider.java ! test/jdk/modules/scenarios/automaticmodules/src/logging/logging/Logger.java ! test/jdk/modules/scenarios/automaticmodules/src/sptest/module-info.java ! test/jdk/modules/scenarios/automaticmodules/src/sptest/test/Main.java ! test/jdk/modules/scenarios/container/ContainerTest.java ! test/jdk/modules/scenarios/container/src/app1/app1/Main.java ! test/jdk/modules/scenarios/container/src/app1/module-info.java ! test/jdk/modules/scenarios/container/src/app2/app2/Main.java ! test/jdk/modules/scenarios/container/src/app2/module-info.java ! test/jdk/modules/scenarios/container/src/container/container/Main.java ! test/jdk/modules/scenarios/container/src/container/module-info.java ! test/jdk/modules/scenarios/container/src/java.ws.rs/javax/ws/rs/Client.java ! test/jdk/modules/scenarios/container/src/java.ws.rs/module-info.java ! test/jdk/modules/scenarios/container/src/java.xml.ws/javax/xml/ws/WebService.java ! test/jdk/modules/scenarios/container/src/java.xml.ws/module-info.java ! test/jdk/modules/scenarios/overlappingpackages/OverlappingPackagesTest.java ! test/jdk/modules/scenarios/overlappingpackages/src/m1/module-info.java ! test/jdk/modules/scenarios/overlappingpackages/src/m1/p/C1.java ! test/jdk/modules/scenarios/overlappingpackages/src/m2/module-info.java ! test/jdk/modules/scenarios/overlappingpackages/src/m2/p/C2.java ! test/jdk/modules/scenarios/overlappingpackages/src/misc/module-info.java ! test/jdk/modules/scenarios/overlappingpackages/src/misc/sun/misc/Unsafe.java ! test/jdk/modules/scenarios/overlappingpackages/src/test/module-info.java ! test/jdk/modules/scenarios/overlappingpackages/src/test/test/Main.java ! test/lib/testlibrary/CompilerUtils.java ! test/lib/testlibrary/JarUtils.java ! test/lib/testlibrary/ModuleUtils.java ! test/lib/testlibrary/jdk/testlibrary/OutputAnalyzer.java ! test/lib/testlibrary/jdk/testlibrary/ProcessTools.java ! test/sun/awt/shell/ShellFolderMemoryLeak.java ! test/sun/management/jmxremote/bootstrap/CustomLauncherTest.java ! test/sun/management/jmxremote/bootstrap/LocalManagementTest.java ! test/sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh ! test/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh ! test/sun/management/jmxremote/bootstrap/RmiSslNoKeyStoreTest.sh ! test/sun/management/jmxremote/startstop/JMXStatusPerfCountersTest.java ! test/sun/net/idn/TestStringPrep.java ! test/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh ! test/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxyWithAuth.sh ! test/sun/net/www/protocol/jrt/OtherResources.java ! test/sun/net/www/protocol/jrt/WithSecurityManager.java ! test/sun/reflect/Reflection/GetCallerClassTest.sh ! test/sun/rmi/runtime/Log/6409194/NoConsoleOutput.java ! test/sun/security/krb5/auto/HttpNegotiateServer.java ! test/sun/security/krb5/config/ConfPlusProp.java ! test/sun/security/krb5/config/java.naming/javax/naming/spi/NamingManager.java ! test/sun/security/krb5/tools/ktcheck.sh ! test/sun/security/mscapi/IsSunMSCAPIAvailable.java ! test/sun/security/mscapi/PublicKeyInterop.sh ! test/sun/security/mscapi/ShortRSAKey1024.sh ! test/sun/security/ssl/StatusStapling/java.base/sun/security/ssl/BogusStatusRequest.java ! test/sun/security/ssl/StatusStapling/java.base/sun/security/ssl/CertStatusReqExtensionTests.java ! test/sun/security/ssl/StatusStapling/java.base/sun/security/ssl/CertStatusReqItemV2Tests.java ! test/sun/security/ssl/StatusStapling/java.base/sun/security/ssl/CertStatusReqListV2ExtensionTests.java ! test/sun/security/ssl/StatusStapling/java.base/sun/security/ssl/OCSPStatusRequestTests.java ! test/sun/security/ssl/StatusStapling/java.base/sun/security/ssl/StatusResponseManagerTests.java ! test/sun/security/ssl/StatusStapling/java.base/sun/security/ssl/TestCase.java ! test/sun/security/ssl/StatusStapling/java.base/sun/security/ssl/TestUtils.java ! test/sun/security/tools/jarsigner/ts.sh ! test/sun/security/tools/keytool/autotest.sh ! test/sun/security/tools/keytool/standard.sh ! test/sun/security/validator/certreplace.sh ! test/sun/security/validator/samedn.sh ! test/sun/util/resources/TimeZone/Bug4640234.java ! test/tools/jar/compat/CLICompatibility.java ! test/tools/jar/modularJar/Basic.java ! test/tools/jar/modularJar/src/bar/jdk/test/bar/Bar.java ! test/tools/jar/modularJar/src/baz/module-info.java ! test/tools/jar/modularJar/src/foo/jdk/test/foo/Foo.java ! test/tools/jar/modularJar/src/foo/module-info.java ! test/tools/jimage/JImageTest.java ! test/tools/jimage/JImageToolTest.java ! test/tools/jimage/VerifyJimage.java ! test/tools/jlink/CheckExecutable.java ! test/tools/jlink/CustomPluginTest.java ! test/tools/jlink/DefaultProviderTest.java ! test/tools/jlink/ImageFileCreatorTest.java ! test/tools/jlink/ImageFilePoolTest.java ! test/tools/jlink/IntegrationTest.java ! test/tools/jlink/JLink2Test.java ! test/tools/jlink/JLinkNegativeTest.java ! test/tools/jlink/JLinkOptimTest.java ! test/tools/jlink/JLinkOptionsTest.java ! test/tools/jlink/JLinkPluginsTest.java ! test/tools/jlink/JLinkPostProcessingTest.java ! test/tools/jlink/JLinkTest.java ! test/tools/jlink/NativeTest.java ! test/tools/jlink/ResourcePoolTest.java ! test/tools/jlink/SecurityTest.java ! test/tools/jlink/asmplugin/AddForgetResourcesTest.java ! test/tools/jlink/asmplugin/AsmPluginTestBase.java ! test/tools/jlink/asmplugin/BasicTest.java ! test/tools/jlink/asmplugin/IdentityPluginTest.java ! test/tools/jlink/asmplugin/NegativeTest.java ! test/tools/jlink/asmplugin/PackageMappingTest.java ! test/tools/jlink/asmplugin/SortingTest.java ! test/tools/jlink/asmplugin/VisitorTest.java ! test/tools/jlink/basic/BasicTest.java ! test/tools/jlink/basic/src/test/jdk/test/Test.java ! test/tools/jlink/basic/src/test/module-info.java ! test/tools/jlink/customplugin/module-info.java ! test/tools/jlink/customplugin/plugin/CustomPlugin.java ! test/tools/jlink/customplugin/plugin/HelloPlugin.java ! test/tools/jlink/hashes/HashesTest.java ! test/tools/jlink/hashes/newsrc/m2/module-info.java ! test/tools/jlink/hashes/newsrc/m2/org/m2/Util.java ! test/tools/jlink/hashes/newsrc/not_matched/module-info.java ! test/tools/jlink/hashes/newsrc/not_matched/org/not_matched/Name.java ! test/tools/jlink/hashes/src/m1/module-info.java ! test/tools/jlink/hashes/src/m1/org/m1/Main.java ! test/tools/jlink/hashes/src/m2/module-info.java ! test/tools/jlink/hashes/src/m2/org/m2/Util.java ! test/tools/jlink/hashes/src/not_matched/module-info.java ! test/tools/jlink/hashes/src/not_matched/org/not_matched/Name.java ! test/tools/jlink/optimplugin/module-info.java ! test/tools/jlink/optimplugin/optim/AType.java ! test/tools/jlink/optimplugin/optim/ForNameTestCase.java ! test/tools/jlink/plugins/CompressIndexesTest.java ! test/tools/jlink/plugins/CompressorPluginTest.java ! test/tools/jlink/plugins/ExcludeFilesPluginTest.java ! test/tools/jlink/plugins/ExcludePluginTest.java ! test/tools/jlink/plugins/ExcludeVMPluginTest.java ! test/tools/jlink/plugins/FileCopierPluginTest.java ! test/tools/jlink/plugins/GetAvailableLocales.java ! test/tools/jlink/plugins/IncludeLocalesPluginTest.java ! test/tools/jlink/plugins/InstalledModuleDescriptors/InstalledModulesTest.java ! test/tools/jlink/plugins/InstalledModuleDescriptors/UserModuleTest.java ! test/tools/jlink/plugins/InstalledModuleDescriptors/src/m1/module-info.java ! test/tools/jlink/plugins/InstalledModuleDescriptors/src/m1/p1/Main.java ! test/tools/jlink/plugins/InstalledModuleDescriptors/src/m1/p2/T.java ! test/tools/jlink/plugins/InstalledModuleDescriptors/src/m2/module-info.java ! test/tools/jlink/plugins/InstalledModuleDescriptors/src/m2/q/S1.java ! test/tools/jlink/plugins/InstalledModuleDescriptors/src/m2/q/S2.java ! test/tools/jlink/plugins/InstalledModuleDescriptors/src/m3/module-info.java ! test/tools/jlink/plugins/LastSorterTest.java ! test/tools/jlink/plugins/PluginOrderTest.java ! test/tools/jlink/plugins/PluginsNegativeTest.java ! test/tools/jlink/plugins/PrevisitorTest.java ! test/tools/jlink/plugins/ResourceFilterTest.java ! test/tools/jlink/plugins/SignatureParserTest.java ! test/tools/jlink/plugins/SorterPluginTest.java ! test/tools/jlink/plugins/StringSharingPluginTest.java ! test/tools/jlink/plugins/StripDebugPluginTest.java ! test/tools/jmod/JmodNegativeTest.java ! test/tools/jmod/JmodTest.java ! test/tools/jmod/src/foo/jdk/test/foo/Foo.java ! test/tools/jmod/src/foo/jdk/test/foo/internal/Message.java ! test/tools/jmod/src/foo/module-info.java ! test/tools/launcher/MiscTests.java ! test/tools/launcher/ToolsOpts.java ! test/tools/launcher/VersionCheck.java ! test/tools/launcher/modules/addexports/AddExportsTest.java ! test/tools/launcher/modules/addexports/src/java.transaction/javax/transaction/Transaction.java ! test/tools/launcher/modules/addexports/src/java.transaction/javax/transaction/internal/Helper.java ! test/tools/launcher/modules/addexports/src/java.transaction/module-info.java ! test/tools/launcher/modules/addexports/src/m1/jdk/test1/Main.java ! test/tools/launcher/modules/addexports/src/m1/module-info.java ! test/tools/launcher/modules/addexports/src/m2/jdk/test2/Main.java ! test/tools/launcher/modules/addexports/src/m2/module-info.java ! test/tools/launcher/modules/addexports/src/m3/jdk/test3/Main.java ! test/tools/launcher/modules/addexports/src/m3/module-info.java ! test/tools/launcher/modules/addexports/src/m4/jdk/test4/Type.java ! test/tools/launcher/modules/addexports/src/m4/module-info.java ! test/tools/launcher/modules/addmods/AddModsTest.java ! test/tools/launcher/modules/addmods/src/app/Main.java ! test/tools/launcher/modules/addmods/src/lib/jdk/lib/Util.java ! test/tools/launcher/modules/addmods/src/lib/module-info.java ! test/tools/launcher/modules/addreads/AddReadsTest.java ! test/tools/launcher/modules/addreads/src/junit/org/junit/Assert.java ! test/tools/launcher/modules/addreads/src/m1/module-info.java ! test/tools/launcher/modules/addreads/src/m1/p/Main.java ! test/tools/launcher/modules/basic/BasicTest.java ! test/tools/launcher/modules/basic/src/test/jdk/test/Main.java ! test/tools/launcher/modules/basic/src/test/module-info.java ! test/tools/launcher/modules/limitmods/LimitModsTest.java ! test/tools/launcher/modules/limitmods/src/test/jdk/test/UseAWT.java ! test/tools/launcher/modules/limitmods/src/test/module-info.java ! test/tools/launcher/modules/listmods/ListModsTest.java ! test/tools/launcher/modules/listmods/src/java.transaction/javax/transaction/Transaction.java ! test/tools/launcher/modules/listmods/src/java.transaction/javax/transaction/atomic/Atomic.java ! test/tools/launcher/modules/listmods/src/java.transaction/module-info.java ! test/tools/launcher/modules/listmods/src/m1/module-info.java ! test/tools/launcher/modules/patch/PatchTest.java ! test/tools/launcher/modules/patch/src/test/jdk/test/Main.java ! test/tools/launcher/modules/patch/src/test/module-info.java ! test/tools/launcher/modules/patch/src1/java.base/java/text/Annotation.java ! test/tools/launcher/modules/patch/src1/java.base/java/text/AnnotationBuddy.java ! test/tools/launcher/modules/patch/src1/jdk.compiler/com/sun/tools/javac/Main.java ! test/tools/launcher/modules/patch/src1/jdk.compiler/com/sun/tools/javac/MainBuddy.java ! test/tools/launcher/modules/patch/src1/jdk.naming.dns/com/sun/jndi/dns/DnsClient.java ! test/tools/launcher/modules/patch/src1/jdk.naming.dns/com/sun/jndi/dns/DnsClientBuddy.java ! test/tools/launcher/modules/patch/src2/java.base/java/lang2/Object.java ! test/tools/launcher/modules/patch/src2/jdk.compiler/com/sun/tools/javac2/Main.java ! test/tools/launcher/modules/patch/src2/jdk.naming.dns/com/sun/jndi/dns2/Zone.java ! test/tools/launcher/modules/upgrademodulepath/UpgradeModulePathTest.java ! test/tools/launcher/modules/upgrademodulepath/src/java.enterprise/javax/enterprise/context/Scope.java ! test/tools/launcher/modules/upgrademodulepath/src/java.enterprise/module-info.java ! test/tools/launcher/modules/upgrademodulepath/src/java.transaction/javax/transaction/Transaction.java ! test/tools/launcher/modules/upgrademodulepath/src/java.transaction/module-info.java ! test/tools/launcher/modules/upgrademodulepath/src/test/jdk/test/Main.java ! test/tools/launcher/modules/upgrademodulepath/src/test/module-info.java ! test/tools/lib/tests/Helper.java ! test/tools/lib/tests/JImageGenerator.java ! test/tools/lib/tests/JImageValidator.java ! test/tools/lib/tests/Result.java ! test/tools/pack200/ModuleAttributes.java ! test/tools/pack200/Utils.java ! test/tools/pack200/pack200-verifier/make/build.xml ! test/tools/pack200/pack200-verifier/src/xmlkit/ClassReader.java From claes.redestad at oracle.com Thu Mar 24 13:42:03 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 24 Mar 2016 14:42:03 +0100 Subject: RFR: 8152641: Plugin to generate BMH$Species classes ahead-of-time Message-ID: <56F3EEAB.4090600@oracle.com> Hi, please review this patch which add an enabled-by-default plugin to generate a configurable list of BoundMethodHandle$Species_*-classes using jlink. Bug: https://bugs.openjdk.java.net/browse/JDK-8152641 Webrev: http://cr.openjdk.java.net/~redestad/8152641/webrev.01/ This plugin adds the --generate-bmh flag to jlink, which takes a comma-separated list of shortened species type strings. As an example: --generate-bmh LL,L3,L4 will generate BoundMethodHandle$Species_LL, ...$Species_L3 and ...$Species_L4 and add them to the java.base module. The Species class lookup in BoundMethodHandle will first check if there is a generated class, otherwise generate it as previously. Adding an exceptional path might seem problematic, but as the code generation is magnitudes more expensive than the exception it doesn't seem fruitful to go to lengths to avoid the CNFE. More notes along with some results can be found here: http://cr.openjdk.java.net/~redestad/scratch/bmh_species_gen.txt Thanks! /Claes From naoto.sato at oracle.com Thu Mar 24 15:51:46 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 24 Mar 2016 08:51:46 -0700 Subject: RFR: 8152143: jlink --include-locales should gracefully detect certain user error In-Reply-To: <56F38DF5.5080805@oracle.com> References: <56F31CFC.9060403@oracle.com> <56F38DF5.5080805@oracle.com> Message-ID: <56F40D12.2020604@oracle.com> Hi Mandy, Sundar, Alan, Thank you for your reviews. On 3/23/16 11:49 PM, Alan Bateman wrote: > On 23/03/2016 22:47, Naoto Sato wrote: >> Hello, >> >> Please review the fix to the following bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8152143 >> >> The fix is located at: >> >> http://cr.openjdk.java.net/~naoto/8152143/webrev.02/ > One little nit that I didn't notice before is "eg: en,ja,*-IN" where I > assume should be "e.g." I copied the part from another plugin. As I've already pushed the above change, I created an issue specific for this(https://bugs.openjdk.java.net/browse/JDK-8152704), and will fix them shortly. Naoto From naoto.sato at oracle.com Thu Mar 24 16:12:14 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 24 Mar 2016 09:12:14 -0700 Subject: RFR: 8152143: jlink --include-locales should gracefully detect certain user error In-Reply-To: <56F40D12.2020604@oracle.com> References: <56F31CFC.9060403@oracle.com> <56F38DF5.5080805@oracle.com> <56F40D12.2020604@oracle.com> Message-ID: <56F411DE.2010208@oracle.com> And the fix is here. Please review this as well. http://cr.openjdk.java.net/~naoto/8152704/webrev.00/ Naoto On 3/24/16 8:51 AM, Naoto Sato wrote: > Hi Mandy, Sundar, Alan, > > Thank you for your reviews. > > On 3/23/16 11:49 PM, Alan Bateman wrote: >> On 23/03/2016 22:47, Naoto Sato wrote: >>> Hello, >>> >>> Please review the fix to the following bug: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8152143 >>> >>> The fix is located at: >>> >>> http://cr.openjdk.java.net/~naoto/8152143/webrev.02/ >> One little nit that I didn't notice before is "eg: en,ja,*-IN" where I >> assume should be "e.g." > > I copied the part from another plugin. As I've already pushed the above > change, I created an issue specific for > this(https://bugs.openjdk.java.net/browse/JDK-8152704), and will fix > them shortly. > > Naoto From david.lloyd at redhat.com Thu Mar 24 16:34:39 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 24 Mar 2016 11:34:39 -0500 Subject: Efficiency of service lookup in layers Message-ID: <56F4171F.9080408@redhat.com> While investigating the JAXP default implementation issue (see core-libs-dev), I discovered that when ServiceLoader is loading services from a Layer, it is simply iterating every module in the layer to find implementations. What if there are thousands or tens of thousands of modules? Would it not be better to let the Layer's Configuration specify some kind of resolver, in order to allow Layer implementations to use a more efficient algorithm (like an index) and have control over service resolution decisions? The code in question is in this method of the LayerLookupIterator nested class of ServiceLoader: Iterator descriptors(Layer layer, String service) { return layer.modules().stream() .map(Module::getDescriptor) .filter(d -> d.provides().get(service) != null) .iterator(); } Note that the collection returned by layer.modules() is not presently customizable in any way as it is derived from a Map which is constructed internally in private code. -- - DML From Alan.Bateman at oracle.com Thu Mar 24 16:49:31 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 24 Mar 2016 16:49:31 +0000 Subject: Efficiency of service lookup in layers In-Reply-To: <56F4171F.9080408@redhat.com> References: <56F4171F.9080408@redhat.com> Message-ID: <56F41A9B.7000405@oracle.com> On 24/03/2016 16:34, David M. Lloyd wrote: > While investigating the JAXP default implementation issue (see > core-libs-dev), I discovered that when ServiceLoader is loading > services from a Layer, it is simply iterating every module in the > layer to find implementations. It was indexed until recently, the indexing was (deliberately) removed when doing API refactoring. It's not currently an issue because it's not used by anything yet. I suspect this will be completely replaced when we get to looking at issues like ordering of service providers. -Alan. From pbenedict at apache.org Thu Mar 24 19:05:23 2016 From: pbenedict at apache.org (Paul Benedict) Date: Thu, 24 Mar 2016 14:05:23 -0500 Subject: Why not get rid of versions? In-Reply-To: References: <244875632.2528263.1458781032429.JavaMail.zimbra@u-pem.fr> Message-ID: Remi, I would like to engage you more on this topic, especially on your statement: "ease the interrop with module systems that does their resolution at runtime" Let's say I have a project that relies on Apache Commons Collections. My project is dependent on version [2.0, 3.3) -- that's the physical version string in my POM. Now if the build tool is meant to bake the version into the class file, there are two choices here: "[2.0, 3.3)" which is a version range OR the actual version range resolved at build time. So the first question is going to be which version should the class file receive? Part of the Module Requirements is fidelity across build and runtime. If fidelity is to be retained, there is an argument either way which version should go into the class file. Allowing "[2.0, 3.3)" would give a module system much freedom, but, on the other hand, what is selected at runtime may not be what was built against. The second question is how a layer/configuration is ever going to know *a priori* (i.e., with prior knowledge) what the version strings mean? I think the underlying assumption all this time is that the version, while opaque, is going to be an exact match .... but we know tools like Maven (and I believe OSGi, if Neil can opine) allow version ranges. To me, these are two worlds colliding that shouldn't. As I said, the versioning is important for the build but it should be completely irrelevant at runtime in all cases. I want to make sure OpenJDK has seriously vetted that requirement because using the Version for runtime resolution, I think, is not going to pan out well. That requires knowing what these syntaxes mean and, as we've seen from David's attempt with the Version class, there is a whole host of schemes out there. It's my opinion the Version should *not* ever be used for "resolution at runtime" but only for build time. At runtime, it's informational only and not an input to any functional requirement. Cheers, Paul On Wed, Mar 23, 2016 at 10:06 PM, Paul Benedict wrote: > Okay, I see. They get baked into the class file by the build tool. Well, > what if they weren't there at all? Every module system today already has > external metadata and it is more descriptive than starting it from scratch > in the JDK (see #StandardModuleAttributes). All I would ask if there could > be given some thought about this, especially if it has a chance to reduce > some complexity of the Module specification. > On Mar 23, 2016 7:57 PM, "Remi Forax" wrote: > >> yes, >> module versions are just metadata, as you said they are not needed by the >> JDK, >> but jigsaw also wants to ease the interrop with module systems that does >> their resolution at runtime, >> so IMO the JDK has to provide a way to query the version of a module at >> runtime. >> >> R?mi >> >> ----- Mail original ----- >> > De: "Paul Benedict" >> > ?: "ML OpenJDK Jigsaw Developers" >> > Envoy?: Jeudi 24 Mars 2016 01:45:41 >> > Objet: Why not get rid of versions? >> > >> > Based on today's discussions, I've been thinking if there is any merit >> in >> > dumping the notion of Module Version altogether? I am beginning to think >> > it's completely irrelevant to the Module System. >> > >> > Versions are important during builds and for interacting with artifact >> > repositories, but once artifacts are resolved and installed into the >> JDK as >> > modules, versioning has no more utility. You don't even need Versions to >> > link modules together. The only thing that is actually needed is the >> Module >> > Name. >> > >> > It looks like to me versions are metadata that belong outside the JDK >> and >> > classfile format. I think a whole host of problems go away when the >> Version >> > goes away. The JDK isn't an artifact manager so it doesn't need >> versions. >> > >> > What do you think? >> > >> > From mandy.chung at oracle.com Thu Mar 24 19:10:26 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 24 Mar 2016 12:10:26 -0700 Subject: Review request 8152508: tools/jlink/SecurityTest.java failed intermittently Message-ID: This test deserves some cleanup and I suspect the intermittent failure may be related to running in agent mode. Mandy diff --git a/test/tools/jlink/SecurityTest.java b/test/tools/jlink/SecurityTest.java --- a/test/tools/jlink/SecurityTest.java +++ b/test/tools/jlink/SecurityTest.java @@ -25,7 +25,7 @@ * @test * @summary Test JlinkPermission * @author Jean-Francois Denise - * @run main SecurityTest + * @run main/othervm SecurityTest */ import java.security.AccessControlException; @@ -36,16 +36,11 @@ public static void main(String[] args) throws Exception { new Jlink(); System.setSecurityManager(new SecurityManager()); - boolean failed = false; try { new Jlink(); - failed = true; + throw new Exception("Call should have failed"); } catch (AccessControlException ex) { - //XXX OK. + // expected exception } - if (failed) { - throw new Exception("Call should have failed"); } - } -} From mandy.chung at oracle.com Thu Mar 24 19:36:39 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 24 Mar 2016 12:36:39 -0700 Subject: Review request 8152697: JVMCI tests fail with UnsatisfiedLinkError as jdk.vm.ci not defined by boot loader Message-ID: <23A98A4B-AFCE-4E24-9D06-F7D367952C8F@oracle.com> Simple patch. jdk.vm.ci should be defined by the boot loader. diff --git a/make/common/Modules.gmk b/make/common/Modules.gmk --- a/make/common/Modules.gmk +++ b/make/common/Modules.gmk @@ -66,6 +66,7 @@ jdk.sctp \ jdk.security.auth \ jdk.security.jgss \ + jdk.vm.ci \ # Mandy From anthony.vanelverdinghe at gmail.com Thu Mar 24 19:37:23 2016 From: anthony.vanelverdinghe at gmail.com (Anthony Vanelverdinghe) Date: Thu, 24 Mar 2016 20:37:23 +0100 Subject: jdeps -check: add section on exports In-Reply-To: <1652856612.2441234.1458757914364.JavaMail.zimbra@u-pem.fr> References: <56F2DFD0.70106@gmail.com> <1652856612.2441234.1458757914364.JavaMail.zimbra@u-pem.fr> Message-ID: <56F441F3.8000103@gmail.com> I believe an error would be too harsh. Suppose I have a method: public CustomList getFoos() { ... } with problematic type CustomList. Then there are multiple options to resolve this, e.g.: - replace CustomList with a super type, likely List/Collection - make the method (package-)private - move CustomList to an exported package - export CustomList's package I believe that the last option would typically not be the best one (assuming the developer has given some thought to which set of packages to export & there are relatively few problematic usages). However, if javac would treat this as an error, some developers would be annoyed by their module not compiling and choose the path of least resistance: add a bunch of "exports" clauses to module-info.java in order to make the compiler happy (especially if the compiler would propose them to do so). If, on the other hand, it were an -Xlint check or warning, those developers wouldn't be bothered, and other developers could still use -Werror to have them treated as an error instead. Moreover, I don't think an issue like this should fail the compilation: even if the example above would make it into a module: at worst a client could treat the result as an accessible super-type & use it (analog, for the case where an inaccessible type is used as a parameter, where a client could try to pass in an accessible subclass instance). But even then: the module could subsequently fix the issue (thereby possibly breaking some clients, but I'd say it wasn't very responsible of them to use inaccessible types in the first place). Kind regards, Anthony On 23/03/2016 19:31, Remi Forax wrote: > In my opinion, it should be a warning (or even an error) in javac, > you should not create a bad module in the first place. > > R?mi > > ----- Mail original ----- >> De: "Anthony Vanelverdinghe" >> ?: jigsaw-dev at openjdk.java.net >> Envoy?: Mercredi 23 Mars 2016 19:26:24 >> Objet: jdeps -check: add section on exports >> >> Hi >> >> It would be great if jdeps -check would also have a section on exports: >> this section would list non-exported packages which contain types that >> are exposed (e.g. through method signatures) by exported packages. >> Ideally, those appearances should be listed under each package, i.e.: >> >> com.foo.impl >> type X is exposed by member Y of exported type Z >> >> Using this, one could easily see whether the package should indeed be >> exported, or whether a method was mistakenly made public, or ... >> >> JDK-8147050 already mentions the similar case of checking whether or not >> a "requires" ought to be public. >> >> What do you think? Should I file an issue for this? >> >> Kind regards, >> Anthony >> From Alan.Bateman at oracle.com Thu Mar 24 19:38:48 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 24 Mar 2016 19:38:48 +0000 Subject: Review request 8152697: JVMCI tests fail with UnsatisfiedLinkError as jdk.vm.ci not defined by boot loader In-Reply-To: <23A98A4B-AFCE-4E24-9D06-F7D367952C8F@oracle.com> References: <23A98A4B-AFCE-4E24-9D06-F7D367952C8F@oracle.com> Message-ID: <56F44248.7020706@oracle.com> On 24/03/2016 19:36, Mandy Chung wrote: > Simple patch. jdk.vm.ci should be defined by the boot loader. > > diff --git a/make/common/Modules.gmk b/make/common/Modules.gmk > --- a/make/common/Modules.gmk > +++ b/make/common/Modules.gmk > @@ -66,6 +66,7 @@ > jdk.sctp \ > jdk.security.auth \ > jdk.security.jgss \ > + jdk.vm.ci \ > # > Looks okay, I'm surprised this was missed. Lost in the refactor? -Alan From Alan.Bateman at oracle.com Thu Mar 24 19:39:31 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 24 Mar 2016 19:39:31 +0000 Subject: Review request 8152508: tools/jlink/SecurityTest.java failed intermittently In-Reply-To: References: Message-ID: <56F44273.1050903@oracle.com> On 24/03/2016 19:10, Mandy Chung wrote: > This test deserves some cleanup and I suspect the intermittent failure may be related to running in agent mode. > > Looks okay for now, we can see if it continues to fail in othervm mode. -Alan From forax at univ-mlv.fr Thu Mar 24 19:44:00 2016 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 24 Mar 2016 20:44:00 +0100 (CET) Subject: Why not get rid of versions? In-Reply-To: References: <244875632.2528263.1458781032429.JavaMail.zimbra@u-pem.fr> Message-ID: <238903465.215392.1458848640986.JavaMail.zimbra@u-pem.fr> Hi Paul, ----- Mail original ----- > De: "Paul Benedict" > ?: "Remi Forax" > Cc: "ML OpenJDK Jigsaw Developers" > Envoy?: Jeudi 24 Mars 2016 20:05:23 > Objet: Re: Why not get rid of versions? > Remi, I would like to engage you more on this topic, especially on your > statement: "ease the interrop with module systems that does their resolution > at runtime" > Let's say I have a project that relies on Apache Commons Collections. My > project is dependent on version [2.0, 3.3) -- that's the physical version > string in my POM. > Now if the build tool is meant to bake the version into the class file, there > are two choices here: "[2.0, 3.3)" which is a version range OR the actual > version range resolved at build time. So the first question is going to be > which version should the class file receive? You are asking how to encode version of dependencies (see [1]), I'm taking about not having a specific format for the module version, which is not really the same issue. If you use a build tool like maven, the resolution of the dependencies is done before running jigsaw so because the resolution is done offline, we already have a way to encode version of dependencies in the POM so we don't have to invent a new format for that. Maven will consume the POMs, find all the artifacts, download the web and show all the modules to jigsaw by setting the modulepath correctly. > Part of the Module Requirements is fidelity across build and runtime. If > fidelity is to be retained, there is an argument either way which version > should go into the class file. Allowing "[2.0, 3.3)" would give a module > system much freedom, but, on the other hand, what is selected at runtime may > not be what was built against. This is part where we can not do exactly the same thing at compile time and at runtime, because doing the module resolution like maven does at runtime will make the application startup so slow that nobody will use it. We already try to do that in an early prototype, it's not a good idea. So like javac does more work than the VM, by example generics are simplified to be fast at runtime with the drawback that there are not truly reified, the works done by jigsaw at runtime can not be exactly the same as the work done at compile-time. jigsaw only validates that the dependencies are all presents at startup time and enforce the enhanced security declared in the module-info. > The second question is how a layer/configuration is ever going to know a > priori (i.e., with prior knowledge) what the version strings mean? I think > the underlying assumption all this time is that the version, while opaque, > is going to be an exact match .... but we know tools like Maven (and I > believe OSGi, if Neil can opine) allow version ranges. Currently, the only way to create a Layer is by using the API at runtime (it may change but that's another story), so a tool like OSGi (or JBoss Module or JavaEE module) will create a Layer using this API and knows how to interpret the version of a module because it's the OSGi code that will control the layer and will add the module into the layer. > To me, these are two worlds colliding that shouldn't. As I said, the > versioning is important for the build but it should be completely irrelevant > at runtime in all cases. I want to make sure OpenJDK has seriously vetted > that requirement because using the Version for runtime resolution, I think, > is not going to pan out well. That requires knowing what these syntaxes mean > and, as we've seen from David's attempt with the Version class, there is a > whole host of schemes out there. > It's my opinion the Version should *not* ever be used for "resolution at > runtime" but only for build time. At runtime, it's informational only and > not an input to any functional requirement. see my answers above > Cheers, > Paul regards, R?mi [1] http://openjdk.java.net/projects/jigsaw/spec/issues/#VersionedDependences > On Wed, Mar 23, 2016 at 10:06 PM, Paul Benedict < pbenedict at apache.org > > wrote: > > Okay, I see. They get baked into the class file by the build tool. Well, > > what > > if they weren't there at all? Every module system today already has > > external > > metadata and it is more descriptive than starting it from scratch in the > > JDK > > (see #StandardModuleAttributes). All I would ask if there could be given > > some thought about this, especially if it has a chance to reduce some > > complexity of the Module specification. > > > On Mar 23, 2016 7:57 PM, "Remi Forax" < forax at univ-mlv.fr > wrote: > > > > yes, > > > > > > module versions are just metadata, as you said they are not needed by the > > > JDK, > > > > > > but jigsaw also wants to ease the interrop with module systems that does > > > their resolution at runtime, > > > > > > so IMO the JDK has to provide a way to query the version of a module at > > > runtime. > > > > > > R?mi > > > > > > ----- Mail original ----- > > > > > > > De: "Paul Benedict" < pbenedict at apache.org > > > > > > > > ?: "ML OpenJDK Jigsaw Developers" < jigsaw-dev at openjdk.java.net > > > > > > > > Envoy?: Jeudi 24 Mars 2016 01:45:41 > > > > > > > Objet: Why not get rid of versions? > > > > > > > > > > > > > > Based on today's discussions, I've been thinking if there is any merit > > > > in > > > > > > > dumping the notion of Module Version altogether? I am beginning to > > > > think > > > > > > > it's completely irrelevant to the Module System. > > > > > > > > > > > > > > Versions are important during builds and for interacting with artifact > > > > > > > repositories, but once artifacts are resolved and installed into the > > > > JDK > > > > as > > > > > > > modules, versioning has no more utility. You don't even need Versions > > > > to > > > > > > > link modules together. The only thing that is actually needed is the > > > > Module > > > > > > > Name. > > > > > > > > > > > > > > It looks like to me versions are metadata that belong outside the JDK > > > > and > > > > > > > classfile format. I think a whole host of problems go away when the > > > > Version > > > > > > > goes away. The JDK isn't an artifact manager so it doesn't need > > > > versions. > > > > > > > > > > > > > > What do you think? > > > > > > > > > > From Alan.Bateman at oracle.com Thu Mar 24 19:46:46 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 24 Mar 2016 19:46:46 +0000 Subject: Why not get rid of versions? In-Reply-To: References: <244875632.2528263.1458781032429.JavaMail.zimbra@u-pem.fr> Message-ID: <56F44426.10407@oracle.com> On 24/03/2016 19:05, Paul Benedict wrote: > Remi, I would like to engage you more on this topic, especially on your > statement: "ease the interrop with module systems that does their > resolution at runtime" > > Let's say I have a project that relies on Apache Commons Collections. My > project is dependent on version [2.0, 3.3) -- that's the physical version > string in my POM. > > Now if the build tool is meant to bake the version into the class file, > there are two choices here: "[2.0, 3.3)" which is a version range OR the > actual version range resolved at build time. I'm not sure which build tool is storing version constraints in class files but just to say that we haven't defined any meta data or class file attributes for this. Early exploratory phases of Project Jigsaw did have support for a lot of this but this is ancient history now. All we have is support for tools to add a version at packaging time. You can try this with the jar tool now. At runtime then you can get the module version if you want and you'll see it show up in places for troubleshooting reasons, like stack traces. There is early support for hashes to tie very tightly coupled modules but that is almost a separate topic. So if a tool is indeed storing version constraints then it's not something that the module system knows anything about. -Alan. From forax at univ-mlv.fr Thu Mar 24 19:53:02 2016 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 24 Mar 2016 20:53:02 +0100 (CET) Subject: jdeps -check: add section on exports In-Reply-To: <56F441F3.8000103@gmail.com> References: <56F2DFD0.70106@gmail.com> <1652856612.2441234.1458757914364.JavaMail.zimbra@u-pem.fr> <56F441F3.8000103@gmail.com> Message-ID: <1887222106.217782.1458849182583.JavaMail.zimbra@u-pem.fr> Hi Anthony, ----- Mail original ----- > De: "Anthony Vanelverdinghe" > ?: "Remi Forax" > Cc: jigsaw-dev at openjdk.java.net > Envoy?: Jeudi 24 Mars 2016 20:37:23 > Objet: Re: jdeps -check: add section on exports > > I believe an error would be too harsh. Suppose I have a method: > > public CustomList getFoos() { ... } > > with problematic type CustomList. Then there are multiple options to > resolve this, e.g.: > - replace CustomList with a super type, likely List/Collection > - make the method (package-)private > - move CustomList to an exported package > - export CustomList's package > > I believe that the last option would typically not be the best one > (assuming the developer has given some thought to which set of packages > to export & there are relatively few problematic usages). However, if > javac would treat this as an error, some developers would be annoyed by > their module not compiling and choose the path of least resistance: add > a bunch of "exports" clauses to module-info.java in order to make the > compiler happy (especially if the compiler would propose them to do so). > If, on the other hand, it were an -Xlint check or warning, those > developers wouldn't be bothered, and other developers could still use > -Werror to have them treated as an error instead. C# currently emit an error if you try to use a non visible type in the signature, and it doesn't seem to cause too much trouble to its users. That said you are right that when the compiler emits an error, it should also indicates that using a supertype is perhaps a good option. > > Moreover, I don't think an issue like this should fail the compilation: > even if the example above would make it into a module: at worst a client > could treat the result as an accessible super-type & use it (analog, for > the case where an inaccessible type is used as a parameter, where a > client could try to pass in an accessible subclass instance). If the client doesn't see the super-type, how can it knows that 'subclass' is a subclass of that super-type ? Apart sending null, it don't think you can do better. > But even > then: the module could subsequently fix the issue (thereby possibly > breaking some clients, but I'd say it wasn't very responsible of them to > use inaccessible types in the first place). > > Kind regards, > Anthony regards, R?mi > > On 23/03/2016 19:31, Remi Forax wrote: > > In my opinion, it should be a warning (or even an error) in javac, > > you should not create a bad module in the first place. > > > > R?mi > > > > ----- Mail original ----- > >> De: "Anthony Vanelverdinghe" > >> ?: jigsaw-dev at openjdk.java.net > >> Envoy?: Mercredi 23 Mars 2016 19:26:24 > >> Objet: jdeps -check: add section on exports > >> > >> Hi > >> > >> It would be great if jdeps -check would also have a section on exports: > >> this section would list non-exported packages which contain types that > >> are exposed (e.g. through method signatures) by exported packages. > >> Ideally, those appearances should be listed under each package, i.e.: > >> > >> com.foo.impl > >> type X is exposed by member Y of exported type Z > >> > >> Using this, one could easily see whether the package should indeed be > >> exported, or whether a method was mistakenly made public, or ... > >> > >> JDK-8147050 already mentions the similar case of checking whether or not > >> a "requires" ought to be public. > >> > >> What do you think? Should I file an issue for this? > >> > >> Kind regards, > >> Anthony > >> > > From alex.buckley at oracle.com Thu Mar 24 19:56:01 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 24 Mar 2016 12:56:01 -0700 Subject: jdeps -check: add section on exports In-Reply-To: <56F441F3.8000103@gmail.com> References: <56F2DFD0.70106@gmail.com> <1652856612.2441234.1458757914364.JavaMail.zimbra@u-pem.fr> <56F441F3.8000103@gmail.com> Message-ID: <56F44651.3050302@oracle.com> I think this is very well argued. Alex On 3/24/2016 12:37 PM, Anthony Vanelverdinghe wrote: > I believe an error would be too harsh. Suppose I have a method: > > public CustomList getFoos() { ... } > > with problematic type CustomList. Then there are multiple options to > resolve this, e.g.: > - replace CustomList with a super type, likely List/Collection > - make the method (package-)private > - move CustomList to an exported package > - export CustomList's package > > I believe that the last option would typically not be the best one > (assuming the developer has given some thought to which set of packages > to export & there are relatively few problematic usages). However, if > javac would treat this as an error, some developers would be annoyed by > their module not compiling and choose the path of least resistance: add > a bunch of "exports" clauses to module-info.java in order to make the > compiler happy (especially if the compiler would propose them to do so). > If, on the other hand, it were an -Xlint check or warning, those > developers wouldn't be bothered, and other developers could still use > -Werror to have them treated as an error instead. > > Moreover, I don't think an issue like this should fail the compilation: > even if the example above would make it into a module: at worst a client > could treat the result as an accessible super-type & use it (analog, for > the case where an inaccessible type is used as a parameter, where a > client could try to pass in an accessible subclass instance). But even > then: the module could subsequently fix the issue (thereby possibly > breaking some clients, but I'd say it wasn't very responsible of them to > use inaccessible types in the first place). > > Kind regards, > Anthony > > On 23/03/2016 19:31, Remi Forax wrote: >> In my opinion, it should be a warning (or even an error) in javac, >> you should not create a bad module in the first place. >> >> R?mi >> >> ----- Mail original ----- >>> De: "Anthony Vanelverdinghe" >>> ?: jigsaw-dev at openjdk.java.net >>> Envoy?: Mercredi 23 Mars 2016 19:26:24 >>> Objet: jdeps -check: add section on exports >>> >>> Hi >>> >>> It would be great if jdeps -check would also have a section on exports: >>> this section would list non-exported packages which contain types that >>> are exposed (e.g. through method signatures) by exported packages. >>> Ideally, those appearances should be listed under each package, i.e.: >>> >>> com.foo.impl >>> type X is exposed by member Y of exported type Z >>> >>> Using this, one could easily see whether the package should indeed be >>> exported, or whether a method was mistakenly made public, or ... >>> >>> JDK-8147050 already mentions the similar case of checking whether or not >>> a "requires" ought to be public. >>> >>> What do you think? Should I file an issue for this? >>> >>> Kind regards, >>> Anthony >>> > From alex.buckley at oracle.com Thu Mar 24 20:06:18 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 24 Mar 2016 13:06:18 -0700 Subject: jdeps -check: add section on exports In-Reply-To: <1887222106.217782.1458849182583.JavaMail.zimbra@u-pem.fr> References: <56F2DFD0.70106@gmail.com> <1652856612.2441234.1458757914364.JavaMail.zimbra@u-pem.fr> <56F441F3.8000103@gmail.com> <1887222106.217782.1458849182583.JavaMail.zimbra@u-pem.fr> Message-ID: <56F448BA.20906@oracle.com> On 3/24/2016 12:53 PM, forax at univ-mlv.fr wrote: >> Moreover, I don't think an issue like this should fail the compilation: >> even if the example above would make it into a module: at worst a client >> could treat the result as an accessible super-type & use it (analog, for >> the case where an inaccessible type is used as a parameter, where a >> client could try to pass in an accessible subclass instance). > > If the client doesn't see the super-type, how can it knows that 'subclass' is a subclass of that super-type ? > Apart sending null, it don't think you can do better. Suppose the parameter type is a package-private interface I, but there's a public class C in the same package that implements I. Since C's superinterfaces are not exactly secret, I can instantiate C from anywhere, and pass the instance to the method expecting I. All of which is to say, while C# may have long given errors for inaccessible types in signatures, Java hasn't. Alex From anthony.vanelverdinghe at gmail.com Thu Mar 24 20:08:53 2016 From: anthony.vanelverdinghe at gmail.com (Anthony Vanelverdinghe) Date: Thu, 24 Mar 2016 21:08:53 +0100 Subject: jdeps -check: add section on exports In-Reply-To: <1887222106.217782.1458849182583.JavaMail.zimbra@u-pem.fr> References: <56F2DFD0.70106@gmail.com> <1652856612.2441234.1458757914364.JavaMail.zimbra@u-pem.fr> <56F441F3.8000103@gmail.com> <1887222106.217782.1458849182583.JavaMail.zimbra@u-pem.fr> Message-ID: <56F44955.8050102@gmail.com> Hi R?mi Yes, I admit I didn't give that too much thought, just wanted to mention the analog with parameter types ;) I was thinking something like SerializableFileSystem, where a client could deduce a subclass from the type name (similar to CustomList, where it's reasonable to assume it's a List implementation). Kind regards, Anthony On 24/03/2016 20:53, forax at univ-mlv.fr wrote: > Hi Anthony, > > ----- Mail original ----- >> De: "Anthony Vanelverdinghe" >> ?: "Remi Forax" >> Cc: jigsaw-dev at openjdk.java.net >> Envoy?: Jeudi 24 Mars 2016 20:37:23 >> Objet: Re: jdeps -check: add section on exports >> >> I believe an error would be too harsh. Suppose I have a method: >> >> public CustomList getFoos() { ... } >> >> with problematic type CustomList. Then there are multiple options to >> resolve this, e.g.: >> - replace CustomList with a super type, likely List/Collection >> - make the method (package-)private >> - move CustomList to an exported package >> - export CustomList's package >> >> I believe that the last option would typically not be the best one >> (assuming the developer has given some thought to which set of packages >> to export & there are relatively few problematic usages). However, if >> javac would treat this as an error, some developers would be annoyed by >> their module not compiling and choose the path of least resistance: add >> a bunch of "exports" clauses to module-info.java in order to make the >> compiler happy (especially if the compiler would propose them to do so). >> If, on the other hand, it were an -Xlint check or warning, those >> developers wouldn't be bothered, and other developers could still use >> -Werror to have them treated as an error instead. > C# currently emit an error if you try to use a non visible type in the signature, and it doesn't seem to cause too much trouble to its users. > That said you are right that when the compiler emits an error, it should also indicates that using a supertype is perhaps a good option. > >> Moreover, I don't think an issue like this should fail the compilation: >> even if the example above would make it into a module: at worst a client >> could treat the result as an accessible super-type & use it (analog, for >> the case where an inaccessible type is used as a parameter, where a >> client could try to pass in an accessible subclass instance). > If the client doesn't see the super-type, how can it knows that 'subclass' is a subclass of that super-type ? > Apart sending null, it don't think you can do better. > >> But even >> then: the module could subsequently fix the issue (thereby possibly >> breaking some clients, but I'd say it wasn't very responsible of them to >> use inaccessible types in the first place). >> >> Kind regards, >> Anthony > regards, > R?mi > >> On 23/03/2016 19:31, Remi Forax wrote: >>> In my opinion, it should be a warning (or even an error) in javac, >>> you should not create a bad module in the first place. >>> >>> R?mi >>> >>> ----- Mail original ----- >>>> De: "Anthony Vanelverdinghe" >>>> ?: jigsaw-dev at openjdk.java.net >>>> Envoy?: Mercredi 23 Mars 2016 19:26:24 >>>> Objet: jdeps -check: add section on exports >>>> >>>> Hi >>>> >>>> It would be great if jdeps -check would also have a section on exports: >>>> this section would list non-exported packages which contain types that >>>> are exposed (e.g. through method signatures) by exported packages. >>>> Ideally, those appearances should be listed under each package, i.e.: >>>> >>>> com.foo.impl >>>> type X is exposed by member Y of exported type Z >>>> >>>> Using this, one could easily see whether the package should indeed be >>>> exported, or whether a method was mistakenly made public, or ... >>>> >>>> JDK-8147050 already mentions the similar case of checking whether or not >>>> a "requires" ought to be public. >>>> >>>> What do you think? Should I file an issue for this? >>>> >>>> Kind regards, >>>> Anthony >>>> >> From mandy.chung at oracle.com Thu Mar 24 20:14:25 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 24 Mar 2016 13:14:25 -0700 Subject: Review request 8152697: JVMCI tests fail with UnsatisfiedLinkError as jdk.vm.ci not defined by boot loader In-Reply-To: <56F44248.7020706@oracle.com> References: <23A98A4B-AFCE-4E24-9D06-F7D367952C8F@oracle.com> <56F44248.7020706@oracle.com> Message-ID: <397FC9B7-1A39-452E-A686-7CCAE053947A@oracle.com> > On Mar 24, 2016, at 12:38 PM, Alan Bateman wrote: > > > On 24/03/2016 19:36, Mandy Chung wrote: >> Simple patch. jdk.vm.ci should be defined by the boot loader. >> >> diff --git a/make/common/Modules.gmk b/make/common/Modules.gmk >> --- a/make/common/Modules.gmk >> +++ b/make/common/Modules.gmk >> @@ -66,6 +66,7 @@ >> jdk.sctp \ >> jdk.security.auth \ >> jdk.security.jgss \ >> + jdk.vm.ci \ >> # >> > Looks okay, I'm surprised this was missed. Lost in the refactor? It was misplaced in the closed version. During the cleanup, it should be moved to the open list but missed. Mandy From pbenedict at apache.org Thu Mar 24 20:28:15 2016 From: pbenedict at apache.org (Paul Benedict) Date: Thu, 24 Mar 2016 15:28:15 -0500 Subject: Why not get rid of versions? In-Reply-To: <238903465.215392.1458848640986.JavaMail.zimbra@u-pem.fr> References: <244875632.2528263.1458781032429.JavaMail.zimbra@u-pem.fr> <238903465.215392.1458848640986.JavaMail.zimbra@u-pem.fr> Message-ID: Remi, thanks for your response. You stated a lot of useful information. If you don't mind, I will just quote snippets to prevent the email from getting too lengthy. Thanks. You wrote: > This is part where we can not do exactly the same thing at compile time > and at runtime, because doing the module resolution like maven does > at runtime will make the application startup so slow that nobody will use it. Agreed. You wrote: > Currently, the only way to create a Layer is by using the API at runtime > (it may change but that's another story), so a tool like OSGi (or JBoss Module > or JavaEE module) will create a Layer using this API and knows how to > interpret the version of a module because it's the OSGi code that will > control the layer and will add the module into the layer. Now this is where things get confusing for me. Since the JSR requirements came out, it's been pretty clear that the Version is not part of any "requires" statement because the version is not supposed to be involved in dependency resolution. By the time the JDK is loading modules into the runtime, all the correct versions have been selected -- not by the JDK, but by whatever assembly mechanism that packaged the application. Maybe this is Maven, for example. So now I am reading emails this week where people are going to "interpret" the version. If you're talking about "interpreting" it for runtime dependency resolution, then you have a conflict with the original Jigsaw requirements (or least my understanding of them). Your phrasing was "interrop with module systems that does their resolution at runtime" and "query the version of a module at runtime" [1]. Either Version is involved at resolution at runtime or it isn't... or now it is sometimes? [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-March/007021.html Cheers, Paul From martinrb at google.com Thu Mar 24 23:10:15 2016 From: martinrb at google.com (Martin Buchholz) Date: Thu, 24 Mar 2016 16:10:15 -0700 Subject: Troubles running javadoc with jsr166 CVS and jigsaw integration Message-ID: Hi jigsaw/javadoc folk, I'm trying to update jsr166 CVS to latest jdks and failing. If I run "ant docs" with a -Djdk9.home pointing at jdk-9+110 binaries and -Djdk9.src.dir pointing at openjdk9 tip sources, I get: [javadoc] Constructing Javadoc information... [javadoc] Standard Doclet (Next) version 9-ea [javadoc] Building tree for all the packages and classes... [javadoc] Generating /usr/local/google/home/martinrb/jsr166/javadoc/build/docs/constant-values.html... [javadoc] 1 error [javadoc] javadoc: error - com.sun.tools.javac.code.ClassFinder$BadClassFile: bad class file: /modules/java.base/java/util/ServiceLoader$LazyIterator.class [javadoc] undeclared type variable: S [javadoc] Please remove or make sure it appears in the correct subdirectory of the classpath. Hmmm ?? ... don't know what to do about that ... except upgrade to +111 ... Binaries are not available yet, but I can build my own. If I then point -Djdk9.home at a freshly built jdk at tip, I get: [javadoc] 1 error [javadoc] java.lang.AssertionError [javadoc] at com.sun.tools.javac.util.Assert.error(jdk.compiler at 9-internal/Assert.java:155) [javadoc] at com.sun.tools.javac.util.Assert.checkNull(jdk.compiler at 9-internal/Assert.java:54) [javadoc] at com.sun.tools.javac.code.Symtab.enterModule(jdk.compiler at 9-internal/Symtab.java:753) [javadoc] at com.sun.tools.javac.comp.Modules.enterModule(jdk.compiler at 9-internal/Modules.java:257) [javadoc] at com.sun.tools.javac.comp.Modules.enterModules(jdk.compiler at 9-internal/Modules.java:235) [javadoc] at com.sun.tools.javac.comp.Modules.enter(jdk.compiler at 9-internal/Modules.java:203) [javadoc] at com.sun.tools.javac.main.JavaCompiler.readSourceFile(jdk.compiler at 9-internal/JavaCompiler.java:816) [javadoc] at com.sun.tools.javac.main.JavaCompiler.readSourceFile(jdk.compiler at 9-internal/JavaCompiler.java:778) [javadoc] at com.sun.tools.javac.main.JavaCompiler.access$100(jdk.compiler at 9-internal/JavaCompiler.java:97) [javadoc] at com.sun.tools.javac.main.JavaCompiler$1.complete(jdk.compiler at 9-internal/JavaCompiler.java:339) [javadoc] at com.sun.tools.javac.code.ClassFinder.fillIn(jdk.compiler at 9-internal/ClassFinder.java:362) [javadoc] at com.sun.tools.javac.code.ModuleFinder.lambda$findSingleModule$0(jdk.compiler at 9-internal/ModuleFinder.java:206) [javadoc] at com.sun.tools.javac.code.Symbol.complete(jdk.compiler at 9-internal/Symbol.java:601) [javadoc] at com.sun.tools.javac.comp.Modules.setCompilationUnitModules(jdk.compiler at 9-internal/Modules.java:361) [javadoc] at com.sun.tools.javac.comp.Modules.enter(jdk.compiler at 9-internal/Modules.java:205) [javadoc] at jdk.javadoc.internal.tool.JavadocTool.getEnvironment(jdk.javadoc at 9-internal/JavadocTool.java:190) [javadoc] at jdk.javadoc.internal.tool.Start.parseAndExecute(jdk.javadoc at 9-internal/Start.java:401) [javadoc] at jdk.javadoc.internal.tool.Start.begin(jdk.javadoc at 9-internal/Start.java:274) [javadoc] at jdk.javadoc.internal.tool.Start.begin(jdk.javadoc at 9-internal/Start.java:220) [javadoc] at jdk.javadoc.internal.tool.Main.execute(jdk.javadoc at 9-internal/Main.java:70) [javadoc] at jdk.javadoc.internal.tool.Main.main(jdk.javadoc at 9-internal/Main.java:52) [javadoc] javadoc: error - fatal error From forax at univ-mlv.fr Thu Mar 24 23:19:34 2016 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Fri, 25 Mar 2016 00:19:34 +0100 (CET) Subject: Why not get rid of versions? In-Reply-To: References: <244875632.2528263.1458781032429.JavaMail.zimbra@u-pem.fr> <238903465.215392.1458848640986.JavaMail.zimbra@u-pem.fr> Message-ID: <2144831584.36482.1458861574118.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Paul Benedict" > ?: forax at univ-mlv.fr > Cc: "ML OpenJDK Jigsaw Developers" > Envoy?: Jeudi 24 Mars 2016 21:28:15 > Objet: Re: Why not get rid of versions? > Remi, thanks for your response. You stated a lot of useful information. If > you don't mind, I will just quote snippets to prevent the email from getting > too lengthy. Thanks. > You wrote: > > This is part where we can not do exactly the same thing at compile time > > and at runtime, because doing the module resolution like maven does > > at runtime will make the application startup so slow that nobody will use > > it. > Agreed. > You wrote: > > Currently, the only way to create a Layer is by using the API at runtime > > (it may change but that's another story), so a tool like OSGi (or JBoss > > Module > > or JavaEE module) will create a Layer using this API and knows how to > > interpret the version of a module because it's the OSGi code that will > > control the layer and will add the module into the layer. > Now this is where things get confusing for me. Since the JSR requirements > came out, it's been pretty clear that the Version is not part of any > "requires" statement because the version is not supposed to be involved in > dependency resolution. By the time the JDK is loading modules into the > runtime, all the correct versions have been selected -- not by the JDK, but > by whatever assembly mechanism that packaged the application. Maybe this is > Maven, for example. > So now I am reading emails this week where people are going to "interpret" > the version. If you're talking about "interpreting" it for runtime > dependency resolution, then you have a conflict with the original Jigsaw > requirements (or least my understanding of them). Your phrasing was > "interrop with module systems that does their resolution at runtime" and > "query the version of a module at runtime" [1]. > Either Version is involved at resolution at runtime or it isn't... or now it > is sometimes? This is something we may have explained poorly, at startup time, all the modules you have in the modulepath are resolved, then when the main() is executed, any codes can create a new layer, loads its own modules from wherever it wants, using the resolution algorithm it wants, using any information it wants (like by example the metadata stored in the module-info.class). So in fact, in this scenario, there are two resolution algorithms, the jigsaw one for the modules in the modulepath, the one from a module system like OSGi. > [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-March/007021.html > Cheers, > Paul cheers, R?mi From jonathan.gibbons at oracle.com Fri Mar 25 00:17:44 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 24 Mar 2016 17:17:44 -0700 Subject: Troubles running javadoc with jsr166 CVS and jigsaw integration In-Reply-To: References: Message-ID: <56F483A8.7090406@oracle.com> Martin, Can you provide details on how to reproduce this (e.g. including repo paths) -- Jon On 03/24/2016 04:10 PM, Martin Buchholz wrote: > Hi jigsaw/javadoc folk, > > I'm trying to update jsr166 CVS to latest jdks and failing. > > If I run "ant docs" with a -Djdk9.home pointing at jdk-9+110 binaries > and -Djdk9.src.dir pointing at openjdk9 tip sources, I get: > > [javadoc] Constructing Javadoc information... > [javadoc] Standard Doclet (Next) version 9-ea > [javadoc] Building tree for all the packages and classes... > [javadoc] Generating > /usr/local/google/home/martinrb/jsr166/javadoc/build/docs/constant-values.html... > [javadoc] 1 error > [javadoc] javadoc: error - > com.sun.tools.javac.code.ClassFinder$BadClassFile: bad class file: > /modules/java.base/java/util/ServiceLoader$LazyIterator.class > [javadoc] undeclared type variable: S > [javadoc] Please remove or make sure it appears in the correct > subdirectory of the classpath. > > Hmmm ?? ... don't know what to do about that ... except upgrade to +111 ... > Binaries are not available yet, but I can build my own. If I then > point -Djdk9.home at a freshly built jdk at tip, I get: > > [javadoc] 1 error > [javadoc] java.lang.AssertionError > [javadoc] at com.sun.tools.javac.util.Assert.error(jdk.compiler at 9-internal/Assert.java:155) > [javadoc] at com.sun.tools.javac.util.Assert.checkNull(jdk.compiler at 9-internal/Assert.java:54) > [javadoc] at com.sun.tools.javac.code.Symtab.enterModule(jdk.compiler at 9-internal/Symtab.java:753) > [javadoc] at com.sun.tools.javac.comp.Modules.enterModule(jdk.compiler at 9-internal/Modules.java:257) > [javadoc] at com.sun.tools.javac.comp.Modules.enterModules(jdk.compiler at 9-internal/Modules.java:235) > [javadoc] at com.sun.tools.javac.comp.Modules.enter(jdk.compiler at 9-internal/Modules.java:203) > [javadoc] at com.sun.tools.javac.main.JavaCompiler.readSourceFile(jdk.compiler at 9-internal/JavaCompiler.java:816) > [javadoc] at com.sun.tools.javac.main.JavaCompiler.readSourceFile(jdk.compiler at 9-internal/JavaCompiler.java:778) > [javadoc] at com.sun.tools.javac.main.JavaCompiler.access$100(jdk.compiler at 9-internal/JavaCompiler.java:97) > [javadoc] at com.sun.tools.javac.main.JavaCompiler$1.complete(jdk.compiler at 9-internal/JavaCompiler.java:339) > [javadoc] at com.sun.tools.javac.code.ClassFinder.fillIn(jdk.compiler at 9-internal/ClassFinder.java:362) > [javadoc] at com.sun.tools.javac.code.ModuleFinder.lambda$findSingleModule$0(jdk.compiler at 9-internal/ModuleFinder.java:206) > [javadoc] at com.sun.tools.javac.code.Symbol.complete(jdk.compiler at 9-internal/Symbol.java:601) > [javadoc] at com.sun.tools.javac.comp.Modules.setCompilationUnitModules(jdk.compiler at 9-internal/Modules.java:361) > [javadoc] at com.sun.tools.javac.comp.Modules.enter(jdk.compiler at 9-internal/Modules.java:205) > [javadoc] at jdk.javadoc.internal.tool.JavadocTool.getEnvironment(jdk.javadoc at 9-internal/JavadocTool.java:190) > [javadoc] at jdk.javadoc.internal.tool.Start.parseAndExecute(jdk.javadoc at 9-internal/Start.java:401) > [javadoc] at jdk.javadoc.internal.tool.Start.begin(jdk.javadoc at 9-internal/Start.java:274) > [javadoc] at jdk.javadoc.internal.tool.Start.begin(jdk.javadoc at 9-internal/Start.java:220) > [javadoc] at jdk.javadoc.internal.tool.Main.execute(jdk.javadoc at 9-internal/Main.java:70) > [javadoc] at jdk.javadoc.internal.tool.Main.main(jdk.javadoc at 9-internal/Main.java:52) > [javadoc] javadoc: error - fatal error From mandy.chung at oracle.com Fri Mar 25 01:51:38 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 24 Mar 2016 18:51:38 -0700 Subject: RFR: 8152641: Plugin to generate BMH$Species classes ahead-of-time In-Reply-To: <56F3EEAB.4090600@oracle.com> References: <56F3EEAB.4090600@oracle.com> Message-ID: <1FE3F7A6-1C7B-4DC6-875C-E3FAEDED08F5@oracle.com> Hi Claes, This is a good interesting work to generate BoundMethodHandle$Species_* classes at link time. This will save the class generation time. Instead of Class.forName, you may want to have a class (similar to SystemModules [1]) that will be updated at link time so that BoundMethodHandle can reference it statically to determine what species are generated at link time and even return statically Class of the generated class. About CNFE, the new Class.forName(Module, String) method does not throw CNFE that you could use instead (if not static reference as suggested above). If not found, it will return null. This plugin accesses the non-public methods in BoundMethodHandle and has to invoke it via reflection. With module boundary enforced now, maybe we could consider moving to some internal package to share with this jlink plugin. I think there are tests needed to be updated when a new plugin is added. Mandy [1] http://hg.openjdk.java.net/jdk9/dev/jdk/file/3abd25870915/src/java.base/share/classes/jdk/internal/module/SystemModules.java > On Mar 24, 2016, at 6:42 AM, Claes Redestad wrote: > > Hi, > > please review this patch which add an enabled-by-default plugin to generate a > configurable list of BoundMethodHandle$Species_*-classes using jlink. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8152641 > Webrev: http://cr.openjdk.java.net/~redestad/8152641/webrev.01/ > > This plugin adds the --generate-bmh flag to jlink, which takes a > comma-separated list of shortened species type strings. > > As an example: --generate-bmh LL,L3,L4 will generate > BoundMethodHandle$Species_LL, ...$Species_L3 and ...$Species_L4 and add > them to the java.base module. > > The Species class lookup in BoundMethodHandle will first check if there is a > generated class, otherwise generate it as previously. Adding an exceptional > path might seem problematic, but as the code generation is magnitudes more > expensive than the exception it doesn't seem fruitful to go to lengths to avoid > the CNFE. > > More notes along with some results can be found here: > > http://cr.openjdk.java.net/~redestad/scratch/bmh_species_gen.txt > > Thanks! > > /Claes From martinrb at google.com Fri Mar 25 03:50:52 2016 From: martinrb at google.com (Martin Buchholz) Date: Thu, 24 Mar 2016 20:50:52 -0700 Subject: Troubles running javadoc with jsr166 CVS and jigsaw integration In-Reply-To: <56F483A8.7090406@oracle.com> References: <56F483A8.7090406@oracle.com> Message-ID: (last minute fiddling with ant properties ... hope this works:) cvs -Q -d ':pserver:anonymous:@gee.cs.oswego.edu/home/jsr166/jsr166' checkout jsr166 && cd jsr166 && ant -Djdk9.home="$JDK9_IMAGE" -Djdk9.src.home="$JDK9_SOURCE_FOREST" docs where $JDK9_IMAGE is an image for +110 or +111, and $JDK9_SOURCE_FOREST is a mercurial forest for +110 or +111 Use "ant -v" to get much more verbose diagnostics. On Thu, Mar 24, 2016 at 5:17 PM, Jonathan Gibbons wrote: > Martin, > > Can you provide details on how to reproduce this (e.g. including repo paths) > > -- Jon > > > On 03/24/2016 04:10 PM, Martin Buchholz wrote: >> >> Hi jigsaw/javadoc folk, >> >> I'm trying to update jsr166 CVS to latest jdks and failing. >> >> If I run "ant docs" with a -Djdk9.home pointing at jdk-9+110 binaries >> and -Djdk9.src.dir pointing at openjdk9 tip sources, I get: >> >> [javadoc] Constructing Javadoc information... >> [javadoc] Standard Doclet (Next) version 9-ea >> [javadoc] Building tree for all the packages and classes... >> [javadoc] Generating >> >> /usr/local/google/home/martinrb/jsr166/javadoc/build/docs/constant-values.html... >> [javadoc] 1 error >> [javadoc] javadoc: error - >> com.sun.tools.javac.code.ClassFinder$BadClassFile: bad class file: >> /modules/java.base/java/util/ServiceLoader$LazyIterator.class >> [javadoc] undeclared type variable: S >> [javadoc] Please remove or make sure it appears in the correct >> subdirectory of the classpath. >> >> Hmmm ?? ... don't know what to do about that ... except upgrade to +111 >> ... >> Binaries are not available yet, but I can build my own. If I then >> point -Djdk9.home at a freshly built jdk at tip, I get: >> >> [javadoc] 1 error >> [javadoc] java.lang.AssertionError >> [javadoc] at >> com.sun.tools.javac.util.Assert.error(jdk.compiler at 9-internal/Assert.java:155) >> [javadoc] at >> com.sun.tools.javac.util.Assert.checkNull(jdk.compiler at 9-internal/Assert.java:54) >> [javadoc] at >> com.sun.tools.javac.code.Symtab.enterModule(jdk.compiler at 9-internal/Symtab.java:753) >> [javadoc] at >> com.sun.tools.javac.comp.Modules.enterModule(jdk.compiler at 9-internal/Modules.java:257) >> [javadoc] at >> com.sun.tools.javac.comp.Modules.enterModules(jdk.compiler at 9-internal/Modules.java:235) >> [javadoc] at >> com.sun.tools.javac.comp.Modules.enter(jdk.compiler at 9-internal/Modules.java:203) >> [javadoc] at >> com.sun.tools.javac.main.JavaCompiler.readSourceFile(jdk.compiler at 9-internal/JavaCompiler.java:816) >> [javadoc] at >> com.sun.tools.javac.main.JavaCompiler.readSourceFile(jdk.compiler at 9-internal/JavaCompiler.java:778) >> [javadoc] at >> com.sun.tools.javac.main.JavaCompiler.access$100(jdk.compiler at 9-internal/JavaCompiler.java:97) >> [javadoc] at >> com.sun.tools.javac.main.JavaCompiler$1.complete(jdk.compiler at 9-internal/JavaCompiler.java:339) >> [javadoc] at >> com.sun.tools.javac.code.ClassFinder.fillIn(jdk.compiler at 9-internal/ClassFinder.java:362) >> [javadoc] at >> com.sun.tools.javac.code.ModuleFinder.lambda$findSingleModule$0(jdk.compiler at 9-internal/ModuleFinder.java:206) >> [javadoc] at >> com.sun.tools.javac.code.Symbol.complete(jdk.compiler at 9-internal/Symbol.java:601) >> [javadoc] at >> com.sun.tools.javac.comp.Modules.setCompilationUnitModules(jdk.compiler at 9-internal/Modules.java:361) >> [javadoc] at >> com.sun.tools.javac.comp.Modules.enter(jdk.compiler at 9-internal/Modules.java:205) >> [javadoc] at >> jdk.javadoc.internal.tool.JavadocTool.getEnvironment(jdk.javadoc at 9-internal/JavadocTool.java:190) >> [javadoc] at >> jdk.javadoc.internal.tool.Start.parseAndExecute(jdk.javadoc at 9-internal/Start.java:401) >> [javadoc] at >> jdk.javadoc.internal.tool.Start.begin(jdk.javadoc at 9-internal/Start.java:274) >> [javadoc] at >> jdk.javadoc.internal.tool.Start.begin(jdk.javadoc at 9-internal/Start.java:220) >> [javadoc] at >> jdk.javadoc.internal.tool.Main.execute(jdk.javadoc at 9-internal/Main.java:70) >> [javadoc] at >> jdk.javadoc.internal.tool.Main.main(jdk.javadoc at 9-internal/Main.java:52) >> [javadoc] javadoc: error - fatal error > > From peter.levart at gmail.com Fri Mar 25 10:11:17 2016 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 25 Mar 2016 11:11:17 +0100 Subject: RFR: 8152641: Plugin to generate BMH$Species classes ahead-of-time In-Reply-To: <1FE3F7A6-1C7B-4DC6-875C-E3FAEDED08F5@oracle.com> References: <56F3EEAB.4090600@oracle.com> <1FE3F7A6-1C7B-4DC6-875C-E3FAEDED08F5@oracle.com> Message-ID: <56F50EC5.6020500@gmail.com> Hi Claes, Mandy, On 03/25/2016 02:51 AM, Mandy Chung wrote: > Hi Claes, > > This is a good interesting work to generate BoundMethodHandle$Species_* classes at link time. This will save the class generation time. Instead of Class.forName, you may want to have a class (similar to SystemModules [1]) that will be updated at link time so that BoundMethodHandle can reference it statically to determine what species are generated at link time and even return statically Class of the generated class. You may still want to load this classes lazily when needed. Otherwise the BMH.CLASS_CACHE could simply be pre-populated with name -> Class entries at appropriate early time. > > About CNFE, the new Class.forName(Module, String) method does not throw CNFE that you could use instead (if not static reference as suggested above). If not found, it will return null. > > This plugin accesses the non-public methods in BoundMethodHandle and has to invoke it via reflection. With module boundary enforced now, maybe we could consider moving to some internal package to share with this jlink plugin. > > I think there are tests needed to be updated when a new plugin is added. > > Mandy > [1] http://hg.openjdk.java.net/jdk9/dev/jdk/file/3abd25870915/src/java.base/share/classes/jdk/internal/module/SystemModules.java One thing to consider is the following: the names of the classes obey a particular convention which is now hardcoded in two places: the BoundMethodHandle and the GenerateBMHClassesPlugin. You could have a method with the following signature in BoundMethodHandle$Factory: Map.Entry generateConcreteBMHClassBytes(String types) ...which would also return the name of the class derived from the types which you would then use to derive the path of the .class file in the module of the image. Also, this method - although package-private becomes part of the API and that should be written in a comment. What do you think? Regards, Peter > >> On Mar 24, 2016, at 6:42 AM, Claes Redestad wrote: >> >> Hi, >> >> please review this patch which add an enabled-by-default plugin to generate a >> configurable list of BoundMethodHandle$Species_*-classes using jlink. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8152641 >> Webrev: http://cr.openjdk.java.net/~redestad/8152641/webrev.01/ >> >> This plugin adds the --generate-bmh flag to jlink, which takes a >> comma-separated list of shortened species type strings. >> >> As an example: --generate-bmh LL,L3,L4 will generate >> BoundMethodHandle$Species_LL, ...$Species_L3 and ...$Species_L4 and add >> them to the java.base module. >> >> The Species class lookup in BoundMethodHandle will first check if there is a >> generated class, otherwise generate it as previously. Adding an exceptional >> path might seem problematic, but as the code generation is magnitudes more >> expensive than the exception it doesn't seem fruitful to go to lengths to avoid >> the CNFE. >> >> More notes along with some results can be found here: >> >> http://cr.openjdk.java.net/~redestad/scratch/bmh_species_gen.txt >> >> Thanks! >> >> /Claes From alan.bateman at oracle.com Fri Mar 25 13:39:42 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 25 Mar 2016 13:39:42 +0000 Subject: hg: jigsaw/jake/jdk: 4 new changesets Message-ID: <201603251339.u2PDdgwZ000951@aojmv0008.oracle.com> Changeset: dfd8d10ebabd Author: alanb Date: 2016-03-24 14:23 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/dfd8d10ebabd Preserve service provider order ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java ! src/java.base/share/classes/java/lang/module/ModuleInfo.java ! src/java.base/share/classes/java/lang/module/ModulePath.java ! src/java.base/share/classes/jdk/internal/module/ClassFileAttributes.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModuleDescriptorPlugin.java Changeset: fb49bb599c58 Author: alanb Date: 2016-03-25 12:47 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fb49bb599c58 Follow on from JDK-8149775, make module path less tolerate of garabge on the module path ! src/java.base/share/classes/java/lang/module/ModulePath.java ! test/java/lang/module/ModuleFinderTest.java Changeset: 069b50202bff Author: alanb Date: 2016-03-25 13:33 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/069b50202bff Move tests to new -XaddExports syntax ! test/java/net/Authenticator/B4933582.sh ! test/java/rmi/activation/Activatable/extLoadedImpl/ext.sh ! test/java/rmi/activation/ActivationGroup/downloadActivationGroup/DownloadActivationGroup.java ! test/java/rmi/activation/ActivationSystem/stubClassesPermitted/StubClassesPermitted.java ! test/java/rmi/registry/readTest/readTest.sh ! test/java/rmi/transport/checkFQDN/CheckFQDN.java ! test/java/rmi/transport/dgcDeadLock/DGCDeadLock.java ! test/java/util/Locale/LocaleProviders.sh ! test/java/util/PluggableLocale/ExecTest.sh ! test/sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh ! test/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh ! test/sun/management/jmxremote/bootstrap/RmiSslNoKeyStoreTest.sh ! test/sun/rmi/runtime/Log/6409194/NoConsoleOutput.java ! test/sun/security/krb5/tools/ktcheck.sh ! test/sun/security/tools/jarsigner/ts.sh ! test/sun/security/tools/keytool/autotest.sh ! test/sun/security/tools/keytool/standard.sh Changeset: 374838f2d298 Author: alanb Date: 2016-03-25 13:38 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/374838f2d298 toString javadoc confusing ! src/java.base/share/classes/java/lang/reflect/Module.java From claes.redestad at oracle.com Fri Mar 25 14:58:21 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 25 Mar 2016 15:58:21 +0100 Subject: RFR: 8152641: Plugin to generate BMH$Species classes ahead-of-time In-Reply-To: <56F50EC5.6020500@gmail.com> References: <56F3EEAB.4090600@oracle.com> <1FE3F7A6-1C7B-4DC6-875C-E3FAEDED08F5@oracle.com> <56F50EC5.6020500@gmail.com> Message-ID: <56F5520D.3080205@oracle.com> Hi, On 2016-03-25 11:11, Peter Levart wrote: > Hi Claes, Mandy, > > On 03/25/2016 02:51 AM, Mandy Chung wrote: >> Hi Claes, >> >> This is a good interesting work to generate >> BoundMethodHandle$Species_* classes at link time. This will save the >> class generation time. Instead of Class.forName, you may want to >> have a class (similar to SystemModules [1]) that will be updated at >> link time so that BoundMethodHandle can reference it statically to >> determine what species are generated at link time and even return >> statically Class of the generated class. > > You may still want to load this classes lazily when needed. Otherwise > the BMH.CLASS_CACHE could simply be pre-populated with name -> > Class entries at appropriate early time. I think laziness is a good property here, since it won't penalize modular applications that choose to instruct jlink to pregenerate a lot of BMH classes. Perhaps we can allow for static resolve + lazy classload by emitting a switch equivalent to: switch (types) { case "LL": return Species_LL.class; case "L3": return Species_L3.class; .. default: return generateBMHSpeciesClass(types); } > >> >> About CNFE, the new Class.forName(Module, String) method does not >> throw CNFE that you could use instead (if not static reference as >> suggested above). If not found, it will return null. Thanks, this one had passed under my radar. :-) >> >> This plugin accesses the non-public methods in BoundMethodHandle and >> has to invoke it via reflection. With module boundary enforced now, >> maybe we could consider moving to some internal package to share with >> this jlink plugin. >> >> I think there are tests needed to be updated when a new plugin is added. >> >> Mandy >> [1] >> http://hg.openjdk.java.net/jdk9/dev/jdk/file/3abd25870915/src/java.base/share/classes/jdk/internal/module/SystemModules.java > > One thing to consider is the following: the names of the classes obey > a particular convention which is now hardcoded in two places: the > BoundMethodHandle and the GenerateBMHClassesPlugin. You could have a > method with the following signature in BoundMethodHandle$Factory: > > Map.Entry generateConcreteBMHClassBytes(String types) > > ...which would also return the name of the class derived from the > types which you would then use to derive the path of the .class file > in the module of the image. Also, this method - although > package-private becomes part of the API and that should be written in > a comment. > > What do you think? Definitely should add a comment about generateConcreteBMHClassBytes being an internal API used by the plugin. I'm open to the idea of moving static utility code to some internal package, but want to hear what maintainers of java.lang.invoke think about factoring out utility code like this. Thanks! /Claes > > Regards, Peter > >> >>> On Mar 24, 2016, at 6:42 AM, Claes Redestad >>> wrote: >>> >>> Hi, >>> >>> please review this patch which add an enabled-by-default plugin to >>> generate a >>> configurable list of BoundMethodHandle$Species_*-classes using jlink. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152641 >>> Webrev: http://cr.openjdk.java.net/~redestad/8152641/webrev.01/ >>> >>> This plugin adds the --generate-bmh flag to jlink, which takes a >>> comma-separated list of shortened species type strings. >>> >>> As an example: --generate-bmh LL,L3,L4 will generate >>> BoundMethodHandle$Species_LL, ...$Species_L3 and ...$Species_L4 and add >>> them to the java.base module. >>> >>> The Species class lookup in BoundMethodHandle will first check if >>> there is a >>> generated class, otherwise generate it as previously. Adding an >>> exceptional >>> path might seem problematic, but as the code generation is >>> magnitudes more >>> expensive than the exception it doesn't seem fruitful to go to >>> lengths to avoid >>> the CNFE. >>> >>> More notes along with some results can be found here: >>> >>> http://cr.openjdk.java.net/~redestad/scratch/bmh_species_gen.txt >>> >>> Thanks! >>> >>> /Claes > From mandy.chung at oracle.com Fri Mar 25 15:00:21 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 25 Mar 2016 08:00:21 -0700 Subject: RFR: 8152641: Plugin to generate BMH$Species classes ahead-of-time In-Reply-To: <56F5520D.3080205@oracle.com> References: <56F3EEAB.4090600@oracle.com> <1FE3F7A6-1C7B-4DC6-875C-E3FAEDED08F5@oracle.com> <56F50EC5.6020500@gmail.com> <56F5520D.3080205@oracle.com> Message-ID: <1A137395-0D73-45B4-9911-0E626804DE00@oracle.com> > On Mar 25, 2016, at 7:58 AM, Claes Redestad wrote: > > Hi, > > On 2016-03-25 11:11, Peter Levart wrote: >> Hi Claes, Mandy, >> >> On 03/25/2016 02:51 AM, Mandy Chung wrote: >>> Hi Claes, >>> >>> This is a good interesting work to generate BoundMethodHandle$Species_* classes at link time. This will save the class generation time. Instead of Class.forName, you may want to have a class (similar to SystemModules [1]) that will be updated at link time so that BoundMethodHandle can reference it statically to determine what species are generated at link time and even return statically Class of the generated class. >> >> You may still want to load this classes lazily when needed. Otherwise the BMH.CLASS_CACHE could simply be pre-populated with name -> Class entries at appropriate early time. > > I think laziness is a good property here, since it won't penalize modular applications that choose to instruct jlink to pregenerate a lot of BMH classes. > > Perhaps we can allow for static resolve + lazy classload by emitting a switch equivalent to: > > switch (types) { > case "LL": > return Species_LL.class; > case "L3": > return Species_L3.class; > .. > default: > return generateBMHSpeciesClass(types); > } > This is exactly what I was thinking. Mandy From anthony.vanelverdinghe at gmail.com Fri Mar 25 20:08:23 2016 From: anthony.vanelverdinghe at gmail.com (Anthony Vanelverdinghe) Date: Fri, 25 Mar 2016 21:08:23 +0100 Subject: jdeps -check: add section on exports In-Reply-To: <56F44651.3050302@oracle.com> References: <56F2DFD0.70106@gmail.com> <1652856612.2441234.1458757914364.JavaMail.zimbra@u-pem.fr> <56F441F3.8000103@gmail.com> <56F44651.3050302@oracle.com> Message-ID: <56F59AB7.8@gmail.com> What's the next step? Will someone with JIRA access file a javac enhancement for this, or shall I do so myself through bugs.java.com? (I'm not sure what the preferred option is for issues that have already been discussed on the mailing list) Thanks, Anthony On 24/03/2016 20:56, Alex Buckley wrote: > I think this is very well argued. > > Alex > > On 3/24/2016 12:37 PM, Anthony Vanelverdinghe wrote: >> I believe an error would be too harsh. Suppose I have a method: >> >> public CustomList getFoos() { ... } >> >> with problematic type CustomList. Then there are multiple options to >> resolve this, e.g.: >> - replace CustomList with a super type, likely List/Collection >> - make the method (package-)private >> - move CustomList to an exported package >> - export CustomList's package >> >> I believe that the last option would typically not be the best one >> (assuming the developer has given some thought to which set of packages >> to export & there are relatively few problematic usages). However, if >> javac would treat this as an error, some developers would be annoyed by >> their module not compiling and choose the path of least resistance: add >> a bunch of "exports" clauses to module-info.java in order to make the >> compiler happy (especially if the compiler would propose them to do so). >> If, on the other hand, it were an -Xlint check or warning, those >> developers wouldn't be bothered, and other developers could still use >> -Werror to have them treated as an error instead. >> >> Moreover, I don't think an issue like this should fail the compilation: >> even if the example above would make it into a module: at worst a client >> could treat the result as an accessible super-type & use it (analog, for >> the case where an inaccessible type is used as a parameter, where a >> client could try to pass in an accessible subclass instance). But even >> then: the module could subsequently fix the issue (thereby possibly >> breaking some clients, but I'd say it wasn't very responsible of them to >> use inaccessible types in the first place). >> >> Kind regards, >> Anthony >> >> On 23/03/2016 19:31, Remi Forax wrote: >>> In my opinion, it should be a warning (or even an error) in javac, >>> you should not create a bad module in the first place. >>> >>> R?mi >>> >>> ----- Mail original ----- >>>> De: "Anthony Vanelverdinghe" >>>> ?: jigsaw-dev at openjdk.java.net >>>> Envoy?: Mercredi 23 Mars 2016 19:26:24 >>>> Objet: jdeps -check: add section on exports >>>> >>>> Hi >>>> >>>> It would be great if jdeps -check would also have a section on exports: >>>> this section would list non-exported packages which contain types that >>>> are exposed (e.g. through method signatures) by exported packages. >>>> Ideally, those appearances should be listed under each package, i.e.: >>>> >>>> com.foo.impl >>>> type X is exposed by member Y of exported type Z >>>> >>>> Using this, one could easily see whether the package should indeed be >>>> exported, or whether a method was mistakenly made public, or ... >>>> >>>> JDK-8147050 already mentions the similar case of checking whether or not >>>> a "requires" ought to be public. >>>> >>>> What do you think? Should I file an issue for this? >>>> >>>> Kind regards, >>>> Anthony >>>> From stefan.dollase at rwth-aachen.de Sat Mar 26 02:45:57 2016 From: stefan.dollase at rwth-aachen.de (Stefan Dollase) Date: Sat, 26 Mar 2016 03:45:57 +0100 Subject: Add multiplicity declaration to use clause of service consuming module Message-ID: Hello, I read the article in [1], which describes the problem that jlink cannot figure out which service providing modules should be included into the custom modular run-time image. In [2] there is a statement about this: Previously, jlink included all service providing modules. Now, none of them is included. Since I am not sure whether this was already discussed, I would like to suggest a third approach: My suggestion is to add a multiplicity declaration to the module-info.java file for each uses clause. Here is an example: module com.socket { uses one com.socket.spi.NetworkSocketProvider; } This declares that the module `com.socket` requires exactly one implementation of the service `com.socket.spi.NetworkSocketProvider`. Here are further suggestions for multiplicity keywords: * optional - requires either zero or exactly one implementation * one - requires exactly one implementation * at least one - requires at least one implementation (this needs a better keyword) * any - any number of implementations is sufficient, even zero I suggest to require a multiplicity declaration, so the intent is always clear. However, it will also work to choose a default when no explicit declaration is given. Currently, any is the default. Adding a multiplicity declaration to the uses clause of the service consuming module allows to nicely solve the problem that is described in the article. Now, the jlink tool can check whether the multiplicity declaration is fulfilled. Then, it can include only the required service providing modules into the custom modular run-time image. Besides this declaration, one might add convenience methods to the ServiceLoader class. Currently, there is only ServiceLoader::iterator. I suggest to add the following methods: * loadOptional() - checks that there is exactly zero or one implementation and returns an Optional<> containing a new instance of the implementation, if any, throws a RuntimeException or Error if there is not exactly zero or one implementation * loadOne() - checks that there is exactly one implementation available and returns an instance of the implementation, throws a RuntimeException or Error if there is not exactly one implementation * loadAtLeastOne() - checks that there is at least one implementation available and returns a Set of instances of the implementations, throws a RuntimeException or Error if there is not at least one implementation * loadAny() - returns a Set of instances of the available implementations I think these methods should throw an Error, since the condition can and should be checked at compile-time. Thus, it is a fatal error if the constraint is not met at run-time. Finally, it might be helpful to be able to explicitly declare which service implementations are provided to which service consumers. For example, given a service `S` with the implementations `S1`, `S2` and `S3` provided by the modules `M1`, `M2` and `M3`. `S` is used by the modules `SC1` and `SC2`. `SC1` requires exactly one implementation of `S` while `SC2` requires any number of implementations. Now, it is unclear which implementation should be used by which service consuming module. Currently, the service consuming module will decide this manually in the code by iterating over all provided implementations. I think this should be explicitly declared. For example, one might declare that for `SC1`, `S` is provided with the implementation `S1`, but for `SC2`, `S` is provided with the implementations `S2` and `S3`. The great thing about this explicit declaration is, that tools like jlink can use this information, so it becomes even more clear which modules are required at run-time. Provided that `SC1` and `SC2` are included in the custom modular run-time image, the service configuration given above implies that also `M1`, `M2` and `M3` have to be included in the custom modular run-time image. If the service configuration is changed so for `SC2`, `S` is only provided with the implementation `S1`, then only `M1` has to be included into the custom modular run-time image, but `M2` and `M3` can be omitted. Also, my suggestion is that this is an interpreted document instead of a compiled one, so it can easily be changed after a release. For example, if an application uses a logging service it would be helpful to be able to add a custom logging service implementation to the module path and simply change the implementation which is used by the application by changing the service configuration file. This also implies that there should be a tool to validate the service configuration via the command line. Here is a summary of the proposed changes: * add a multiplicity declaration to the uses clause * use the multiplicity declaration to validate the current configuration of service consumers and service providers * include all required service provider modules when executing jlink * add convenience methods to the ServiceLoader class which match the introduced multiplicity declarations * add an (interpreted) document to explicitly declare the service configuration * add a command-line tool to validate the service configuration I am happy to hear any feedback. If you have trouble understanding my suggestions, please don't hesitate to ask for clarification. Again, I am not sure whether this topic was already discussed. I was unable to find it. If it was, please feel free to ignore this mail and send me a link to the discussion. [1]: https://blog.codecentric.de/en/2016/01/java9-jigsaw-missing-piece/ [2]: https://twitter.com/mreinhold/status/665122968851382273 Regards Stefan Dollase From peter.levart at gmail.com Sat Mar 26 11:47:22 2016 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 26 Mar 2016 12:47:22 +0100 Subject: RFR: 8152641: Plugin to generate BMH$Species classes ahead-of-time In-Reply-To: <56F5520D.3080205@oracle.com> References: <56F3EEAB.4090600@oracle.com> <1FE3F7A6-1C7B-4DC6-875C-E3FAEDED08F5@oracle.com> <56F50EC5.6020500@gmail.com> <56F5520D.3080205@oracle.com> Message-ID: <56F676CA.5000803@gmail.com> Hi Claes, Mandy, On 03/25/2016 03:58 PM, Claes Redestad wrote: > Hi, > > On 2016-03-25 11:11, Peter Levart wrote: >> Hi Claes, Mandy, >> >> On 03/25/2016 02:51 AM, Mandy Chung wrote: >>> Hi Claes, >>> >>> This is a good interesting work to generate >>> BoundMethodHandle$Species_* classes at link time. This will save >>> the class generation time. Instead of Class.forName, you may want >>> to have a class (similar to SystemModules [1]) that will be updated >>> at link time so that BoundMethodHandle can reference it statically >>> to determine what species are generated at link time and even return >>> statically Class of the generated class. >> >> You may still want to load this classes lazily when needed. Otherwise >> the BMH.CLASS_CACHE could simply be pre-populated with name -> >> Class entries at appropriate early time. > > I think laziness is a good property here, since it won't penalize > modular applications that choose to instruct jlink to pregenerate a > lot of BMH classes. > > Perhaps we can allow for static resolve + lazy classload by emitting a > switch equivalent to: > > switch (types) { > case "LL": > return Species_LL.class; > case "L3": > return Species_L3.class; > .. > default: > return generateBMHSpeciesClass(types); > } Comparing this with proposed code from webrev: 493 try { 494 return (Class) 495 Class.forName("java.lang.invoke.BoundMethodHandle$Species_" + LambdaForm.shortenSignature(types)); 496 } catch (ClassNotFoundException cnf) { 497 // Not pregenerated, generate the class 498 return generateConcreteBMHClass(types); 499 } ...note that the function passed to CLASS_CACHE.computeIfAbsent is executed just once per distinct 'types' argument. Even if you put the generated switch between a call to getConcreteBMHClass and CLASS_CACHE.computeIfAbsent, getConcreteBMHClass(String types) is executed just once per distinct 'types' argument (except in rare occasions when VM can not initialize the loaded class). In this respect a successful Class.forName() is not any worse than static resolving. It's just that unsuccessful Class.forName() represents some overhead for classes that are not pre-generated. So an alternative way to get rid of that overhead is to have a HashSet of 'types' strings for pre-generated classes at hand in order to decide whether to call Class.forName or generateConcreteBMHClass. What's easier to support is another question. Regards, Peter > >> >>> >>> About CNFE, the new Class.forName(Module, String) method does not >>> throw CNFE that you could use instead (if not static reference as >>> suggested above). If not found, it will return null. > > Thanks, this one had passed under my radar. :-) > >>> >>> This plugin accesses the non-public methods in BoundMethodHandle >>> and has to invoke it via reflection. With module boundary enforced >>> now, maybe we could consider moving to some internal package to >>> share with this jlink plugin. >>> >>> I think there are tests needed to be updated when a new plugin is >>> added. >>> >>> Mandy >>> [1] >>> http://hg.openjdk.java.net/jdk9/dev/jdk/file/3abd25870915/src/java.base/share/classes/jdk/internal/module/SystemModules.java >> >> One thing to consider is the following: the names of the classes obey >> a particular convention which is now hardcoded in two places: the >> BoundMethodHandle and the GenerateBMHClassesPlugin. You could have a >> method with the following signature in BoundMethodHandle$Factory: >> >> Map.Entry generateConcreteBMHClassBytes(String types) >> >> ...which would also return the name of the class derived from the >> types which you would then use to derive the path of the .class file >> in the module of the image. Also, this method - although >> package-private becomes part of the API and that should be written in >> a comment. >> >> What do you think? > > Definitely should add a comment about generateConcreteBMHClassBytes > being an internal API used by the plugin. > > I'm open to the idea of moving static utility code to some internal > package, but want to hear what maintainers of java.lang.invoke think > about factoring out utility code like this. > > Thanks! > > /Claes > >> >> Regards, Peter >> >>> >>>> On Mar 24, 2016, at 6:42 AM, Claes Redestad >>>> wrote: >>>> >>>> Hi, >>>> >>>> please review this patch which add an enabled-by-default plugin to >>>> generate a >>>> configurable list of BoundMethodHandle$Species_*-classes using jlink. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152641 >>>> Webrev: http://cr.openjdk.java.net/~redestad/8152641/webrev.01/ >>>> >>>> This plugin adds the --generate-bmh flag to jlink, which takes a >>>> comma-separated list of shortened species type strings. >>>> >>>> As an example: --generate-bmh LL,L3,L4 will generate >>>> BoundMethodHandle$Species_LL, ...$Species_L3 and ...$Species_L4 and >>>> add >>>> them to the java.base module. >>>> >>>> The Species class lookup in BoundMethodHandle will first check if >>>> there is a >>>> generated class, otherwise generate it as previously. Adding an >>>> exceptional >>>> path might seem problematic, but as the code generation is >>>> magnitudes more >>>> expensive than the exception it doesn't seem fruitful to go to >>>> lengths to avoid >>>> the CNFE. >>>> >>>> More notes along with some results can be found here: >>>> >>>> http://cr.openjdk.java.net/~redestad/scratch/bmh_species_gen.txt >>>> >>>> Thanks! >>>> >>>> /Claes >> > From Alan.Bateman at oracle.com Sun Mar 27 08:36:12 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 27 Mar 2016 09:36:12 +0100 Subject: Add multiplicity declaration to use clause of service consuming module In-Reply-To: References: Message-ID: <56F79B7C.3030702@oracle.com> On 26/03/2016 02:45, Stefan Dollase wrote: > Hello, > > I read the article in [1], which describes the problem that jlink cannot > figure out which service providing modules should be included into the > custom modular run-time image. In [2] there is a statement about this: > Previously, jlink included all service providing modules. Now, none of them > is included. Since I am not sure whether this was already discussed, I > would like to suggest a third approach: JEP 282 [1] lists services as an open issue. Yes, it was the case, at least for a brief period, that service providers were linked in automatically. It immediately leads to calls for ways to keep providers out and it gets very complicated once you have a command-line that it try to add and exclude modules at the same time. So as things stand, jlink is an advanced tool and you do need to know about service providers when creating a custom runtime image. If you want specific crypto support or a specific dynamic language then you need specify the names of the modules to -addmods when creating the runtime image. On extending the `uses` clause then this may be something to send to jpms-spec-comments for consideration if you feel it is important. One thing to be aware of is that the early exploratory phase of Project Jigsaw had `requires service S` and `requires optional service S`. The former could cause resolution to fail if there weren't any modules providing implementations of S. The latter is more like what we have today with `uses`. At least for usages in the JDK, then we almost always used the latter in the prototypes at the time. One reason is the consumer modules often have a default implementation to use when there aren't any implementations deployed. The java.xml module has a default implementation of each of the XML parser types for example. There are a few cases, like the java.scripting or java.naming modules where there isn't any notion of the default implementation but it's not an error in either case to link or run without any service providers. The reason is that service provider modules may be loaded at runtime, maybe into module layers that a container creates. -Alan [1] http://openjdk.java.net/jeps/282 From alan.bateman at oracle.com Sun Mar 27 08:39:10 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 27 Mar 2016 08:39:10 +0000 Subject: hg: jigsaw/jake/hotspot: -XX:+EnableJVMCI implies -addmods jdk.vm.ci Message-ID: <201603270839.u2R8dA6f000867@aojmv0008.oracle.com> Changeset: 7356066f452f Author: alanb Date: 2016-03-27 09:38 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7356066f452f -XX:+EnableJVMCI implies -addmods jdk.vm.ci ! src/share/vm/runtime/arguments.cpp From alan.bateman at oracle.com Sun Mar 27 08:40:08 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 27 Mar 2016 08:40:08 +0000 Subject: hg: jigsaw/jake/corba: JNDI CosNaming provider can be located via fallback mechanism Message-ID: <201603270840.u2R8e89V001119@aojmv0008.oracle.com> Changeset: 0bd4a67bc14c Author: alanb Date: 2016-03-27 09:39 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/0bd4a67bc14c JNDI CosNaming provider can be located via fallback mechanism ! src/java.corba/share/classes/module-info.java From alan.bateman at oracle.com Sun Mar 27 09:25:32 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 27 Mar 2016 09:25:32 +0000 Subject: hg: jigsaw/jake/jdk: jdk.rmic should not be root Message-ID: <201603270925.u2R9PWgU015674@aojmv0008.oracle.com> Changeset: 542dbe7bfd9f Author: alanb Date: 2016-03-27 10:25 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/542dbe7bfd9f jdk.rmic should not be root ! make/launcher/Launcher-jdk.rmic.gmk ! src/java.base/share/conf/security/java.security - src/jdk.rmic/share/classes/jdk/rmi/rmic/Main.java ! src/jdk.rmic/share/classes/module-info.java ! test/java/lang/SecurityManager/RestrictedPackages.java From sundararajan.athijegannathan at oracle.com Mon Mar 28 08:37:10 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 28 Mar 2016 14:07:10 +0530 Subject: RFR: 8152143: jlink --include-locales should gracefully detect certain user error In-Reply-To: <56F411DE.2010208@oracle.com> References: <56F31CFC.9060403@oracle.com> <56F38DF5.5080805@oracle.com> <56F40D12.2020604@oracle.com> <56F411DE.2010208@oracle.com> Message-ID: <56F8ED36.6010308@oracle.com> Looks good to me. -Sundar On 3/24/2016 9:42 PM, Naoto Sato wrote: > And the fix is here. Please review this as well. > > http://cr.openjdk.java.net/~naoto/8152704/webrev.00/ > > Naoto > > On 3/24/16 8:51 AM, Naoto Sato wrote: >> Hi Mandy, Sundar, Alan, >> >> Thank you for your reviews. >> >> On 3/23/16 11:49 PM, Alan Bateman wrote: >>> On 23/03/2016 22:47, Naoto Sato wrote: >>>> Hello, >>>> >>>> Please review the fix to the following bug: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8152143 >>>> >>>> The fix is located at: >>>> >>>> http://cr.openjdk.java.net/~naoto/8152143/webrev.02/ >>> One little nit that I didn't notice before is "eg: en,ja,*-IN" where I >>> assume should be "e.g." >> >> I copied the part from another plugin. As I've already pushed the above >> change, I created an issue specific for >> this(https://bugs.openjdk.java.net/browse/JDK-8152704), and will fix >> them shortly. >> >> Naoto From forax at univ-mlv.fr Mon Mar 28 10:13:47 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 28 Mar 2016 12:13:47 +0200 (CEST) Subject: modulepath and classpath mixture In-Reply-To: <56F2B3DA.402@oracle.com> References: <56CC57A1.2050109@oracle.com> <56F2440A.7010505@oracle.com> <56F2914C.3030706@oracle.com> <56F2B3DA.402@oracle.com> Message-ID: <1228911717.349701.1459160027285.JavaMail.zimbra@u-pem.fr> Hi Stephen, Hi all, I think that delivering tests as a separated module is a bad idea. I see that from the point of a developer, seeing the code and the test as different modules can be attractive because everything seems to be put at the right place but there is a big drawback. Because modules are reified at runtime, it means that the runtime environment of the tests will be different from the production environment. So as Alan said, from the jigsaw point of view at runtime, the tests and the code should be in the same module. So the building tools have to come with a way to support to have 2 different module-info.java in two different folders and package them as one module, maybe javac should help by providing a way to merge 2 module-info at compile time. R?mi ----- Mail original ----- > De: "Alan Bateman" > ?: "Stephen Colebourne" , "jigsaw-dev" > Envoy?: Mercredi 23 Mars 2016 16:18:50 > Objet: Re: modulepath and classpath mixture > > > On 23/03/2016 14:42, Stephen Colebourne wrote: > > : > > > > I don't particularly care what the mechanism is for this, but at the > > requirements level: > > - there are two modules - main and test > > - each has its own source tree > > - each has its own dependencies > > - each is released separately > > - each could be hosted on a central repo > > - the test module needs to be able to contain the same packages as the > > main module > > - the test module needs to be able to invoke package-scoped code in > > the same package in the main module > > > > To clarify further consider 4 modules, A, B, A-test and B-test where B > > depends on A. Module A-test may have a method foo() that uses package > > scope to access something in A. Module B-test will depend on A-test > > and rely on foo() to get access to that internal object. > To your list, I would add the ability to make use of testing frameworks > like TestNG and JUnit. > > In any case, and as things currently stand, you've got most of the > above. One differences is that the tests are not a separate module, they > are instead compiled and run in a way that patches the main module. The > second difference is that they don't have their own module declaration, > instead the compilation or run augments the dependences with any > additional dependences that the tests have. As I said, if they tools > makes it easy then I don't think it's too bad. > > > > > (Note that I view the thread discussion of > > references to test classes on the classpath as another hack. > > > Packages can't be split between modules and classpath so there is no > support for that. > > -Alan > From alan.bateman at oracle.com Mon Mar 28 11:14:46 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 28 Mar 2016 11:14:46 +0000 Subject: hg: jigsaw/jake/jdk: 2 new changesets Message-ID: <201603281114.u2SBEktj016387@aojmv0008.oracle.com> Changeset: 1515cfb2143e Author: alanb Date: 2016-03-28 09:19 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1515cfb2143e Fixed typo in javadoc ! src/java.base/share/classes/java/util/ServiceLoader.java Changeset: 84ccd36adb13 Author: alanb Date: 2016-03-28 12:14 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/84ccd36adb13 Only modules that export APIs should be removed when initial module is the class path ! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java ! test/java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java ! test/jdk/modules/etc/VerifyModuleDelegation.java ! test/tools/jimage/VerifyJimage.java From ali.ebrahimi1781 at gmail.com Mon Mar 28 12:55:48 2016 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Mon, 28 Mar 2016 17:25:48 +0430 Subject: modulepath and classpath mixture In-Reply-To: <1228911717.349701.1459160027285.JavaMail.zimbra@u-pem.fr> References: <56CC57A1.2050109@oracle.com> <56F2440A.7010505@oracle.com> <56F2914C.3030706@oracle.com> <56F2B3DA.402@oracle.com> <1228911717.349701.1459160027285.JavaMail.zimbra@u-pem.fr> Message-ID: I think we can adapt OSGI fragment bundle here and introduce module fragments that is attached to a host module. So we would have test fragment that is embeded in main module. So we would have one module. What do you think? On Mon, Mar 28, 2016 at 2:43 PM, Remi Forax wrote: > Hi Stephen, Hi all, > I think that delivering tests as a separated module is a bad idea. > > I see that from the point of a developer, seeing the code and the test as > different modules can be attractive because everything seems to be put at > the right place but there is a big drawback. Because modules are reified at > runtime, it means that the runtime environment of the tests will be > different from the production environment. > > So as Alan said, from the jigsaw point of view at runtime, the tests and > the code should be in the same module. > > So the building tools have to come with a way to support to have 2 > different module-info.java in two different folders and package them as one > module, > maybe javac should help by providing a way to merge 2 module-info at > compile time. > > R?mi > > ----- Mail original ----- > > De: "Alan Bateman" > > ?: "Stephen Colebourne" , "jigsaw-dev" < > jigsaw-dev at openjdk.java.net> > > Envoy?: Mercredi 23 Mars 2016 16:18:50 > > Objet: Re: modulepath and classpath mixture > > > > > > On 23/03/2016 14:42, Stephen Colebourne wrote: > > > : > > > > > > I don't particularly care what the mechanism is for this, but at the > > > requirements level: > > > - there are two modules - main and test > > > - each has its own source tree > > > - each has its own dependencies > > > - each is released separately > > > - each could be hosted on a central repo > > > - the test module needs to be able to contain the same packages as the > > > main module > > > - the test module needs to be able to invoke package-scoped code in > > > the same package in the main module > > > > > > To clarify further consider 4 modules, A, B, A-test and B-test where B > > > depends on A. Module A-test may have a method foo() that uses package > > > scope to access something in A. Module B-test will depend on A-test > > > and rely on foo() to get access to that internal object. > > To your list, I would add the ability to make use of testing frameworks > > like TestNG and JUnit. > > > > In any case, and as things currently stand, you've got most of the > > above. One differences is that the tests are not a separate module, they > > are instead compiled and run in a way that patches the main module. The > > second difference is that they don't have their own module declaration, > > instead the compilation or run augments the dependences with any > > additional dependences that the tests have. As I said, if they tools > > makes it easy then I don't think it's too bad. > > > > > > > > (Note that I view the thread discussion of > > > references to test classes on the classpath as another hack. > > > > > Packages can't be split between modules and classpath so there is no > > support for that. > > > > -Alan > > > -- Best Regards, Ali Ebrahimi From stephen.felts at oracle.com Mon Mar 28 14:23:09 2016 From: stephen.felts at oracle.com (Stephen Felts) Date: Mon, 28 Mar 2016 07:23:09 -0700 (PDT) Subject: modulepath and classpath mixture In-Reply-To: References: <56CC57A1.2050109@oracle.com> <56F2440A.7010505@oracle.com> <56F2914C.3030706@oracle.com> <56F2B3DA.402@oracle.com> <1228911717.349701.1459160027285.JavaMail.zimbra@u-pem.fr> Message-ID: <0ccbd90a-9585-4a27-9955-5e0f7c2afc74@default> Having spent 3 years using OSGI, fragment bundles were a great feature that we used to overcome this type of problem and others. I like the idea but I don't think it will be popular in Jigsaw (and OSGI is a four-letter word). -----Original Message----- From: Ali Ebrahimi [mailto:ali.ebrahimi1781 at gmail.com] Sent: Monday, March 28, 2016 8:56 AM To: Remi Forax Cc: jigsaw-dev Subject: Re: modulepath and classpath mixture I think we can adapt OSGI fragment bundle here and introduce module fragments that is attached to a host module. So we would have test fragment that is embeded in main module. So we would have one module. What do you think? On Mon, Mar 28, 2016 at 2:43 PM, Remi Forax wrote: > Hi Stephen, Hi all, > I think that delivering tests as a separated module is a bad idea. > > I see that from the point of a developer, seeing the code and the test > as different modules can be attractive because everything seems to be > put at the right place but there is a big drawback. Because modules > are reified at runtime, it means that the runtime environment of the > tests will be different from the production environment. > > So as Alan said, from the jigsaw point of view at runtime, the tests > and the code should be in the same module. > > So the building tools have to come with a way to support to have 2 > different module-info.java in two different folders and package them > as one module, maybe javac should help by providing a way to merge 2 > module-info at compile time. > > R?mi > > ----- Mail original ----- > > De: "Alan Bateman" > > ?: "Stephen Colebourne" , "jigsaw-dev" < > jigsaw-dev at openjdk.java.net> > > Envoy?: Mercredi 23 Mars 2016 16:18:50 > > Objet: Re: modulepath and classpath mixture > > > > > > On 23/03/2016 14:42, Stephen Colebourne wrote: > > > : > > > > > > I don't particularly care what the mechanism is for this, but at > > > the requirements level: > > > - there are two modules - main and test > > > - each has its own source tree > > > - each has its own dependencies > > > - each is released separately > > > - each could be hosted on a central repo > > > - the test module needs to be able to contain the same packages as > > > the main module > > > - the test module needs to be able to invoke package-scoped code > > > in the same package in the main module > > > > > > To clarify further consider 4 modules, A, B, A-test and B-test > > > where B depends on A. Module A-test may have a method foo() that > > > uses package scope to access something in A. Module B-test will > > > depend on A-test and rely on foo() to get access to that internal object. > > To your list, I would add the ability to make use of testing > > frameworks like TestNG and JUnit. > > > > In any case, and as things currently stand, you've got most of the > > above. One differences is that the tests are not a separate module, > > they are instead compiled and run in a way that patches the main > > module. The second difference is that they don't have their own > > module declaration, instead the compilation or run augments the > > dependences with any additional dependences that the tests have. As > > I said, if they tools makes it easy then I don't think it's too bad. > > > > > > > > (Note that I view the thread discussion of references to test > > > classes on the classpath as another hack. > > > > > Packages can't be split between modules and classpath so there is no > > support for that. > > > > -Alan > > > -- Best Regards, Ali Ebrahimi From martinrb at google.com Mon Mar 28 15:36:57 2016 From: martinrb at google.com (Martin Buchholz) Date: Mon, 28 Mar 2016 08:36:57 -0700 Subject: Troubles running javadoc with jsr166 CVS and jigsaw integration In-Reply-To: References: <56F483A8.7090406@oracle.com> Message-ID: The current status: we have updated jsr166 CVS to run with jdk9-ea+111, but jdk9 javadoc doesn't work to create the traditional jsr166 javadoc we have been publishing for 10 years, so we are working around this temporarily by running jdk8 javadoc on our jdk8 backport. On Thu, Mar 24, 2016 at 8:50 PM, Martin Buchholz wrote: > (last minute fiddling with ant properties ... hope this works:) > > cvs -Q -d ':pserver:anonymous:@gee.cs.oswego.edu/home/jsr166/jsr166' > checkout jsr166 && cd jsr166 && ant -Djdk9.home="$JDK9_IMAGE" > -Djdk9.src.home="$JDK9_SOURCE_FOREST" docs > > where $JDK9_IMAGE is an image for +110 or +111, and > $JDK9_SOURCE_FOREST is a mercurial forest for +110 or +111 > > Use "ant -v" to get much more verbose diagnostics. > > > On Thu, Mar 24, 2016 at 5:17 PM, Jonathan Gibbons > wrote: >> Martin, >> >> Can you provide details on how to reproduce this (e.g. including repo paths) >> >> -- Jon >> >> >> On 03/24/2016 04:10 PM, Martin Buchholz wrote: >>> >>> Hi jigsaw/javadoc folk, >>> >>> I'm trying to update jsr166 CVS to latest jdks and failing. >>> >>> If I run "ant docs" with a -Djdk9.home pointing at jdk-9+110 binaries >>> and -Djdk9.src.dir pointing at openjdk9 tip sources, I get: >>> >>> [javadoc] Constructing Javadoc information... >>> [javadoc] Standard Doclet (Next) version 9-ea >>> [javadoc] Building tree for all the packages and classes... >>> [javadoc] Generating >>> >>> /usr/local/google/home/martinrb/jsr166/javadoc/build/docs/constant-values.html... >>> [javadoc] 1 error >>> [javadoc] javadoc: error - >>> com.sun.tools.javac.code.ClassFinder$BadClassFile: bad class file: >>> /modules/java.base/java/util/ServiceLoader$LazyIterator.class >>> [javadoc] undeclared type variable: S >>> [javadoc] Please remove or make sure it appears in the correct >>> subdirectory of the classpath. >>> >>> Hmmm ?? ... don't know what to do about that ... except upgrade to +111 >>> ... >>> Binaries are not available yet, but I can build my own. If I then >>> point -Djdk9.home at a freshly built jdk at tip, I get: >>> >>> [javadoc] 1 error >>> [javadoc] java.lang.AssertionError >>> [javadoc] at >>> com.sun.tools.javac.util.Assert.error(jdk.compiler at 9-internal/Assert.java:155) >>> [javadoc] at >>> com.sun.tools.javac.util.Assert.checkNull(jdk.compiler at 9-internal/Assert.java:54) >>> [javadoc] at >>> com.sun.tools.javac.code.Symtab.enterModule(jdk.compiler at 9-internal/Symtab.java:753) >>> [javadoc] at >>> com.sun.tools.javac.comp.Modules.enterModule(jdk.compiler at 9-internal/Modules.java:257) >>> [javadoc] at >>> com.sun.tools.javac.comp.Modules.enterModules(jdk.compiler at 9-internal/Modules.java:235) >>> [javadoc] at >>> com.sun.tools.javac.comp.Modules.enter(jdk.compiler at 9-internal/Modules.java:203) >>> [javadoc] at >>> com.sun.tools.javac.main.JavaCompiler.readSourceFile(jdk.compiler at 9-internal/JavaCompiler.java:816) >>> [javadoc] at >>> com.sun.tools.javac.main.JavaCompiler.readSourceFile(jdk.compiler at 9-internal/JavaCompiler.java:778) >>> [javadoc] at >>> com.sun.tools.javac.main.JavaCompiler.access$100(jdk.compiler at 9-internal/JavaCompiler.java:97) >>> [javadoc] at >>> com.sun.tools.javac.main.JavaCompiler$1.complete(jdk.compiler at 9-internal/JavaCompiler.java:339) >>> [javadoc] at >>> com.sun.tools.javac.code.ClassFinder.fillIn(jdk.compiler at 9-internal/ClassFinder.java:362) >>> [javadoc] at >>> com.sun.tools.javac.code.ModuleFinder.lambda$findSingleModule$0(jdk.compiler at 9-internal/ModuleFinder.java:206) >>> [javadoc] at >>> com.sun.tools.javac.code.Symbol.complete(jdk.compiler at 9-internal/Symbol.java:601) >>> [javadoc] at >>> com.sun.tools.javac.comp.Modules.setCompilationUnitModules(jdk.compiler at 9-internal/Modules.java:361) >>> [javadoc] at >>> com.sun.tools.javac.comp.Modules.enter(jdk.compiler at 9-internal/Modules.java:205) >>> [javadoc] at >>> jdk.javadoc.internal.tool.JavadocTool.getEnvironment(jdk.javadoc at 9-internal/JavadocTool.java:190) >>> [javadoc] at >>> jdk.javadoc.internal.tool.Start.parseAndExecute(jdk.javadoc at 9-internal/Start.java:401) >>> [javadoc] at >>> jdk.javadoc.internal.tool.Start.begin(jdk.javadoc at 9-internal/Start.java:274) >>> [javadoc] at >>> jdk.javadoc.internal.tool.Start.begin(jdk.javadoc at 9-internal/Start.java:220) >>> [javadoc] at >>> jdk.javadoc.internal.tool.Main.execute(jdk.javadoc at 9-internal/Main.java:70) >>> [javadoc] at >>> jdk.javadoc.internal.tool.Main.main(jdk.javadoc at 9-internal/Main.java:52) >>> [javadoc] javadoc: error - fatal error >> >> From martinrb at google.com Mon Mar 28 17:08:43 2016 From: martinrb at google.com (Martin Buchholz) Date: Mon, 28 Mar 2016 10:08:43 -0700 Subject: trouble with java -Xpatch Message-ID: The only doc for -Xpatch I can find is $ java -X |& grep -A2 Xpatch -Xpatch:=(:)* Override or augment a module with classes and resources in JAR files or directories BUT that syntax appears to have no effect, e.g. if I try java -Xpatch:java.base=$CLASSES that seems to have no effect, whatever the value of $CLASSES, and there is no warning/error if $CLASSES doesn't exist in the filesystem, which seems like a bug. Currently java -Xpatch:$CLASSES does work, but only if $CLASSES is a directory, not a jar file, which seems like a bug. If I have two separate -Xpatch flags, then I get: $ java -Xpatch:junk -Xpatch:junk -help Error occurred during initialization of VM java.lang.ExceptionInInitializerError at java.lang.module.SystemModuleFinder.(java.base/SystemModuleFinder.java:129) at java.lang.module.ModuleFinder.ofSystem(java.base/ModuleFinder.java:165) at jdk.internal.module.ModuleBootstrap.boot(java.base/ModuleBootstrap.java:98) at java.lang.System.initPhase2(java.base/System.java:1916) Caused by: java.lang.IllegalArgumentException: Unable to parse: junk at jdk.internal.module.ModulePatcher.throwIAE(java.base/ModulePatcher.java:583) at jdk.internal.module.ModulePatcher.decodeProperties(java.base/ModulePatcher.java:97) at jdk.internal.module.ModulePatcher.(java.base/ModulePatcher.java:73) at java.lang.module.SystemModuleFinder.(java.base/SystemModuleFinder.java:129) at java.lang.module.ModuleFinder.ofSystem(java.base/ModuleFinder.java:165) at jdk.internal.module.ModuleBootstrap.boot(java.base/ModuleBootstrap.java:98) at java.lang.System.initPhase2(java.base/System.java:1916) I expect to get "Unable to parse: junk" even with just a single -Xpatch:junk, but I don't. I might have filed bugs, but I don't know where. From Alan.Bateman at oracle.com Mon Mar 28 17:13:37 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 28 Mar 2016 18:13:37 +0100 Subject: Troubles running javadoc with jsr166 CVS and jigsaw integration In-Reply-To: References: <56F483A8.7090406@oracle.com> Message-ID: <56F96641.10300@oracle.com> On 28/03/2016 16:36, Martin Buchholz wrote: > The current status: we have updated jsr166 CVS to run with > jdk9-ea+111, but jdk9 javadoc doesn't work to create the traditional > jsr166 javadoc we have been publishing for 10 years, so we are working > around this temporarily by running jdk8 javadoc on our jdk8 backport. > > We have JDK-8152818 tracking this, I'm sure Kumar or Jon will figure this out quickly. -Alan From pbenedict at apache.org Mon Mar 28 17:21:09 2016 From: pbenedict at apache.org (Paul Benedict) Date: Mon, 28 Mar 2016 12:21:09 -0500 Subject: modulepath and classpath mixture In-Reply-To: <0ccbd90a-9585-4a27-9955-5e0f7c2afc74@default> References: <56CC57A1.2050109@oracle.com> <56F2440A.7010505@oracle.com> <56F2914C.3030706@oracle.com> <56F2B3DA.402@oracle.com> <1228911717.349701.1459160027285.JavaMail.zimbra@u-pem.fr> <0ccbd90a-9585-4a27-9955-5e0f7c2afc74@default> Message-ID: Stephen C, I'd like to question the assumption why tests must be their own module? Clearly tests are going to be their own artifact, but I am not sure they need the semantics of module boundaries. Placing on them classpath would be the best thing for them, I think. However, two requirements would still need to be met: (a) Split packages need to be allowed so test classes can live in the same package as the main classes (b) Test classes can replace main classes The patch/override command line argument already satisfies (b). Regarding (a), although the classpath exports everything, code in an named module can't access types in the unnamed module. That will be necessary so existing code in "main" can access the replacement classes in "test". If there was a mechanism to allow classpath code to overlay with module code, existing Maven projects could function normally. Cheers, Paul On Mon, Mar 28, 2016 at 9:23 AM, Stephen Felts wrote: > Having spent 3 years using OSGI, fragment bundles were a great feature > that we used to overcome this type of problem and others. > I like the idea but I don't think it will be popular in Jigsaw (and OSGI > is a four-letter word). > > > > -----Original Message----- > From: Ali Ebrahimi [mailto:ali.ebrahimi1781 at gmail.com] > Sent: Monday, March 28, 2016 8:56 AM > To: Remi Forax > Cc: jigsaw-dev > Subject: Re: modulepath and classpath mixture > > I think we can adapt OSGI fragment bundle here and introduce module > fragments that is attached to a host module. > > So we would have test fragment that is embeded in main module. So we would > have one module. > What do you think? > > On Mon, Mar 28, 2016 at 2:43 PM, Remi Forax wrote: > > > Hi Stephen, Hi all, > > I think that delivering tests as a separated module is a bad idea. > > > > I see that from the point of a developer, seeing the code and the test > > as different modules can be attractive because everything seems to be > > put at the right place but there is a big drawback. Because modules > > are reified at runtime, it means that the runtime environment of the > > tests will be different from the production environment. > > > > So as Alan said, from the jigsaw point of view at runtime, the tests > > and the code should be in the same module. > > > > So the building tools have to come with a way to support to have 2 > > different module-info.java in two different folders and package them > > as one module, maybe javac should help by providing a way to merge 2 > > module-info at compile time. > > > > R?mi > > > > ----- Mail original ----- > > > De: "Alan Bateman" > > > ?: "Stephen Colebourne" , "jigsaw-dev" < > > jigsaw-dev at openjdk.java.net> > > > Envoy?: Mercredi 23 Mars 2016 16:18:50 > > > Objet: Re: modulepath and classpath mixture > > > > > > > > > On 23/03/2016 14:42, Stephen Colebourne wrote: > > > > : > > > > > > > > I don't particularly care what the mechanism is for this, but at > > > > the requirements level: > > > > - there are two modules - main and test > > > > - each has its own source tree > > > > - each has its own dependencies > > > > - each is released separately > > > > - each could be hosted on a central repo > > > > - the test module needs to be able to contain the same packages as > > > > the main module > > > > - the test module needs to be able to invoke package-scoped code > > > > in the same package in the main module > > > > > > > > To clarify further consider 4 modules, A, B, A-test and B-test > > > > where B depends on A. Module A-test may have a method foo() that > > > > uses package scope to access something in A. Module B-test will > > > > depend on A-test and rely on foo() to get access to that internal > object. > > > To your list, I would add the ability to make use of testing > > > frameworks like TestNG and JUnit. > > > > > > In any case, and as things currently stand, you've got most of the > > > above. One differences is that the tests are not a separate module, > > > they are instead compiled and run in a way that patches the main > > > module. The second difference is that they don't have their own > > > module declaration, instead the compilation or run augments the > > > dependences with any additional dependences that the tests have. As > > > I said, if they tools makes it easy then I don't think it's too bad. > > > > > > > > > > > (Note that I view the thread discussion of references to test > > > > classes on the classpath as another hack. > > > > > > > Packages can't be split between modules and classpath so there is no > > > support for that. > > > > > > -Alan > > > > > > > > > -- > > Best Regards, > Ali Ebrahimi > From Alan.Bateman at oracle.com Mon Mar 28 17:30:25 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 28 Mar 2016 18:30:25 +0100 Subject: trouble with java -Xpatch In-Reply-To: References: Message-ID: <56F96A31.4080309@oracle.com> Sorry, it is a bit confusing as we aren't quite done with the transition from an older form of a -Xpatch to the new form. The syntax you see in JEP 261 and in the java -X usage output is the new form. That works for modules defined to the platform or application class loaders but doesn't work for modules (like java.base) that are defined to the boot loader. Lois is working on the missing piece in hotspot, it is tracked by JDK-8146448. All the other pieces (in javac and the runtime) are in place. In the mean-time, the old form still works. The old syntax is -Xpatch:(:*) where is a directory of exploded patches. If you want to override CHM then you would run with -Xpatch:jsr166 where jsr166 contains: java.base/java/util/concurrent/ConcurrentHashMap.class You can use the old syntax with the first usage of -Xpatch, not second or subsequent usages. That is why you see a difference in the -Xpatch:junk behavior when you specify it more than once. -Alan. From martinrb at google.com Mon Mar 28 18:49:56 2016 From: martinrb at google.com (Martin Buchholz) Date: Mon, 28 Mar 2016 11:49:56 -0700 Subject: trouble with java -Xpatch In-Reply-To: <56F96A31.4080309@oracle.com> References: <56F96A31.4080309@oracle.com> Message-ID: OK, sounds like we have a plan. Currently jsr166 development has no problem with -Xpatch in +111 because we use the old syntax. On Mon, Mar 28, 2016 at 10:30 AM, Alan Bateman wrote: > > Sorry, it is a bit confusing as we aren't quite done with the transition > from an older form of a -Xpatch to the new form. > > The syntax you see in JEP 261 and in the java -X usage output is the new > form. That works for modules defined to the platform or application class > loaders but doesn't work for modules (like java.base) that are defined to > the boot loader. Lois is working on the missing piece in hotspot, it is > tracked by JDK-8146448. All the other pieces (in javac and the runtime) are > in place. > > In the mean-time, the old form still works. The old syntax is > -Xpatch:(:*) where is a directory of exploded patches. If > you want to override CHM then you would run with -Xpatch:jsr166 where jsr166 > contains: > > java.base/java/util/concurrent/ConcurrentHashMap.class > > You can use the old syntax with the first usage of -Xpatch, not second or > subsequent usages. That is why you see a difference in the -Xpatch:junk > behavior when you specify it more than once. > > -Alan. From robbiexgibson at yahoo.com Tue Mar 29 09:10:18 2016 From: robbiexgibson at yahoo.com (Robert Gibson) Date: Tue, 29 Mar 2016 11:10:18 +0200 Subject: Jigsaw + Web Start Message-ID: <59A16BCA-975A-413D-A46C-F93F88704035@yahoo.com> Hi all, We have a number of applications launched over Web Start. Unfortunately none of them work with the latest JDK build, it looks like the closed-source Web Start implementation is not a testing priority for Oracle, so I put my shoulder to the wheel and filed a few bugs. Anyway, I haven't seen any mention of Web Start in the various Jigsaw documents, can I assume that there is a plan to add the "emergency hatch" VM options to the java-vm-args whitelist? Without it we are dead in the water, and I assume we are not alone! Thanks, Robert From michael.rasmussen at zeroturnaround.com Tue Mar 29 09:14:46 2016 From: michael.rasmussen at zeroturnaround.com (Michael Rasmussen) Date: Tue, 29 Mar 2016 12:14:46 +0300 Subject: trouble with java -Xpatch In-Reply-To: <56F96A31.4080309@oracle.com> References: <56F96A31.4080309@oracle.com> Message-ID: With the new -Xpatch format, are there any plans to add support for adding (or modifying) these from JVMTI in the OnLoad phase? /Michael On 28 March 2016 at 20:30, Alan Bateman wrote: > > Sorry, it is a bit confusing as we aren't quite done with the transition > from an older form of a -Xpatch to the new form. > > The syntax you see in JEP 261 and in the java -X usage output is the new > form. That works for modules defined to the platform or application class > loaders but doesn't work for modules (like java.base) that are defined to > the boot loader. Lois is working on the missing piece in hotspot, it is > tracked by JDK-8146448. All the other pieces (in javac and the runtime) are > in place. > > In the mean-time, the old form still works. The old syntax is > -Xpatch:(:*) where is a directory of exploded patches. If > you want to override CHM then you would run with -Xpatch:jsr166 where jsr166 > contains: > > java.base/java/util/concurrent/ConcurrentHashMap.class > > You can use the old syntax with the first usage of -Xpatch, not second or > subsequent usages. That is why you see a difference in the -Xpatch:junk > behavior when you specify it more than once. > > -Alan. From Alan.Bateman at oracle.com Tue Mar 29 09:39:51 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 29 Mar 2016 10:39:51 +0100 Subject: Jigsaw + Web Start In-Reply-To: <59A16BCA-975A-413D-A46C-F93F88704035@yahoo.com> References: <59A16BCA-975A-413D-A46C-F93F88704035@yahoo.com> Message-ID: <56FA4D67.2010705@oracle.com> On 29/03/2016 10:10, Robert Gibson wrote: > Hi all, > We have a number of applications launched over Web Start. Unfortunately none of them work with the latest JDK build, it looks like the closed-source Web Start implementation is not a testing priority for Oracle, so I put my shoulder to the wheel and filed a few bugs. > > Anyway, I haven't seen any mention of Web Start in the various Jigsaw documents, can I assume that there is a plan to add the "emergency hatch" VM options to the java-vm-args whitelist? Without it we are dead in the water, and I assume we are not alone! > There was a huge effort behind the scenes to get Web Start working as modules. I'm only aware of one issue so far. That issue is that transitive closure of the jdk.javaws module is limit the modules that can be read by applications launched in the same VM as the javaws launcher. A fix for this is in progress. So what issues are you running into that requires changing the java-vm-args whitelist? Are these applications using JDK-internal APIs? -Alan From Alan.Bateman at oracle.com Tue Mar 29 09:51:43 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 29 Mar 2016 10:51:43 +0100 Subject: trouble with java -Xpatch In-Reply-To: References: <56F96A31.4080309@oracle.com> Message-ID: <56FA502F.6030406@oracle.com> On 29/03/2016 10:14, Michael Rasmussen wrote: > With the new -Xpatch format, are there any plans to add support for > adding (or modifying) these from JVMTI in the OnLoad phase? > > /Michael Not specifically but you can use -Xpatch in conjunction with -agentlib/-agentpath. Also if enable the new can_generate_early_vmstart capability then you can use the ClassFileLoadHook to patch classes loaded early in the startup. In previous threads I think you mentioned this was something you were looking to do. -Alan From robbiexgibson at yahoo.com Tue Mar 29 10:03:02 2016 From: robbiexgibson at yahoo.com (Robert Gibson) Date: Tue, 29 Mar 2016 12:03:02 +0200 Subject: Jigsaw + Web Start In-Reply-To: <56FA4D67.2010705@oracle.com> References: <59A16BCA-975A-413D-A46C-F93F88704035@yahoo.com> <56FA4D67.2010705@oracle.com> Message-ID: > On 29 Mar 2016, at 11:39, Alan Bateman wrote: > >> On 29/03/2016 10:10, Robert Gibson wrote: >> Hi all, >> We have a number of applications launched over Web Start. Unfortunately none of them work with the latest JDK build, it looks like the closed-source Web Start implementation is not a testing priority for Oracle, so I put my shoulder to the wheel and filed a few bugs. >> >> Anyway, I haven't seen any mention of Web Start in the various Jigsaw documents, can I assume that there is a plan to add the "emergency hatch" VM options to the java-vm-args whitelist? Without it we are dead in the water, and I assume we are not alone! > There was a huge effort behind the scenes to get Web Start working as modules. I'm only aware of one issue so far. That issue is that transitive closure of the jdk.javaws module is limit the modules that can be read by applications launched in the same VM as the javaws launcher. A fix for this is in progress. > > So what issues are you running into that requires changing the java-vm-args whitelist? Are these applications using JDK-internal APIs? > > -Alan Hi Alan, Thanks for your quick reply. Yes, we have code (and depend on libraries) that use, approximately: com.sun.java.swing.plaf com.sun.org.apache.xerces com.sun.jmx.remote.util com.sun.management com.sun.jndi.ldap com.sun.crypto.provider We will at some point get around to re-writing the code that we have control over but would like to have flexibility over when we do this, and not have it as a precondition for upgrading our clients to Java 9. Currently it seems that -XaddExports doesn't have any effect in a JNLP file and I assumed that was a whitelisting issue with VM arguments and Web Start - but maybe it is supposed to work at this point? Regards, Robert From Alan.Bateman at oracle.com Tue Mar 29 10:15:44 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 29 Mar 2016 11:15:44 +0100 Subject: Jigsaw + Web Start In-Reply-To: References: <59A16BCA-975A-413D-A46C-F93F88704035@yahoo.com> <56FA4D67.2010705@oracle.com> Message-ID: <56FA55D0.1010503@oracle.com> On 29/03/2016 11:03, Robert Gibson wrote: > : > Hi Alan, > Thanks for your quick reply. > Yes, we have code (and depend on libraries) that use, approximately: > com.sun.java.swing.plaf Are you sure you are using classes in this package directly? The L&F is usually specified as a String. > com.sun.org.apache.xerces > com.sun.jmx.remote.util > com.sun.management com.sun.management is a supported/documented API, exported by the jdk.management module, so you should be okay here, unless you are making use of some of its internal types. > com.sun.jndi.ldap Are you making direct use of types in this package? Just curious as creating the initial context specifies the provider name as String. Also all the configuration is Strings too. > com.sun.crypto.provider I'm also curious about this one. > > We will at some point get around to re-writing the code that we have control over but would like to have flexibility over when we do this, and not have it as a precondition for upgrading our clients to Java 9. Currently it seems that -XaddExports doesn't have any effect in a JNLP file and I assumed that was a whitelisting issue with VM arguments and Web Start - but maybe it is supposed to work at this point? > -XaddExports has not been added to the options allowed to be specified with the java-vm-args attribute. It probably should be considered so as to have consistency with the command line (within reason of course, anything allowed to be specified via java-vm-args requires thinking about security). -Alan From robbiexgibson at yahoo.com Tue Mar 29 10:30:26 2016 From: robbiexgibson at yahoo.com (Robert Gibson) Date: Tue, 29 Mar 2016 12:30:26 +0200 Subject: Jigsaw + Web Start In-Reply-To: <56FA55D0.1010503@oracle.com> References: <59A16BCA-975A-413D-A46C-F93F88704035@yahoo.com> <56FA4D67.2010705@oracle.com> <56FA55D0.1010503@oracle.com> Message-ID: <956263C2-5958-4E15-8D07-5F9D92A1D259@yahoo.com> > On 29 Mar 2016, at 12:15, Alan Bateman wrote: > >> On 29/03/2016 11:03, Robert Gibson wrote: >> : >> Hi Alan, >> Thanks for your quick reply. >> Yes, we have code (and depend on libraries) that use, approximately: >> com.sun.java.swing.plaf > Are you sure you are using classes in this package directly? The L&F is usually specified as a String. Our historical preference for compile-time type errors gives rise to code like if (UIManager.getLookAndFeel() instanceof WindowsLookAndFeel) [Various other packages snipped] > >> >> We will at some point get around to re-writing the code that we have control over but would like to have flexibility over when we do this, and not have it as a precondition for upgrading our clients to Java 9. Currently it seems that -XaddExports doesn't have any effect in a JNLP file and I assumed that was a whitelisting issue with VM arguments and Web Start - but maybe it is supposed to work at this point? > -XaddExports has not been added to the options allowed to be specified with the java-vm-args attribute. It probably should be considered so as to have consistency with the command line (within reason of course, anything allowed to be specified via java-vm-args requires thinking about security). > > -Alan Like I said, we will get around to rewriting what absolutely needs to be tweaked where we can, but being able to use the escape hatch like a command-line app (along with fixes for 8152838 and 8152839) will allow us to continue our testing. Thanks, Robert From alan.bateman at oracle.com Tue Mar 29 12:19:41 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 29 Mar 2016 12:19:41 +0000 Subject: hg: jigsaw/jake/langtools: Drop support for old style -XaddExports and -XaddReads Message-ID: <201603291219.u2TCJfLi023049@aojmv0008.oracle.com> Changeset: 496a2a78b2a4 Author: alanb Date: 2016-03-29 13:19 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/496a2a78b2a4 Drop support for old style -XaddExports and -XaddReads ! test/tools/javac/modules/AddLimitMods.java ! test/tools/javac/platform/PlatformProviderTest.java From alan.bateman at oracle.com Tue Mar 29 12:21:24 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 29 Mar 2016 12:21:24 +0000 Subject: hg: jigsaw/jake/jdk: Drop support for old style -XaddExports and -XaddReads Message-ID: <201603291221.u2TCLPVx024841@aojmv0008.oracle.com> Changeset: a7a44ba9e6d8 Author: alanb Date: 2016-03-29 13:21 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a7a44ba9e6d8 Drop support for old style -XaddExports and -XaddReads ! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java ! test/java/awt/Toolkit/Headless/WrappedToolkitTest/WrappedToolkitTest.sh ! test/tools/launcher/modules/patch/PatchTest.java From scolebourne at joda.org Tue Mar 29 13:24:15 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 29 Mar 2016 14:24:15 +0100 Subject: modulepath and classpath mixture In-Reply-To: <1228911717.349701.1459160027285.JavaMail.zimbra@u-pem.fr> References: <56CC57A1.2050109@oracle.com> <56F2440A.7010505@oracle.com> <56F2914C.3030706@oracle.com> <56F2B3DA.402@oracle.com> <1228911717.349701.1459160027285.JavaMail.zimbra@u-pem.fr> Message-ID: On 28 March 2016 at 11:13, Remi Forax wrote: > Hi Stephen, Hi all, > I think that delivering tests as a separated module is a bad idea. > > I see that from the point of a developer, seeing the code and the test as different modules can be attractive because everything seems to be put at the right place but there is a big drawback. Because modules are reified at runtime, it means that the runtime environment of the tests will be different from the production environment. This last sentence doesn't make sense to me - tests are not run in a production environment. Tests have all the qualities of modules - code, dependencies, compilation phase, deployment. The only special part is the need for special "friend-like" access, which Jigsaw already has for other cases (the export...to clause). Put simply, I consider that module = deployment-artifact-with-dependencies. With that mental model, putting tests inside the module is just not acceptable, because tests should not be deployed with the main application and they have different dependencies. If we disagree that module = deployment-artifact-with-dependencies, then perhaps we have bigger problems to solve here. Stephen (And to Paul Benedict, the classpath is going to die over time, so any solution that uses that is flawed IMO). > So as Alan said, from the jigsaw point of view at runtime, the tests and the code should be in the same module. > > So the building tools have to come with a way to support to have 2 different module-info.java in two different folders and package them as one module, > maybe javac should help by providing a way to merge 2 module-info at compile time. > > R?mi > > ----- Mail original ----- >> De: "Alan Bateman" >> ?: "Stephen Colebourne" , "jigsaw-dev" >> Envoy?: Mercredi 23 Mars 2016 16:18:50 >> Objet: Re: modulepath and classpath mixture >> >> >> On 23/03/2016 14:42, Stephen Colebourne wrote: >> > : >> > >> > I don't particularly care what the mechanism is for this, but at the >> > requirements level: >> > - there are two modules - main and test >> > - each has its own source tree >> > - each has its own dependencies >> > - each is released separately >> > - each could be hosted on a central repo >> > - the test module needs to be able to contain the same packages as the >> > main module >> > - the test module needs to be able to invoke package-scoped code in >> > the same package in the main module >> > >> > To clarify further consider 4 modules, A, B, A-test and B-test where B >> > depends on A. Module A-test may have a method foo() that uses package >> > scope to access something in A. Module B-test will depend on A-test >> > and rely on foo() to get access to that internal object. >> To your list, I would add the ability to make use of testing frameworks >> like TestNG and JUnit. >> >> In any case, and as things currently stand, you've got most of the >> above. One differences is that the tests are not a separate module, they >> are instead compiled and run in a way that patches the main module. The >> second difference is that they don't have their own module declaration, >> instead the compilation or run augments the dependences with any >> additional dependences that the tests have. As I said, if they tools >> makes it easy then I don't think it's too bad. >> >> > >> > (Note that I view the thread discussion of >> > references to test classes on the classpath as another hack. >> > >> Packages can't be split between modules and classpath so there is no >> support for that. >> >> -Alan >> From andrej.golovnin at gmail.com Tue Mar 29 13:26:36 2016 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Tue, 29 Mar 2016 15:26:36 +0200 Subject: Jigsaw + Web Start In-Reply-To: <56FA55D0.1010503@oracle.com> References: <59A16BCA-975A-413D-A46C-F93F88704035@yahoo.com> <56FA4D67.2010705@oracle.com> <56FA55D0.1010503@oracle.com> Message-ID: Hi Alan, >> Hi Alan, >> Thanks for your quick reply. >> Yes, we have code (and depend on libraries) that use, approximately: >> com.sun.java.swing.plaf > Are you sure you are using classes in this package directly? The L&F is usually specified as a String. We have also a product wich use Java WebStart and we use classes from com.sun.java.swing.plaf. We use in our product JGoodies Looks. And JGoodies Windows L&F extends some classes from this package. Here is one example: http://grepcode.com/file/repo1.maven.org/maven2/com.jgoodies/jgoodies-looks/2.5.3/com/jgoodies/looks/windows/WindowsLookAndFeel.java?av=f#71 Best regards, Andrej Golovnin From sundararajan.athijegannathan at oracle.com Tue Mar 29 15:38:04 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 29 Mar 2016 21:08:04 +0530 Subject: Please review 8148491: Revisit jlink --genbom Message-ID: <56FAA15C.2010305@oracle.com> Hi, Please review http://cr.openjdk.java.net/~sundar/8148491/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8148491 Thanks, -Sundar From forax at univ-mlv.fr Tue Mar 29 15:41:38 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 29 Mar 2016 17:41:38 +0200 (CEST) Subject: modulepath and classpath mixture In-Reply-To: References: <56F2440A.7010505@oracle.com> <56F2914C.3030706@oracle.com> <56F2B3DA.402@oracle.com> <1228911717.349701.1459160027285.JavaMail.zimbra@u-pem.fr> Message-ID: <1988402913.1434736.1459266098559.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Stephen Colebourne" > ?: "jigsaw-dev" > Envoy?: Mardi 29 Mars 2016 15:24:15 > Objet: Re: modulepath and classpath mixture > > On 28 March 2016 at 11:13, Remi Forax wrote: > > Hi Stephen, Hi all, > > I think that delivering tests as a separated module is a bad idea. > > > > I see that from the point of a developer, seeing the code and the test as > > different modules can be attractive because everything seems to be put at > > the right place but there is a big drawback. Because modules are reified > > at runtime, it means that the runtime environment of the tests will be > > different from the production environment. > > This last sentence doesn't make sense to me - tests are not run in a > production environment. yes, you just want your tests to run in a runtime which is as close as possible to the runtime of the production environment. It's like when a test fails because JUnit calls the test concurrently when in production the code always run under a giant lock. > > Tests have all the qualities of modules - code, dependencies, > compilation phase, deployment. The only special part is the need for > special "friend-like" access, which Jigsaw already has for other cases > (the export...to clause). You also need to support split packages or a kind of export...to that allows to export package private method as public. These are two major deviations from the jigsaw canon. Instead of considering tests as a separated module, i prefer to consider them as a separated version (1.0 vs 1.0-test), the test version includes the code, the tests, and have several more dependencies on JUnit like modules. > > Put simply, I consider that module = > deployment-artifact-with-dependencies. With that mental model, putting > tests inside the module is just not acceptable, because tests should > not be deployed with the main application and they have different > dependencies. If we disagree that module = > deployment-artifact-with-dependencies, then perhaps we have bigger > problems to solve here. We agree that a module = deployment-artifact-with-dependencies, but we disagree because for me the test should be a module with the same name but a different version (by example with a test suffix) while you think it should be a different module. > > Stephen > (And to Paul Benedict, the classpath is going to die over time, so any > solution that uses that is flawed IMO). I don't think the classpath will die but if you want to use things like jlink, it will not work if you have jars in the a classpath. R?mi > > > > So as Alan said, from the jigsaw point of view at runtime, the tests and > > the code should be in the same module. > > > > So the building tools have to come with a way to support to have 2 > > different module-info.java in two different folders and package them as > > one module, > > maybe javac should help by providing a way to merge 2 module-info at > > compile time. > > > > R?mi > > > > ----- Mail original ----- > >> De: "Alan Bateman" > >> ?: "Stephen Colebourne" , "jigsaw-dev" > >> > >> Envoy?: Mercredi 23 Mars 2016 16:18:50 > >> Objet: Re: modulepath and classpath mixture > >> > >> > >> On 23/03/2016 14:42, Stephen Colebourne wrote: > >> > : > >> > > >> > I don't particularly care what the mechanism is for this, but at the > >> > requirements level: > >> > - there are two modules - main and test > >> > - each has its own source tree > >> > - each has its own dependencies > >> > - each is released separately > >> > - each could be hosted on a central repo > >> > - the test module needs to be able to contain the same packages as the > >> > main module > >> > - the test module needs to be able to invoke package-scoped code in > >> > the same package in the main module > >> > > >> > To clarify further consider 4 modules, A, B, A-test and B-test where B > >> > depends on A. Module A-test may have a method foo() that uses package > >> > scope to access something in A. Module B-test will depend on A-test > >> > and rely on foo() to get access to that internal object. > >> To your list, I would add the ability to make use of testing frameworks > >> like TestNG and JUnit. > >> > >> In any case, and as things currently stand, you've got most of the > >> above. One differences is that the tests are not a separate module, they > >> are instead compiled and run in a way that patches the main module. The > >> second difference is that they don't have their own module declaration, > >> instead the compilation or run augments the dependences with any > >> additional dependences that the tests have. As I said, if they tools > >> makes it easy then I don't think it's too bad. > >> > >> > > >> > (Note that I view the thread discussion of > >> > references to test classes on the classpath as another hack. > >> > > >> Packages can't be split between modules and classpath so there is no > >> support for that. > >> > >> -Alan > >> > From pbenedict at apache.org Tue Mar 29 15:55:10 2016 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 29 Mar 2016 10:55:10 -0500 Subject: modulepath and classpath mixture In-Reply-To: <1988402913.1434736.1459266098559.JavaMail.zimbra@u-pem.fr> References: <56F2440A.7010505@oracle.com> <56F2914C.3030706@oracle.com> <56F2B3DA.402@oracle.com> <1228911717.349701.1459160027285.JavaMail.zimbra@u-pem.fr> <1988402913.1434736.1459266098559.JavaMail.zimbra@u-pem.fr> Message-ID: Remi, it's really untenable to give tests a different version. Tests are currently built under the same version as the main project under one master parent project. Split packages are still going to be a necessary because that's the world of thousands of existing projects. So that might be against jigsaw canon but hopefully a compromise can be found. Cheers, Paul On Tue, Mar 29, 2016 at 10:41 AM, Remi Forax wrote: > > > ----- Mail original ----- > > De: "Stephen Colebourne" > > ?: "jigsaw-dev" > > Envoy?: Mardi 29 Mars 2016 15:24:15 > > Objet: Re: modulepath and classpath mixture > > > > On 28 March 2016 at 11:13, Remi Forax wrote: > > > Hi Stephen, Hi all, > > > I think that delivering tests as a separated module is a bad idea. > > > > > > I see that from the point of a developer, seeing the code and the test > as > > > different modules can be attractive because everything seems to be put > at > > > the right place but there is a big drawback. Because modules are > reified > > > at runtime, it means that the runtime environment of the tests will be > > > different from the production environment. > > > > This last sentence doesn't make sense to me - tests are not run in a > > production environment. > > yes, you just want your tests to run in a runtime which is as close as > possible to the runtime of the production environment. > It's like when a test fails because JUnit calls the test concurrently when > in production the code always run under a giant lock. > > > > > Tests have all the qualities of modules - code, dependencies, > > compilation phase, deployment. The only special part is the need for > > special "friend-like" access, which Jigsaw already has for other cases > > (the export...to clause). > > You also need to support split packages or a kind of export...to that > allows to export package private method as public. > These are two major deviations from the jigsaw canon. > > Instead of considering tests as a separated module, i prefer to consider > them as a separated version (1.0 vs 1.0-test), > the test version includes the code, the tests, and have several more > dependencies on JUnit like modules. > > > > > Put simply, I consider that module = > > deployment-artifact-with-dependencies. With that mental model, putting > > tests inside the module is just not acceptable, because tests should > > not be deployed with the main application and they have different > > dependencies. If we disagree that module = > > deployment-artifact-with-dependencies, then perhaps we have bigger > > problems to solve here. > > We agree that a module = deployment-artifact-with-dependencies, but we > disagree because for me the test should be a module with the same name but > a different version (by example with a test suffix) while you think it > should be a different module. > > > > > Stephen > > (And to Paul Benedict, the classpath is going to die over time, so any > > solution that uses that is flawed IMO). > > I don't think the classpath will die but if you want to use things like > jlink, it will not work if you have jars in the a classpath. > > R?mi > > > > > > > > So as Alan said, from the jigsaw point of view at runtime, the tests > and > > > the code should be in the same module. > > > > > > So the building tools have to come with a way to support to have 2 > > > different module-info.java in two different folders and package them as > > > one module, > > > maybe javac should help by providing a way to merge 2 module-info at > > > compile time. > > > > > > R?mi > > > > > > ----- Mail original ----- > > >> De: "Alan Bateman" > > >> ?: "Stephen Colebourne" , "jigsaw-dev" > > >> > > >> Envoy?: Mercredi 23 Mars 2016 16:18:50 > > >> Objet: Re: modulepath and classpath mixture > > >> > > >> > > >> On 23/03/2016 14:42, Stephen Colebourne wrote: > > >> > : > > >> > > > >> > I don't particularly care what the mechanism is for this, but at the > > >> > requirements level: > > >> > - there are two modules - main and test > > >> > - each has its own source tree > > >> > - each has its own dependencies > > >> > - each is released separately > > >> > - each could be hosted on a central repo > > >> > - the test module needs to be able to contain the same packages as > the > > >> > main module > > >> > - the test module needs to be able to invoke package-scoped code in > > >> > the same package in the main module > > >> > > > >> > To clarify further consider 4 modules, A, B, A-test and B-test > where B > > >> > depends on A. Module A-test may have a method foo() that uses > package > > >> > scope to access something in A. Module B-test will depend on A-test > > >> > and rely on foo() to get access to that internal object. > > >> To your list, I would add the ability to make use of testing > frameworks > > >> like TestNG and JUnit. > > >> > > >> In any case, and as things currently stand, you've got most of the > > >> above. One differences is that the tests are not a separate module, > they > > >> are instead compiled and run in a way that patches the main module. > The > > >> second difference is that they don't have their own module > declaration, > > >> instead the compilation or run augments the dependences with any > > >> additional dependences that the tests have. As I said, if they tools > > >> makes it easy then I don't think it's too bad. > > >> > > >> > > > >> > (Note that I view the thread discussion of > > >> > references to test classes on the classpath as another hack. > > >> > > > >> Packages can't be split between modules and classpath so there is no > > >> support for that. > > >> > > >> -Alan > > >> > > > From james.laskey at oracle.com Tue Mar 29 15:56:10 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 29 Mar 2016 12:56:10 -0300 Subject: Please review 8148491: Revisit jlink --genbom In-Reply-To: <56FAA15C.2010305@oracle.com> References: <56FAA15C.2010305@oracle.com> Message-ID: +1 > On Mar 29, 2016, at 12:38 PM, Sundararajan Athijegannathan wrote: > > Hi, > > Please review http://cr.openjdk.java.net/~sundar/8148491/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8148491 > > Thanks, > -Sundar From forax at univ-mlv.fr Tue Mar 29 16:10:38 2016 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Tue, 29 Mar 2016 18:10:38 +0200 (CEST) Subject: modulepath and classpath mixture In-Reply-To: References: <56F2914C.3030706@oracle.com> <56F2B3DA.402@oracle.com> <1228911717.349701.1459160027285.JavaMail.zimbra@u-pem.fr> <1988402913.1434736.1459266098559.JavaMail.zimbra@u-pem.fr> Message-ID: <861072180.1451770.1459267838583.JavaMail.zimbra@u-pem.fr> Paul, you can give a different version to your module but you don't have to. Test can use the very same module name along with the same version. R?mi ----- Mail original ----- > De: "Paul Benedict" > ?: "Remi Forax" > Cc: "Stephen Colebourne" , "jigsaw-dev" > > Envoy?: Mardi 29 Mars 2016 17:55:10 > Objet: Re: modulepath and classpath mixture > Remi, it's really untenable to give tests a different version. Tests are > currently built under the same version as the main project under one master > parent project. Split packages are still going to be a necessary because > that's the world of thousands of existing projects. So that might be against > jigsaw canon but hopefully a compromise can be found. > Cheers, > Paul > On Tue, Mar 29, 2016 at 10:41 AM, Remi Forax < forax at univ-mlv.fr > wrote: > > ----- Mail original ----- > > > > De: "Stephen Colebourne" < scolebourne at joda.org > > > > > ?: "jigsaw-dev" < jigsaw-dev at openjdk.java.net > > > > > Envoy?: Mardi 29 Mars 2016 15:24:15 > > > > Objet: Re: modulepath and classpath mixture > > > > > > > > On 28 March 2016 at 11:13, Remi Forax < forax at univ-mlv.fr > wrote: > > > > > Hi Stephen, Hi all, > > > > > I think that delivering tests as a separated module is a bad idea. > > > > > > > > > > I see that from the point of a developer, seeing the code and the test > > > > as > > > > > different modules can be attractive because everything seems to be put > > > > at > > > > > the right place but there is a big drawback. Because modules are > > > > reified > > > > > at runtime, it means that the runtime environment of the tests will be > > > > > different from the production environment. > > > > > > > > This last sentence doesn't make sense to me - tests are not run in a > > > > production environment. > > > yes, you just want your tests to run in a runtime which is as close as > > possible to the runtime of the production environment. > > > It's like when a test fails because JUnit calls the test concurrently when > > in > > production the code always run under a giant lock. > > > > > > > > Tests have all the qualities of modules - code, dependencies, > > > > compilation phase, deployment. The only special part is the need for > > > > special "friend-like" access, which Jigsaw already has for other cases > > > > (the export...to clause). > > > You also need to support split packages or a kind of export...to that > > allows > > to export package private method as public. > > > These are two major deviations from the jigsaw canon. > > > Instead of considering tests as a separated module, i prefer to consider > > them > > as a separated version (1.0 vs 1.0-test), > > > the test version includes the code, the tests, and have several more > > dependencies on JUnit like modules. > > > > > > > > Put simply, I consider that module = > > > > deployment-artifact-with-dependencies. With that mental model, putting > > > > tests inside the module is just not acceptable, because tests should > > > > not be deployed with the main application and they have different > > > > dependencies. If we disagree that module = > > > > deployment-artifact-with-dependencies, then perhaps we have bigger > > > > problems to solve here. > > > We agree that a module = deployment-artifact-with-dependencies, but we > > disagree because for me the test should be a module with the same name but > > a > > different version (by example with a test suffix) while you think it should > > be a different module. > > > > > > > > Stephen > > > > (And to Paul Benedict, the classpath is going to die over time, so any > > > > solution that uses that is flawed IMO). > > > I don't think the classpath will die but if you want to use things like > > jlink, it will not work if you have jars in the a classpath. > > > R?mi > > > > > > > > > > > > > So as Alan said, from the jigsaw point of view at runtime, the tests > > > > and > > > > > the code should be in the same module. > > > > > > > > > > So the building tools have to come with a way to support to have 2 > > > > > different module-info.java in two different folders and package them as > > > > > one module, > > > > > maybe javac should help by providing a way to merge 2 module-info at > > > > > compile time. > > > > > > > > > > R?mi > > > > > > > > > > ----- Mail original ----- > > > > >> De: "Alan Bateman" < Alan.Bateman at oracle.com > > > > > >> ?: "Stephen Colebourne" < scolebourne at joda.org >, "jigsaw-dev" > > > > >> < jigsaw-dev at openjdk.java.net > > > > > >> Envoy?: Mercredi 23 Mars 2016 16:18:50 > > > > >> Objet: Re: modulepath and classpath mixture > > > > >> > > > > >> > > > > >> On 23/03/2016 14:42, Stephen Colebourne wrote: > > > > >> > : > > > > >> > > > > > >> > I don't particularly care what the mechanism is for this, but at the > > > > >> > requirements level: > > > > >> > - there are two modules - main and test > > > > >> > - each has its own source tree > > > > >> > - each has its own dependencies > > > > >> > - each is released separately > > > > >> > - each could be hosted on a central repo > > > > >> > - the test module needs to be able to contain the same packages as > > > >> > the > > > > >> > main module > > > > >> > - the test module needs to be able to invoke package-scoped code in > > > > >> > the same package in the main module > > > > >> > > > > > >> > To clarify further consider 4 modules, A, B, A-test and B-test where > > > >> > B > > > > >> > depends on A. Module A-test may have a method foo() that uses > > > >> > package > > > > >> > scope to access something in A. Module B-test will depend on A-test > > > > >> > and rely on foo() to get access to that internal object. > > > > >> To your list, I would add the ability to make use of testing > > > >> frameworks > > > > >> like TestNG and JUnit. > > > > >> > > > > >> In any case, and as things currently stand, you've got most of the > > > > >> above. One differences is that the tests are not a separate module, > > > >> they > > > > >> are instead compiled and run in a way that patches the main module. > > > >> The > > > > >> second difference is that they don't have their own module > > > >> declaration, > > > > >> instead the compilation or run augments the dependences with any > > > > >> additional dependences that the tests have. As I said, if they tools > > > > >> makes it easy then I don't think it's too bad. > > > > >> > > > > >> > > > > > >> > (Note that I view the thread discussion of > > > > >> > references to test classes on the classpath as another hack. > > > > >> > > > > > >> Packages can't be split between modules and classpath so there is no > > > > >> support for that. > > > > >> > > > > >> -Alan > > > > >> > > > > > From stephen.felts at oracle.com Tue Mar 29 16:33:22 2016 From: stephen.felts at oracle.com (Stephen Felts) Date: Tue, 29 Mar 2016 09:33:22 -0700 (PDT) Subject: argsfile problem In-Reply-To: References: <56CC57A1.2050109@oracle.com> <56F2440A.7010505@oracle.com> <56F2914C.3030706@oracle.com> <56F2B3DA.402@oracle.com> <1228911717.349701.1459160027285.JavaMail.zimbra@u-pem.fr> <0ccbd90a-9585-4a27-9955-5e0f7c2afc74@default> Message-ID: <816680c3-0fa9-4554-91ac-c27858af880a@default> Here?s an interesting problem. ? I have a lot of JDK9-specific command line options. I decided to try to put them into an argsfile. I then tried to use the @argsfile in a gradle script using something like ? options.compilerArgs=?@/argsfile? ? I was getting a ?javac: invalid flag: @/argsfile? and couldn?t figure out why. The answer is that gradle is using an argsfile so I ended up with an argsfile within an argsfile. ? ? ? ? From russell.gold at oracle.com Tue Mar 29 16:33:55 2016 From: russell.gold at oracle.com (Russell Gold) Date: Tue, 29 Mar 2016 12:33:55 -0400 Subject: modulepath and classpath mixture In-Reply-To: References: <56CC57A1.2050109@oracle.com> <56F2440A.7010505@oracle.com> <56F2914C.3030706@oracle.com> <56F2B3DA.402@oracle.com> <1228911717.349701.1459160027285.JavaMail.zimbra@u-pem.fr> Message-ID: <0CC4E4A6-4152-4BB0-BB42-B9E284540BB6@oracle.com> Hi Stephen, Why do you need any kind of friend access? It seems to me that this is making things harder than they need to be. The tests can simply run with the production code on the class path, and then there are no module issues at all. I think a larger problem is that you can do what I just said with the jars, even a jar which has been designated as a module by virtue of having a module-info.class in it. That means that, when users are up taking jars, they are not prevented from accessing module internals. They can put the jars on the module path, of course, but they can still use them on the class path! - Russ > > On 28 March 2016 at 11:13, Remi Forax wrote: >> Hi Stephen, Hi all, >> I think that delivering tests as a separated module is a bad idea. >> >> I see that from the point of a developer, seeing the code and the test as different modules can be attractive because everything seems to be put at the right place but there is a big drawback. Because modules are reified at runtime, it means that the runtime environment of the tests will be different from the production environment. > > This last sentence doesn't make sense to me - tests are not run in a > production environment. > > Tests have all the qualities of modules - code, dependencies, > compilation phase, deployment. The only special part is the need for > special "friend-like" access, which Jigsaw already has for other cases > (the export...to clause). > > Put simply, I consider that module = > deployment-artifact-with-dependencies. With that mental model, putting > tests inside the module is just not acceptable, because tests should > not be deployed with the main application and they have different > dependencies. If we disagree that module = > deployment-artifact-with-dependencies, then perhaps we have bigger > problems to solve here. > > Stephen > (And to Paul Benedict, the classpath is going to die over time, so any > solution that uses that is flawed IMO). > > >> So as Alan said, from the jigsaw point of view at runtime, the tests and the code should be in the same module. >> >> So the building tools have to come with a way to support to have 2 different module-info.java in two different folders and package them as one module, >> maybe javac should help by providing a way to merge 2 module-info at compile time. >> >> R?mi >> >> ----- Mail original ----- >>> De: "Alan Bateman" >>> ?: "Stephen Colebourne" , "jigsaw-dev" >>> Envoy?: Mercredi 23 Mars 2016 16:18:50 >>> Objet: Re: modulepath and classpath mixture >>> >>> >>> On 23/03/2016 14:42, Stephen Colebourne wrote: >>>> : >>>> >>>> I don't particularly care what the mechanism is for this, but at the >>>> requirements level: >>>> - there are two modules - main and test >>>> - each has its own source tree >>>> - each has its own dependencies >>>> - each is released separately >>>> - each could be hosted on a central repo >>>> - the test module needs to be able to contain the same packages as the >>>> main module >>>> - the test module needs to be able to invoke package-scoped code in >>>> the same package in the main module >>>> >>>> To clarify further consider 4 modules, A, B, A-test and B-test where B >>>> depends on A. Module A-test may have a method foo() that uses package >>>> scope to access something in A. Module B-test will depend on A-test >>>> and rely on foo() to get access to that internal object. >>> To your list, I would add the ability to make use of testing frameworks >>> like TestNG and JUnit. >>> >>> In any case, and as things currently stand, you've got most of the >>> above. One differences is that the tests are not a separate module, they >>> are instead compiled and run in a way that patches the main module. The >>> second difference is that they don't have their own module declaration, >>> instead the compilation or run augments the dependences with any >>> additional dependences that the tests have. As I said, if they tools >>> makes it easy then I don't think it's too bad. >>> >>>> >>>> (Note that I view the thread discussion of >>>> references to test classes on the classpath as another hack. >>>> >>> Packages can't be split between modules and classpath so there is no >>> support for that. >>> >>> -Alan >>> From stephen.felts at oracle.com Tue Mar 29 16:37:16 2016 From: stephen.felts at oracle.com (Stephen Felts) Date: Tue, 29 Mar 2016 09:37:16 -0700 (PDT) Subject: argsfile problem In-Reply-To: <816680c3-0fa9-4554-91ac-c27858af880a@default> References: <56CC57A1.2050109@oracle.com> <56F2440A.7010505@oracle.com> <56F2914C.3030706@oracle.com> <56F2B3DA.402@oracle.com> <1228911717.349701.1459160027285.JavaMail.zimbra@u-pem.fr> <0ccbd90a-9585-4a27-9955-5e0f7c2afc74@default> <816680c3-0fa9-4554-91ac-c27858af880a@default> Message-ID: For you gradle experts, the syntax below is obviously wrong. options.compilerArgs << '@/argsfile' Maybe we can get the gradle folks to recognize @filename and expand it into their argsfile? -----Original Message----- From: Stephen Felts Sent: Tuesday, March 29, 2016 12:33 PM To: jigsaw-dev Subject: argsfile problem Here?s an interesting problem. ? I have a lot of JDK9-specific command line options. I decided to try to put them into an argsfile. I then tried to use the @argsfile in a gradle script using something like ? options.compilerArgs=?@/argsfile? ? I was getting a ?javac: invalid flag: @/argsfile? and couldn?t figure out why. The answer is that gradle is using an argsfile so I ended up with an argsfile within an argsfile. ? ? ? ? From Alan.Bateman at oracle.com Tue Mar 29 18:51:54 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 29 Mar 2016 19:51:54 +0100 Subject: Please review 8148491: Revisit jlink --genbom In-Reply-To: <56FAA15C.2010305@oracle.com> References: <56FAA15C.2010305@oracle.com> Message-ID: <56FACECA.5060602@oracle.com> On 29/03/2016 16:38, Sundararajan Athijegannathan wrote: > Hi, > > Please review http://cr.openjdk.java.net/~sundar/8148491/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8148491 > This looks to me. A minor nit in TaskHelper.getPluginsConfig where removing genbom leaves a ) in mid air. -Alan From naoto.sato at oracle.com Tue Mar 29 21:25:44 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 29 Mar 2016 14:25:44 -0700 Subject: RFR: 8152704: jlink command line output/help message improvement Message-ID: <56FAF2D8.4020906@oracle.com> Hello, Please review the changes for the following issue: https://bugs.openjdk.java.net/browse/JDK-8152704 The suggested change is located at: http://cr.openjdk.java.net/~naoto/8152704/webrev.01/ Naoto From claes.redestad at oracle.com Tue Mar 29 23:03:47 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 30 Mar 2016 01:03:47 +0200 Subject: RFR: 8152641: Plugin to generate BMH$Species classes ahead-of-time In-Reply-To: <56F676CA.5000803@gmail.com> References: <56F3EEAB.4090600@oracle.com> <1FE3F7A6-1C7B-4DC6-875C-E3FAEDED08F5@oracle.com> <56F50EC5.6020500@gmail.com> <56F5520D.3080205@oracle.com> <56F676CA.5000803@gmail.com> Message-ID: <56FB09D3.4090000@oracle.com> Hi Peter, Mandy, On 2016-03-26 12:47, Peter Levart wrote: > > Comparing this with proposed code from webrev: > > 493 try { > 494 return (Class BoundMethodHandle>) > 495 Class.forName("java.lang.invoke.BoundMethodHandle$Species_" + > LambdaForm.shortenSignature(types)); > 496 } catch (ClassNotFoundException cnf) { > 497 // Not pregenerated, generate the class > 498 return generateConcreteBMHClass(types); > 499 } > > > ...note that the function passed to CLASS_CACHE.computeIfAbsent is > executed just once per distinct 'types' argument. Even if you put the > generated switch between a call to getConcreteBMHClass and > CLASS_CACHE.computeIfAbsent, getConcreteBMHClass(String types) is > executed just once per distinct 'types' argument (except in rare > occasions when VM can not initialize the loaded class). > > In this respect a successful Class.forName() is not any worse than > static resolving. It's just that unsuccessful Class.forName() > represents some overhead for classes that are not pre-generated. So an > alternative way to get rid of that overhead is to have a HashSet of > 'types' strings for pre-generated classes at hand in order to decide > whether to call Class.forName or generateConcreteBMHClass. > > What's easier to support is another question. > > Regards, Peter to have something to compare with I built a version which, like you suggest, generates a HashSet with the set of generated classes here: http://cr.openjdk.java.net/~redestad/8152641/webrev.02/ This adds a fair bit of complexity to the plugin and requires we add a nested class in BoundMethodHandle that we can replace. Using the anonymous compute Function for this seems like the best choice for this. I've not been able to measure any statistical difference in real startup terms, though, and not figured out a smart way to benchmark the overhead of the CNFE in relation to the class generation (my guess it adds a fraction to the total cost) and since this adds ever so little footprint and an extra lookup to the fast path it would seem that this is the wrong trade-off to do here. All-in-all I lean towards moving forward with the first, simpler revision of this patch[1] and then evaluate if webrev.02 or a String-switch+static resolve as a follow-up. A compromise would be to keep the SpeciesLookup class introduced here to allow removing all overhead in case the plugin is disabled. Mandy: I've not found any test (under jdk/test/tools/jlink or elsewhere) which has to be updated when adding a plugin like this. Thanks! /Claes [1] http://cr.openjdk.java.net/~redestad/8152641/webrev.01/ From mandy.chung at oracle.com Tue Mar 29 23:40:42 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 29 Mar 2016 16:40:42 -0700 Subject: RFR: 8152704: jlink command line output/help message improvement In-Reply-To: <56FAF2D8.4020906@oracle.com> References: <56FAF2D8.4020906@oracle.com> Message-ID: <8D333EAA-4EB2-469A-9388-50CEF3E0231C@oracle.com> > On Mar 29, 2016, at 2:25 PM, Naoto Sato wrote: > > Hello, > > Please review the changes for the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8152704 > > The suggested change is located at: > > http://cr.openjdk.java.net/~naoto/8152704/webrev.01/ Looks okay. Does this show the usage message? JlinkTask::run catches PluginException and print ?main.usage.summary?. It?d be more appropriate to show the plugin usage message instead that should be addressed by JDK-8152800. Mandy From naoto.sato at oracle.com Tue Mar 29 23:46:02 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 29 Mar 2016 16:46:02 -0700 Subject: RFR: 8152704: jlink command line output/help message improvement In-Reply-To: <8D333EAA-4EB2-469A-9388-50CEF3E0231C@oracle.com> References: <56FAF2D8.4020906@oracle.com> <8D333EAA-4EB2-469A-9388-50CEF3E0231C@oracle.com> Message-ID: <56FB13BA.4060107@oracle.com> Thanks. Yes, the usage message is always displayed on PluginException as before. Naoto On 3/29/16 4:40 PM, Mandy Chung wrote: > >> On Mar 29, 2016, at 2:25 PM, Naoto Sato wrote: >> >> Hello, >> >> Please review the changes for the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8152704 >> >> The suggested change is located at: >> >> http://cr.openjdk.java.net/~naoto/8152704/webrev.01/ > > Looks okay. Does this show the usage message? JlinkTask::run catches PluginException and print ?main.usage.summary?. It?d be more appropriate to show the plugin usage message instead that should be addressed by JDK-8152800. > > Mandy > From pbenedict at apache.org Wed Mar 30 02:47:11 2016 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 29 Mar 2016 21:47:11 -0500 Subject: modulepath and classpath mixture In-Reply-To: <0CC4E4A6-4152-4BB0-BB42-B9E284540BB6@oracle.com> References: <56CC57A1.2050109@oracle.com> <56F2440A.7010505@oracle.com> <56F2914C.3030706@oracle.com> <56F2B3DA.402@oracle.com> <1228911717.349701.1459160027285.JavaMail.zimbra@u-pem.fr> <0CC4E4A6-4152-4BB0-BB42-B9E284540BB6@oracle.com> Message-ID: Russell, when you drop a jar on the classpath, module code will not be able to access it in a split package situation. That's the big barrier here. Maven test projects are typically written with the same package shared with the "main" code. Cheers, Paul On Tue, Mar 29, 2016 at 11:33 AM, Russell Gold wrote: > Hi Stephen, > > Why do you need any kind of friend access? > > It seems to me that this is making things harder than they need to be. The > tests can simply run with the production code on the class path, and then > there are no module issues at all. > > I think a larger problem is that you can do what I just said with the > jars, even a jar which has been designated as a module by virtue of having > a module-info.class in it. That means that, when users are up taking jars, > they are not prevented from accessing module internals. They can put the > jars on the module path, of course, but they can still use them on the > class path! > > - Russ > > > > > On 28 March 2016 at 11:13, Remi Forax wrote: > >> Hi Stephen, Hi all, > >> I think that delivering tests as a separated module is a bad idea. > >> > >> I see that from the point of a developer, seeing the code and the test > as different modules can be attractive because everything seems to be put > at the right place but there is a big drawback. Because modules are reified > at runtime, it means that the runtime environment of the tests will be > different from the production environment. > > > > This last sentence doesn't make sense to me - tests are not run in a > > production environment. > > > > Tests have all the qualities of modules - code, dependencies, > > compilation phase, deployment. The only special part is the need for > > special "friend-like" access, which Jigsaw already has for other cases > > (the export...to clause). > > > > Put simply, I consider that module = > > deployment-artifact-with-dependencies. With that mental model, putting > > tests inside the module is just not acceptable, because tests should > > not be deployed with the main application and they have different > > dependencies. If we disagree that module = > > deployment-artifact-with-dependencies, then perhaps we have bigger > > problems to solve here. > > > > Stephen > > (And to Paul Benedict, the classpath is going to die over time, so any > > solution that uses that is flawed IMO). > > > > > >> So as Alan said, from the jigsaw point of view at runtime, the tests > and the code should be in the same module. > >> > >> So the building tools have to come with a way to support to have 2 > different module-info.java in two different folders and package them as one > module, > >> maybe javac should help by providing a way to merge 2 module-info at > compile time. > >> > >> R?mi > >> > >> ----- Mail original ----- > >>> De: "Alan Bateman" > >>> ?: "Stephen Colebourne" , "jigsaw-dev" < > jigsaw-dev at openjdk.java.net> > >>> Envoy?: Mercredi 23 Mars 2016 16:18:50 > >>> Objet: Re: modulepath and classpath mixture > >>> > >>> > >>> On 23/03/2016 14:42, Stephen Colebourne wrote: > >>>> : > >>>> > >>>> I don't particularly care what the mechanism is for this, but at the > >>>> requirements level: > >>>> - there are two modules - main and test > >>>> - each has its own source tree > >>>> - each has its own dependencies > >>>> - each is released separately > >>>> - each could be hosted on a central repo > >>>> - the test module needs to be able to contain the same packages as the > >>>> main module > >>>> - the test module needs to be able to invoke package-scoped code in > >>>> the same package in the main module > >>>> > >>>> To clarify further consider 4 modules, A, B, A-test and B-test where B > >>>> depends on A. Module A-test may have a method foo() that uses package > >>>> scope to access something in A. Module B-test will depend on A-test > >>>> and rely on foo() to get access to that internal object. > >>> To your list, I would add the ability to make use of testing frameworks > >>> like TestNG and JUnit. > >>> > >>> In any case, and as things currently stand, you've got most of the > >>> above. One differences is that the tests are not a separate module, > they > >>> are instead compiled and run in a way that patches the main module. The > >>> second difference is that they don't have their own module declaration, > >>> instead the compilation or run augments the dependences with any > >>> additional dependences that the tests have. As I said, if they tools > >>> makes it easy then I don't think it's too bad. > >>> > >>>> > >>>> (Note that I view the thread discussion of > >>>> references to test classes on the classpath as another hack. > >>>> > >>> Packages can't be split between modules and classpath so there is no > >>> support for that. > >>> > >>> -Alan > >>> > > From ydwchina at gmail.com Wed Mar 30 03:53:25 2016 From: ydwchina at gmail.com (deven you) Date: Wed, 30 Mar 2016 11:53:25 +0800 Subject: Modularity status? Message-ID: Hi All, I see 8142968: Module System implementation already included in OpenJDK9 but jake is still in active as well as m3 seems. I just wonder what the status of modularity on OpenJDK9 now? Are there still more changes coming into OpenJDK9 from jake or m3? Thanks a lot! From tomas.zezula at oracle.com Wed Mar 30 05:53:56 2016 From: tomas.zezula at oracle.com (Tomas Zezula) Date: Wed, 30 Mar 2016 07:53:56 +0200 Subject: Jigsaw + Ant Message-ID: <1FA6EB1D-7DE3-4200-A8D4-3DB77FC4E2D5@oracle.com> Hi All, the Ant 1.9.7alpha (https://ant.apache.org/nightlies.html) now supports modules in the Javac and Java tasks. The Javac single module compilation example: The Javac multi-module compilation example: The main module execution example: ? Tomas From Alan.Bateman at oracle.com Wed Mar 30 07:00:54 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 30 Mar 2016 08:00:54 +0100 Subject: Jigsaw + Ant In-Reply-To: <1FA6EB1D-7DE3-4200-A8D4-3DB77FC4E2D5@oracle.com> References: <1FA6EB1D-7DE3-4200-A8D4-3DB77FC4E2D5@oracle.com> Message-ID: <56FB79A6.2040308@oracle.com> On 30/03/2016 06:53, Tomas Zezula wrote: > Hi All, > the Ant 1.9.7alpha (https://ant.apache.org/nightlies.html) now supports modules in the Javac and Java tasks. > Just browsing the ant-dev archives ad I see you created the patch and opened the pull request - thanks for that, it's good to have these tasks supporting the module options. -Alan From Alan.Bateman at oracle.com Wed Mar 30 07:09:13 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 30 Mar 2016 08:09:13 +0100 Subject: Modularity status? In-Reply-To: References: Message-ID: <56FB7B99.3090401@oracle.com> On 30/03/2016 04:53, deven you wrote: > Hi All, > > I see 8142968: Module System implementation already included in OpenJDK9 > but jake is still in active as well as m3 seems. > > I just wonder what the status of modularity on OpenJDK9 now? Are there > still more changes coming into OpenJDK9 from jake or m3? > Mark has a note about this in his recent blog [1], see the last paragraph. So assume that there will be changes going into jake for some time. Where possible then we'll direct the changes to jdk9/dev or other integration forests, esp. for changes that aren't core or tied to design issues. We'll try to sync up JDK 9 periodically too so that we don't have a huge patch building up in jake. -Alan [1] http://mreinhold.org/blog/jigsaw-module-system From Alan.Bateman at oracle.com Wed Mar 30 07:11:20 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 30 Mar 2016 08:11:20 +0100 Subject: RFR: 8152704: jlink command line output/help message improvement In-Reply-To: <56FAF2D8.4020906@oracle.com> References: <56FAF2D8.4020906@oracle.com> Message-ID: <56FB7C18.60909@oracle.com> On 29/03/2016 22:25, Naoto Sato wrote: > Hello, > > Please review the changes for the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8152704 > > The suggested change is located at: > > http://cr.openjdk.java.net/~naoto/8152704/webrev.01/ This looks okay to me too. -Alan From peter.levart at gmail.com Wed Mar 30 07:40:46 2016 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 30 Mar 2016 09:40:46 +0200 Subject: RFR: 8152641: Plugin to generate BMH$Species classes ahead-of-time In-Reply-To: <56FB09D3.4090000@oracle.com> References: <56F3EEAB.4090600@oracle.com> <1FE3F7A6-1C7B-4DC6-875C-E3FAEDED08F5@oracle.com> <56F50EC5.6020500@gmail.com> <56F5520D.3080205@oracle.com> <56F676CA.5000803@gmail.com> <56FB09D3.4090000@oracle.com> Message-ID: <56FB82FE.5010209@gmail.com> Hi Claes, On 03/30/2016 01:03 AM, Claes Redestad wrote: > Hi Peter, Mandy, > > On 2016-03-26 12:47, Peter Levart wrote: >> >> Comparing this with proposed code from webrev: >> >> 493 try { >> 494 return (Class> BoundMethodHandle>) >> 495 Class.forName("java.lang.invoke.BoundMethodHandle$Species_" + >> LambdaForm.shortenSignature(types)); >> 496 } catch (ClassNotFoundException cnf) { >> 497 // Not pregenerated, generate the class >> 498 return generateConcreteBMHClass(types); >> 499 } >> >> >> ...note that the function passed to CLASS_CACHE.computeIfAbsent is >> executed just once per distinct 'types' argument. Even if you put the >> generated switch between a call to getConcreteBMHClass and >> CLASS_CACHE.computeIfAbsent, getConcreteBMHClass(String types) is >> executed just once per distinct 'types' argument (except in rare >> occasions when VM can not initialize the loaded class). >> >> In this respect a successful Class.forName() is not any worse than >> static resolving. It's just that unsuccessful Class.forName() >> represents some overhead for classes that are not pre-generated. So >> an alternative way to get rid of that overhead is to have a HashSet >> of 'types' strings for pre-generated classes at hand in order to >> decide whether to call Class.forName or generateConcreteBMHClass. >> >> What's easier to support is another question. >> >> Regards, Peter > > to have something to compare with I built a version which, like you > suggest, > generates a HashSet with the set of generated classes here: > > http://cr.openjdk.java.net/~redestad/8152641/webrev.02/ > > This adds a fair bit of complexity to the plugin and requires we add a > nested > class in BoundMethodHandle that we can replace. Using the anonymous > compute Function for this seems like the best choice for this. ...what I had in mind as alternative to a pregenerated class with a switch was a simple textual resource file, generated by plugin, read-in by BMH into a HashSet. No special-purpose class generation and much less complexity for the plugin. > > I've not been able to measure any statistical difference in real > startup terms, > though, and not figured out a smart way to benchmark the overhead of the > CNFE in relation to the class generation (my guess it adds a fraction > to the > total cost) and since this adds ever so little footprint and an extra > lookup to the > fast path it would seem that this is the wrong trade-off to do here. Yes, perhaps it would be best to just use Class.forName(module, className) instead. I have created a little benchmark to compare overheads (just overheads) of unsuccessful lookups for pregenerated classes (a situation where a BMH class is requested that has not been pregenerated) and here's the result for overhead of 5 unsuccessfull lookups: Benchmark (generate) (lookup) Mode Cnt Score Error Units ClassForNameBench.classForName LL,LLL,LLLL,LLLLL,LLLLLL LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 6800.878 ? 421.424 ns/op ClassForNameBench.classForNameInModule LL,LLL,LLLL,LLLLL,LLLLLL LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 209.574 ? 2.114 ns/op ClassForNameBench.hashSetContains LL,LLL,LLLL,LLLLL,LLLLLL LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 6.813 ? 0.317 ns/op ClassForNameBench.switchStatement LL,LLL,LLLL,LLLLL,LLLLLL LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 6.601 ? 0.061 ns/op ...compared to runtime BMH class generation and loading this is really a very minor overhead. I would just use Class.forName(module, className) and reduce the complexity of the plugin. What do you think? Here's the benchmark: package jdk.test; import org.openjdk.jmh.annotations.*; import org.openjdk.jmh.infra.Blackhole; import java.io.Serializable; import java.lang.invoke.MethodHandle; import java.util.Iterator; import java.util.Set; import java.util.concurrent.TimeUnit; import java.util.stream.Collectors; import java.util.stream.Stream; @BenchmarkMode(Mode.AverageTime) @Fork(value = 1, warmups = 0) @Warmup(iterations = 10) @Measurement(iterations = 10) @OutputTimeUnit(TimeUnit.NANOSECONDS) @State(Scope.Thread) public class ClassForNameBench { static final String BMH = "java/lang/invoke/BoundMethodHandle"; static final String SPECIES_PREFIX_NAME = "Species_"; static final String SPECIES_PREFIX_PATH = BMH + "$" + SPECIES_PREFIX_NAME; @Param({"LL,LLL,LLLL,LLLLL,LLLLLL"}) public String generate; @Param({"LLI,LLLI,LLLLI,LLLLLI,LLLLLLI"}) public String lookup; private String[] generatedTypes; private String[] lookedUpTypes; private Set generatedNames; private String[] lookedUpNames; @Setup(Level.Trial) public void setup() { generatedTypes = generate.trim().split("\\s+,\\s+"); lookedUpTypes = lookup.trim().split("\\s+,\\s+"); generatedNames = Stream.of(generatedTypes) .map(types -> SPECIES_PREFIX_PATH + shortenSignature(types)) .collect(Collectors.toSet()); lookedUpNames = Stream.of(lookedUpTypes) .map(types -> SPECIES_PREFIX_PATH + shortenSignature(types)) .toArray(String[]::new); } @Benchmark public void classForName(Blackhole bh) { for (String name : lookedUpNames) { try { bh.consume(Class.forName(name, false, MethodHandle.class.getClassLoader())); } catch (ClassNotFoundException e) { bh.consume(e); } } } @Benchmark public void classForNameInModule(Blackhole bh) { for (String name : lookedUpNames) { bh.consume(Class.forName(MethodHandle.class.getModule(), name)); } } @Benchmark public void hashSetContains(Blackhole bh) { for (String name : lookedUpNames) { bh.consume(generatedNames.contains(name)); } } @Benchmark public void switchStatement(Blackhole bh) { for (String types : lookedUpTypes) { bh.consume(getBMHSwitch(types)); } } static Class getBMHSwitch(String types) { // should be in sync with @Param generate above... switch (types) { case "LL": return Object.class; case "LLL": return Serializable.class; case "LLLL": return Iterator.class; case "LLLLL": return Throwable.class; case "LLLLLL": return String.class; default: return null; } } // copied from non-public LambdaForm static String shortenSignature(String signature) { // Hack to make signatures more readable when they show up in method names. final int NO_CHAR = -1, MIN_RUN = 3; int c0, c1 = NO_CHAR, c1reps = 0; StringBuilder buf = null; int len = signature.length(); if (len < MIN_RUN) return signature; for (int i = 0; i <= len; i++) { // shift in the next char: c0 = c1; c1 = (i == len ? NO_CHAR : signature.charAt(i)); if (c1 == c0) { ++c1reps; continue; } // shift in the next count: int c0reps = c1reps; c1reps = 1; // end of a character run if (c0reps < MIN_RUN) { if (buf != null) { while (--c0reps >= 0) buf.append((char) c0); } continue; } // found three or more in a row if (buf == null) buf = new StringBuilder().append(signature, 0, i - c0reps); buf.append((char) c0).append(c0reps); } return (buf == null) ? signature : buf.toString(); } } Regards, Peter > > All-in-all I lean towards moving forward with the first, simpler > revision of this > patch[1] and then evaluate if webrev.02 or a String-switch+static resolve > as a follow-up. > > A compromise would be to keep the SpeciesLookup class introduced here > to allow removing all overhead in case the plugin is disabled. > > Mandy: I've not found any test (under jdk/test/tools/jlink or > elsewhere) which > has to be updated when adding a plugin like this. > > Thanks! > > /Claes > > [1] http://cr.openjdk.java.net/~redestad/8152641/webrev.01/ From peter.levart at gmail.com Wed Mar 30 07:53:43 2016 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 30 Mar 2016 09:53:43 +0200 Subject: RFR: 8152641: Plugin to generate BMH$Species classes ahead-of-time In-Reply-To: <56FB82FE.5010209@gmail.com> References: <56F3EEAB.4090600@oracle.com> <1FE3F7A6-1C7B-4DC6-875C-E3FAEDED08F5@oracle.com> <56F50EC5.6020500@gmail.com> <56F5520D.3080205@oracle.com> <56F676CA.5000803@gmail.com> <56FB09D3.4090000@oracle.com> <56FB82FE.5010209@gmail.com> Message-ID: <56FB8607.8030000@gmail.com> Hi Claes, Sorry, I found a flaw in the benchmark (the regex pattern to split comma-separated string into substrings was wrong). What the benchmark did was compare the overheads of a single lookup of a longer class name containing commas. Here's the corrected result of overheads of 5 unsuccessful lookups: Benchmark (generate) (lookup) Mode Cnt Score Error Units ClassForNameBench.classForName LL,LLL,LLLL,LLLLL,LLLLLL LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 29627.141 ? 567.427 ns/op ClassForNameBench.classForNameInModule LL,LLL,LLLL,LLLLL,LLLLLL LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 1073.256 ? 23.794 ns/op ClassForNameBench.hashSetContains LL,LLL,LLLL,LLLLL,LLLLLL LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 33.022 ? 0.066 ns/op ClassForNameBench.switchStatement LL,LLL,LLLL,LLLLL,LLLLLL LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 38.498 ? 5.842 ns/op ...overheads are a little bigger (x5 approx.). Here's the corrected benchmark: package jdk.test; import org.openjdk.jmh.annotations.*; import org.openjdk.jmh.infra.Blackhole; import java.io.Serializable; import java.lang.invoke.MethodHandle; import java.util.Iterator; import java.util.Set; import java.util.concurrent.TimeUnit; import java.util.stream.Collectors; import java.util.stream.Stream; @BenchmarkMode(Mode.AverageTime) @Fork(value = 1, warmups = 0) @Warmup(iterations = 10) @Measurement(iterations = 10) @OutputTimeUnit(TimeUnit.NANOSECONDS) @State(Scope.Thread) public class ClassForNameBench { static final String BMH = "java/lang/invoke/BoundMethodHandle"; static final String SPECIES_PREFIX_NAME = "Species_"; static final String SPECIES_PREFIX_PATH = BMH + "$" + SPECIES_PREFIX_NAME; @Param({"LL,LLL,LLLL,LLLLL,LLLLLL"}) public String generate; @Param({"LLI,LLLI,LLLLI,LLLLLI,LLLLLLI"}) public String lookup; private String[] generatedTypes; private String[] lookedUpTypes; private Set generatedNames; private String[] lookedUpNames; @Setup(Level.Trial) public void setup() { generatedTypes = generate.trim().split("\\s*,\\s*"); lookedUpTypes = lookup.trim().split("\\s*,\\s*"); generatedNames = Stream.of(generatedTypes) .map(types -> SPECIES_PREFIX_PATH + shortenSignature(types)) .collect(Collectors.toSet()); lookedUpNames = Stream.of(lookedUpTypes) .map(types -> SPECIES_PREFIX_PATH + shortenSignature(types)) .toArray(String[]::new); } @Benchmark public void classForName(Blackhole bh) { for (String name : lookedUpNames) { try { bh.consume(Class.forName(name, false, MethodHandle.class.getClassLoader())); } catch (ClassNotFoundException e) { bh.consume(e); } } } @Benchmark public void classForNameInModule(Blackhole bh) { for (String name : lookedUpNames) { bh.consume(Class.forName(MethodHandle.class.getModule(), name)); } } @Benchmark public void hashSetContains(Blackhole bh) { for (String name : lookedUpNames) { bh.consume(generatedNames.contains(name)); } } @Benchmark public void switchStatement(Blackhole bh) { for (String types : lookedUpTypes) { bh.consume(getBMHSwitch(types)); } } static Class getBMHSwitch(String types) { // should be in sync with @Param generate above... switch (types) { case "LL": return Object.class; case "LLL": return Serializable.class; case "LLLL": return Iterator.class; case "LLLLL": return Throwable.class; case "LLLLLL": return String.class; default: return null; } } // copied from non-public LambdaForm static String shortenSignature(String signature) { // Hack to make signatures more readable when they show up in method names. final int NO_CHAR = -1, MIN_RUN = 3; int c0, c1 = NO_CHAR, c1reps = 0; StringBuilder buf = null; int len = signature.length(); if (len < MIN_RUN) return signature; for (int i = 0; i <= len; i++) { // shift in the next char: c0 = c1; c1 = (i == len ? NO_CHAR : signature.charAt(i)); if (c1 == c0) { ++c1reps; continue; } // shift in the next count: int c0reps = c1reps; c1reps = 1; // end of a character run if (c0reps < MIN_RUN) { if (buf != null) { while (--c0reps >= 0) buf.append((char) c0); } continue; } // found three or more in a row if (buf == null) buf = new StringBuilder().append(signature, 0, i - c0reps); buf.append((char) c0).append(c0reps); } return (buf == null) ? signature : buf.toString(); } } Regards, Peter On 03/30/2016 09:40 AM, Peter Levart wrote: > Hi Claes, > > On 03/30/2016 01:03 AM, Claes Redestad wrote: >> Hi Peter, Mandy, >> >> On 2016-03-26 12:47, Peter Levart wrote: >>> >>> Comparing this with proposed code from webrev: >>> >>> 493 try { >>> 494 return (Class>> BoundMethodHandle>) >>> 495 Class.forName("java.lang.invoke.BoundMethodHandle$Species_" + >>> LambdaForm.shortenSignature(types)); >>> 496 } catch (ClassNotFoundException cnf) { >>> 497 // Not pregenerated, generate the class >>> 498 return generateConcreteBMHClass(types); >>> 499 } >>> >>> >>> ...note that the function passed to CLASS_CACHE.computeIfAbsent is >>> executed just once per distinct 'types' argument. Even if you put >>> the generated switch between a call to getConcreteBMHClass and >>> CLASS_CACHE.computeIfAbsent, getConcreteBMHClass(String types) is >>> executed just once per distinct 'types' argument (except in rare >>> occasions when VM can not initialize the loaded class). >>> >>> In this respect a successful Class.forName() is not any worse than >>> static resolving. It's just that unsuccessful Class.forName() >>> represents some overhead for classes that are not pre-generated. So >>> an alternative way to get rid of that overhead is to have a HashSet >>> of 'types' strings for pre-generated classes at hand in order to >>> decide whether to call Class.forName or generateConcreteBMHClass. >>> >>> What's easier to support is another question. >>> >>> Regards, Peter >> >> to have something to compare with I built a version which, like you >> suggest, >> generates a HashSet with the set of generated classes here: >> >> http://cr.openjdk.java.net/~redestad/8152641/webrev.02/ >> >> This adds a fair bit of complexity to the plugin and requires we add >> a nested >> class in BoundMethodHandle that we can replace. Using the anonymous >> compute Function for this seems like the best choice for this. > > ...what I had in mind as alternative to a pregenerated class with a > switch was a simple textual resource file, generated by plugin, > read-in by BMH into a HashSet. No special-purpose class generation and > much less complexity for the plugin. > >> >> I've not been able to measure any statistical difference in real >> startup terms, >> though, and not figured out a smart way to benchmark the overhead of the >> CNFE in relation to the class generation (my guess it adds a fraction >> to the >> total cost) and since this adds ever so little footprint and an extra >> lookup to the >> fast path it would seem that this is the wrong trade-off to do here. > > Yes, perhaps it would be best to just use Class.forName(module, > className) instead. I have created a little benchmark to compare > overheads (just overheads) of unsuccessful lookups for pregenerated > classes (a situation where a BMH class is requested that has not been > pregenerated) and here's the result for overhead of 5 unsuccessfull > lookups: > > Benchmark (generate) (lookup) Mode Cnt > Score Error Units > ClassForNameBench.classForName LL,LLL,LLLL,LLLLL,LLLLLL > LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 6800.878 ? 421.424 ns/op > ClassForNameBench.classForNameInModule LL,LLL,LLLL,LLLLL,LLLLLL > LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 209.574 ? 2.114 ns/op > ClassForNameBench.hashSetContains LL,LLL,LLLL,LLLLL,LLLLLL > LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 6.813 ? 0.317 ns/op > ClassForNameBench.switchStatement LL,LLL,LLLL,LLLLL,LLLLLL > LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 6.601 ? 0.061 ns/op > > ...compared to runtime BMH class generation and loading this is really > a very minor overhead. I would just use Class.forName(module, > className) and reduce the complexity of the plugin. > > What do you think? > > > Here's the benchmark: > > package jdk.test; > > import org.openjdk.jmh.annotations.*; > import org.openjdk.jmh.infra.Blackhole; > > import java.io.Serializable; > import java.lang.invoke.MethodHandle; > import java.util.Iterator; > import java.util.Set; > import java.util.concurrent.TimeUnit; > import java.util.stream.Collectors; > import java.util.stream.Stream; > > @BenchmarkMode(Mode.AverageTime) > @Fork(value = 1, warmups = 0) > @Warmup(iterations = 10) > @Measurement(iterations = 10) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > @State(Scope.Thread) > public class ClassForNameBench { > > static final String BMH = "java/lang/invoke/BoundMethodHandle"; > static final String SPECIES_PREFIX_NAME = "Species_"; > static final String SPECIES_PREFIX_PATH = BMH + "$" + > SPECIES_PREFIX_NAME; > > @Param({"LL,LLL,LLLL,LLLLL,LLLLLL"}) > public String generate; > > @Param({"LLI,LLLI,LLLLI,LLLLLI,LLLLLLI"}) > public String lookup; > > private String[] generatedTypes; > private String[] lookedUpTypes; > private Set generatedNames; > private String[] lookedUpNames; > > @Setup(Level.Trial) > public void setup() { > generatedTypes = generate.trim().split("\\s+,\\s+"); > lookedUpTypes = lookup.trim().split("\\s+,\\s+"); > generatedNames = Stream.of(generatedTypes) > .map(types -> SPECIES_PREFIX_PATH + > shortenSignature(types)) > .collect(Collectors.toSet()); > lookedUpNames = Stream.of(lookedUpTypes) > .map(types -> SPECIES_PREFIX_PATH + > shortenSignature(types)) > .toArray(String[]::new); > } > > @Benchmark > public void classForName(Blackhole bh) { > for (String name : lookedUpNames) { > try { > bh.consume(Class.forName(name, false, > MethodHandle.class.getClassLoader())); > } catch (ClassNotFoundException e) { > bh.consume(e); > } > } > } > > @Benchmark > public void classForNameInModule(Blackhole bh) { > for (String name : lookedUpNames) { > bh.consume(Class.forName(MethodHandle.class.getModule(), name)); > } > } > > @Benchmark > public void hashSetContains(Blackhole bh) { > for (String name : lookedUpNames) { > bh.consume(generatedNames.contains(name)); > } > } > > @Benchmark > public void switchStatement(Blackhole bh) { > for (String types : lookedUpTypes) { > bh.consume(getBMHSwitch(types)); > } > } > > static Class getBMHSwitch(String types) { > // should be in sync with @Param generate above... > switch (types) { > case "LL": return Object.class; > case "LLL": return Serializable.class; > case "LLLL": return Iterator.class; > case "LLLLL": return Throwable.class; > case "LLLLLL": return String.class; > default: return null; > } > } > > // copied from non-public LambdaForm > static String shortenSignature(String signature) { > // Hack to make signatures more readable when they show up in > method names. > final int NO_CHAR = -1, MIN_RUN = 3; > int c0, c1 = NO_CHAR, c1reps = 0; > StringBuilder buf = null; > int len = signature.length(); > if (len < MIN_RUN) return signature; > for (int i = 0; i <= len; i++) { > // shift in the next char: > c0 = c1; c1 = (i == len ? NO_CHAR : signature.charAt(i)); > if (c1 == c0) { ++c1reps; continue; } > // shift in the next count: > int c0reps = c1reps; c1reps = 1; > // end of a character run > if (c0reps < MIN_RUN) { > if (buf != null) { > while (--c0reps >= 0) > buf.append((char) c0); > } > continue; > } > // found three or more in a row > if (buf == null) > buf = new StringBuilder().append(signature, 0, i - > c0reps); > buf.append((char) c0).append(c0reps); > } > return (buf == null) ? signature : buf.toString(); > } > } > > > > Regards, Peter > >> >> All-in-all I lean towards moving forward with the first, simpler >> revision of this >> patch[1] and then evaluate if webrev.02 or a String-switch+static >> resolve >> as a follow-up. >> >> A compromise would be to keep the SpeciesLookup class introduced here >> to allow removing all overhead in case the plugin is disabled. >> >> Mandy: I've not found any test (under jdk/test/tools/jlink or >> elsewhere) which >> has to be updated when adding a plugin like this. >> >> Thanks! >> >> /Claes >> >> [1] http://cr.openjdk.java.net/~redestad/8152641/webrev.01/ > From forax at univ-mlv.fr Wed Mar 30 09:18:04 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 30 Mar 2016 11:18:04 +0200 (CEST) Subject: Jigsaw + Ant In-Reply-To: <1FA6EB1D-7DE3-4200-A8D4-3DB77FC4E2D5@oracle.com> References: <1FA6EB1D-7DE3-4200-A8D4-3DB77FC4E2D5@oracle.com> Message-ID: <867636023.1980264.1459329484654.JavaMail.zimbra@u-pem.fr> Hi Tomas, many thanks for your work, it seems, i will be able to ditch the shell scripts i currently used soon :) May i ask you to also add the support for modules in the jar task and to create a jlink task ? regards, R?mi ----- Mail original ----- > De: "Tomas Zezula" > ?: jigsaw-dev at openjdk.java.net > Envoy?: Mercredi 30 Mars 2016 07:53:56 > Objet: Jigsaw + Ant > > Hi All, > the Ant 1.9.7alpha (https://ant.apache.org/nightlies.html) now supports > modules in the Javac and Java tasks. > > The Javac single module compilation example: > > destdir="${build}" > includeantruntime="false" > modulepath="modules" > source="9" > /> > > > The Javac multi-module compilation example: > > destdir="${build}" > includeantruntime="false" > modulepath="modules" > source="9" > /> > > The main module execution example: > > module="TestModule" > modulepath="lib:dist/test.jar?/> > > An execution of an explicit main class in a module: > > module="TestModule" > classname="Main"> > > > > > > > > ? Tomas From scolebourne at joda.org Wed Mar 30 09:26:44 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 30 Mar 2016 10:26:44 +0100 Subject: modulepath and classpath mixture In-Reply-To: <0CC4E4A6-4152-4BB0-BB42-B9E284540BB6@oracle.com> References: <56CC57A1.2050109@oracle.com> <56F2440A.7010505@oracle.com> <56F2914C.3030706@oracle.com> <56F2B3DA.402@oracle.com> <1228911717.349701.1459160027285.JavaMail.zimbra@u-pem.fr> <0CC4E4A6-4152-4BB0-BB42-B9E284540BB6@oracle.com> Message-ID: On 29 March 2016 at 17:33, Russell Gold wrote: > Hi Stephen, > Why do you need any kind of friend access? > It seems to me that this is making things harder than they need to be. The tests can simply run with the production code on the class path, and then there are no module issues at all. The underlying message of Jigsaw is that the classpath is going away. An approach that requires use of the classpath is therefore not really a solution to the real problem. Stephen > I think a larger problem is that you can do what I just said with the jars, even a jar which has been designated as a module by virtue of having a module-info.class in it. That means that, when users are up taking jars, they are not prevented from accessing module internals. They can put the jars on the module path, of course, but they can still use them on the class path! > > - Russ > >> >> On 28 March 2016 at 11:13, Remi Forax wrote: >>> Hi Stephen, Hi all, >>> I think that delivering tests as a separated module is a bad idea. >>> >>> I see that from the point of a developer, seeing the code and the test as different modules can be attractive because everything seems to be put at the right place but there is a big drawback. Because modules are reified at runtime, it means that the runtime environment of the tests will be different from the production environment. >> >> This last sentence doesn't make sense to me - tests are not run in a >> production environment. >> >> Tests have all the qualities of modules - code, dependencies, >> compilation phase, deployment. The only special part is the need for >> special "friend-like" access, which Jigsaw already has for other cases >> (the export...to clause). >> >> Put simply, I consider that module = >> deployment-artifact-with-dependencies. With that mental model, putting >> tests inside the module is just not acceptable, because tests should >> not be deployed with the main application and they have different >> dependencies. If we disagree that module = >> deployment-artifact-with-dependencies, then perhaps we have bigger >> problems to solve here. >> >> Stephen >> (And to Paul Benedict, the classpath is going to die over time, so any >> solution that uses that is flawed IMO). >> >> >>> So as Alan said, from the jigsaw point of view at runtime, the tests and the code should be in the same module. >>> >>> So the building tools have to come with a way to support to have 2 different module-info.java in two different folders and package them as one module, >>> maybe javac should help by providing a way to merge 2 module-info at compile time. >>> >>> R?mi >>> >>> ----- Mail original ----- >>>> De: "Alan Bateman" >>>> ?: "Stephen Colebourne" , "jigsaw-dev" >>>> Envoy?: Mercredi 23 Mars 2016 16:18:50 >>>> Objet: Re: modulepath and classpath mixture >>>> >>>> >>>> On 23/03/2016 14:42, Stephen Colebourne wrote: >>>>> : >>>>> >>>>> I don't particularly care what the mechanism is for this, but at the >>>>> requirements level: >>>>> - there are two modules - main and test >>>>> - each has its own source tree >>>>> - each has its own dependencies >>>>> - each is released separately >>>>> - each could be hosted on a central repo >>>>> - the test module needs to be able to contain the same packages as the >>>>> main module >>>>> - the test module needs to be able to invoke package-scoped code in >>>>> the same package in the main module >>>>> >>>>> To clarify further consider 4 modules, A, B, A-test and B-test where B >>>>> depends on A. Module A-test may have a method foo() that uses package >>>>> scope to access something in A. Module B-test will depend on A-test >>>>> and rely on foo() to get access to that internal object. >>>> To your list, I would add the ability to make use of testing frameworks >>>> like TestNG and JUnit. >>>> >>>> In any case, and as things currently stand, you've got most of the >>>> above. One differences is that the tests are not a separate module, they >>>> are instead compiled and run in a way that patches the main module. The >>>> second difference is that they don't have their own module declaration, >>>> instead the compilation or run augments the dependences with any >>>> additional dependences that the tests have. As I said, if they tools >>>> makes it easy then I don't think it's too bad. >>>> >>>>> >>>>> (Note that I view the thread discussion of >>>>> references to test classes on the classpath as another hack. >>>>> >>>> Packages can't be split between modules and classpath so there is no >>>> support for that. >>>> >>>> -Alan >>>> > From ali.ebrahimi1781 at gmail.com Wed Mar 30 09:59:09 2016 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Wed, 30 Mar 2016 14:29:09 +0430 Subject: modulepath and classpath mixture In-Reply-To: References: <56CC57A1.2050109@oracle.com> <56F2440A.7010505@oracle.com> <56F2914C.3030706@oracle.com> <56F2B3DA.402@oracle.com> <1228911717.349701.1459160027285.JavaMail.zimbra@u-pem.fr> <0CC4E4A6-4152-4BB0-BB42-B9E284540BB6@oracle.com> Message-ID: Also, we should look for solutions not workaround( or hacks) in remaining time. I think classpath was that problem we trying avoid (or solve) with jigsaw. On Wed, Mar 30, 2016 at 1:56 PM, Stephen Colebourne wrote: > On 29 March 2016 at 17:33, Russell Gold wrote: > > Hi Stephen, > > Why do you need any kind of friend access? > > It seems to me that this is making things harder than they need to be. > The tests can simply run with the production code on the class path, and > then there are no module issues at all. > > The underlying message of Jigsaw is that the classpath is going away. > An approach that requires use of the classpath is therefore not really > a solution to the real problem. > > Stephen > > > > I think a larger problem is that you can do what I just said with the > jars, even a jar which has been designated as a module by virtue of having > a module-info.class in it. That means that, when users are up taking jars, > they are not prevented from accessing module internals. They can put the > jars on the module path, of course, but they can still use them on the > class path! > > > > - Russ > > > >> > >> On 28 March 2016 at 11:13, Remi Forax wrote: > >>> Hi Stephen, Hi all, > >>> I think that delivering tests as a separated module is a bad idea. > >>> > >>> I see that from the point of a developer, seeing the code and the test > as different modules can be attractive because everything seems to be put > at the right place but there is a big drawback. Because modules are reified > at runtime, it means that the runtime environment of the tests will be > different from the production environment. > >> > >> This last sentence doesn't make sense to me - tests are not run in a > >> production environment. > >> > >> Tests have all the qualities of modules - code, dependencies, > >> compilation phase, deployment. The only special part is the need for > >> special "friend-like" access, which Jigsaw already has for other cases > >> (the export...to clause). > >> > >> Put simply, I consider that module = > >> deployment-artifact-with-dependencies. With that mental model, putting > >> tests inside the module is just not acceptable, because tests should > >> not be deployed with the main application and they have different > >> dependencies. If we disagree that module = > >> deployment-artifact-with-dependencies, then perhaps we have bigger > >> problems to solve here. > >> > >> Stephen > >> (And to Paul Benedict, the classpath is going to die over time, so any > >> solution that uses that is flawed IMO). > >> > >> > >>> So as Alan said, from the jigsaw point of view at runtime, the tests > and the code should be in the same module. > >>> > >>> So the building tools have to come with a way to support to have 2 > different module-info.java in two different folders and package them as one > module, > >>> maybe javac should help by providing a way to merge 2 module-info at > compile time. > >>> > >>> R?mi > >>> > >>> ----- Mail original ----- > >>>> De: "Alan Bateman" > >>>> ?: "Stephen Colebourne" , "jigsaw-dev" < > jigsaw-dev at openjdk.java.net> > >>>> Envoy?: Mercredi 23 Mars 2016 16:18:50 > >>>> Objet: Re: modulepath and classpath mixture > >>>> > >>>> > >>>> On 23/03/2016 14:42, Stephen Colebourne wrote: > >>>>> : > >>>>> > >>>>> I don't particularly care what the mechanism is for this, but at the > >>>>> requirements level: > >>>>> - there are two modules - main and test > >>>>> - each has its own source tree > >>>>> - each has its own dependencies > >>>>> - each is released separately > >>>>> - each could be hosted on a central repo > >>>>> - the test module needs to be able to contain the same packages as > the > >>>>> main module > >>>>> - the test module needs to be able to invoke package-scoped code in > >>>>> the same package in the main module > >>>>> > >>>>> To clarify further consider 4 modules, A, B, A-test and B-test where > B > >>>>> depends on A. Module A-test may have a method foo() that uses package > >>>>> scope to access something in A. Module B-test will depend on A-test > >>>>> and rely on foo() to get access to that internal object. > >>>> To your list, I would add the ability to make use of testing > frameworks > >>>> like TestNG and JUnit. > >>>> > >>>> In any case, and as things currently stand, you've got most of the > >>>> above. One differences is that the tests are not a separate module, > they > >>>> are instead compiled and run in a way that patches the main module. > The > >>>> second difference is that they don't have their own module > declaration, > >>>> instead the compilation or run augments the dependences with any > >>>> additional dependences that the tests have. As I said, if they tools > >>>> makes it easy then I don't think it's too bad. > >>>> > >>>>> > >>>>> (Note that I view the thread discussion of > >>>>> references to test classes on the classpath as another hack. > >>>>> > >>>> Packages can't be split between modules and classpath so there is no > >>>> support for that. > >>>> > >>>> -Alan > >>>> > > > -- Best Regards, Ali Ebrahimi From sundararajan.athijegannathan at oracle.com Wed Mar 30 10:18:22 2016 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Wed, 30 Mar 2016 10:18:22 +0000 Subject: hg: jigsaw/jake/jdk: 8148491: Revisit jlink --genbom Message-ID: <201603301018.u2UAIMkP009658@aojmv0008.oracle.com> Changeset: fdaafc3eeb7c Author: sundar Date: 2016-03-30 15:48 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fdaafc3eeb7c 8148491: Revisit jlink --genbom Reviewed-by: jlaskey, alanb, mchung ! make/launcher/Launcher-jdk.scripting.nashorn.shell.gmk ! src/jdk.jlink/share/classes/jdk/tools/jimage/JImageTask.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/builder/DefaultImageBuilder.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/builder/ImageBuilder.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageFileCreator.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginConfiguration.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginStack.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties ! test/tools/jlink/ImageFileCreatorTest.java ! test/tools/jlink/IntegrationTest.java ! test/tools/jlink/JLink2Test.java ! test/tools/jlink/plugins/FileCopierPluginTest.java From Alan.Bateman at oracle.com Wed Mar 30 10:23:29 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 30 Mar 2016 11:23:29 +0100 Subject: modulepath and classpath mixture In-Reply-To: References: <56CC57A1.2050109@oracle.com> <56F2440A.7010505@oracle.com> <56F2914C.3030706@oracle.com> <56F2B3DA.402@oracle.com> <1228911717.349701.1459160027285.JavaMail.zimbra@u-pem.fr> <0CC4E4A6-4152-4BB0-BB42-B9E284540BB6@oracle.com> Message-ID: <56FBA921.6030206@oracle.com> On 30/03/2016 10:26, Stephen Colebourne wrote: > The underlying message of Jigsaw is that the classpath is going away. There are no plans, at least not in this project, to remove the class path. There is of course a better world beyond the class path, it's just going to take a long time and require a lot of existing code and configuration to be cleaned up in order to get there. We have a good story for modules and the class path to co-exist and we expect they will co-exist for a long long time, maybe forever. -Alan. From claes.redestad at oracle.com Wed Mar 30 10:53:08 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 30 Mar 2016 12:53:08 +0200 Subject: RFR: 8152641: Plugin to generate BMH$Species classes ahead-of-time In-Reply-To: <56FB8607.8030000@gmail.com> References: <56F3EEAB.4090600@oracle.com> <1FE3F7A6-1C7B-4DC6-875C-E3FAEDED08F5@oracle.com> <56F50EC5.6020500@gmail.com> <56F5520D.3080205@oracle.com> <56F676CA.5000803@gmail.com> <56FB09D3.4090000@oracle.com> <56FB82FE.5010209@gmail.com> <56FB8607.8030000@gmail.com> Message-ID: <56FBB014.6050002@oracle.com> Hi, I think Class.forName(Module, String) seemed like a nice efficiency/simplicity compromise, but there is some usage of lambdas/method-refs in the Module lookup code, especially for exploded modules (which get exercised during JDK build). Depending on a lambda from code in java.lang.invoke means we fail to bootstrap. But hey, we're living in an encapsulated world now, and this is in java.base, so why not go directly to the BootLoader: http://cr.openjdk.java.net/~redestad/8152641/webrev.03/ Since this is what's called from Class.forName(Module, String), the overhead should be even smaller than in your classForNameInModule test. If I call this final, will you say "Reviewed"? :-) /Claes PS: The default list of types is generated in a few adhoc tests not part of this patch. I'm considering proposing add support for generating this list at build time. Maybe a JEP called "Build system support for profile-guided optimizations", which could also handle https://bugs.openjdk.java.net/browse/JDK-8150044 On 2016-03-30 09:53, Peter Levart wrote: > Hi Claes, > > Sorry, I found a flaw in the benchmark (the regex pattern to split > comma-separated string into substrings was wrong). What the benchmark > did was compare the overheads of a single lookup of a longer class > name containing commas. Here's the corrected result of overheads of 5 > unsuccessful lookups: > > Benchmark (generate) (lookup) Mode Cnt > Score Error Units > ClassForNameBench.classForName LL,LLL,LLLL,LLLLL,LLLLLL > LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 29627.141 ? 567.427 ns/op > ClassForNameBench.classForNameInModule LL,LLL,LLLL,LLLLL,LLLLLL > LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 1073.256 ? 23.794 ns/op > ClassForNameBench.hashSetContains LL,LLL,LLLL,LLLLL,LLLLLL > LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 33.022 ? 0.066 ns/op > ClassForNameBench.switchStatement LL,LLL,LLLL,LLLLL,LLLLLL > LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 38.498 ? 5.842 ns/op > > ...overheads are a little bigger (x5 approx.). > > > Here's the corrected benchmark: > > > package jdk.test; > > import org.openjdk.jmh.annotations.*; > import org.openjdk.jmh.infra.Blackhole; > > import java.io.Serializable; > import java.lang.invoke.MethodHandle; > import java.util.Iterator; > import java.util.Set; > import java.util.concurrent.TimeUnit; > import java.util.stream.Collectors; > import java.util.stream.Stream; > > @BenchmarkMode(Mode.AverageTime) > @Fork(value = 1, warmups = 0) > @Warmup(iterations = 10) > @Measurement(iterations = 10) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > @State(Scope.Thread) > public class ClassForNameBench { > > static final String BMH = "java/lang/invoke/BoundMethodHandle"; > static final String SPECIES_PREFIX_NAME = "Species_"; > static final String SPECIES_PREFIX_PATH = BMH + "$" + > SPECIES_PREFIX_NAME; > > @Param({"LL,LLL,LLLL,LLLLL,LLLLLL"}) > public String generate; > > @Param({"LLI,LLLI,LLLLI,LLLLLI,LLLLLLI"}) > public String lookup; > > private String[] generatedTypes; > private String[] lookedUpTypes; > private Set generatedNames; > private String[] lookedUpNames; > > @Setup(Level.Trial) > public void setup() { > generatedTypes = generate.trim().split("\\s*,\\s*"); > lookedUpTypes = lookup.trim().split("\\s*,\\s*"); > generatedNames = Stream.of(generatedTypes) > .map(types -> SPECIES_PREFIX_PATH + > shortenSignature(types)) > .collect(Collectors.toSet()); > lookedUpNames = Stream.of(lookedUpTypes) > .map(types -> SPECIES_PREFIX_PATH + > shortenSignature(types)) > .toArray(String[]::new); > } > > @Benchmark > public void classForName(Blackhole bh) { > for (String name : lookedUpNames) { > try { > bh.consume(Class.forName(name, false, > MethodHandle.class.getClassLoader())); > } catch (ClassNotFoundException e) { > bh.consume(e); > } > } > } > > @Benchmark > public void classForNameInModule(Blackhole bh) { > for (String name : lookedUpNames) { > bh.consume(Class.forName(MethodHandle.class.getModule(), name)); > } > } > > @Benchmark > public void hashSetContains(Blackhole bh) { > for (String name : lookedUpNames) { > bh.consume(generatedNames.contains(name)); > } > } > > @Benchmark > public void switchStatement(Blackhole bh) { > for (String types : lookedUpTypes) { > bh.consume(getBMHSwitch(types)); > } > } > > static Class getBMHSwitch(String types) { > // should be in sync with @Param generate above... > switch (types) { > case "LL": return Object.class; > case "LLL": return Serializable.class; > case "LLLL": return Iterator.class; > case "LLLLL": return Throwable.class; > case "LLLLLL": return String.class; > default: return null; > } > } > > // copied from non-public LambdaForm > static String shortenSignature(String signature) { > // Hack to make signatures more readable when they show up in > method names. > final int NO_CHAR = -1, MIN_RUN = 3; > int c0, c1 = NO_CHAR, c1reps = 0; > StringBuilder buf = null; > int len = signature.length(); > if (len < MIN_RUN) return signature; > for (int i = 0; i <= len; i++) { > // shift in the next char: > c0 = c1; c1 = (i == len ? NO_CHAR : signature.charAt(i)); > if (c1 == c0) { ++c1reps; continue; } > // shift in the next count: > int c0reps = c1reps; c1reps = 1; > // end of a character run > if (c0reps < MIN_RUN) { > if (buf != null) { > while (--c0reps >= 0) > buf.append((char) c0); > } > continue; > } > // found three or more in a row > if (buf == null) > buf = new StringBuilder().append(signature, 0, i - > c0reps); > buf.append((char) c0).append(c0reps); > } > return (buf == null) ? signature : buf.toString(); > } > } > > > Regards, Peter > > > > On 03/30/2016 09:40 AM, Peter Levart wrote: >> Hi Claes, >> >> On 03/30/2016 01:03 AM, Claes Redestad wrote: >>> Hi Peter, Mandy, >>> >>> On 2016-03-26 12:47, Peter Levart wrote: >>>> >>>> Comparing this with proposed code from webrev: >>>> >>>> 493 try { >>>> 494 return (Class>>> BoundMethodHandle>) >>>> 495 Class.forName("java.lang.invoke.BoundMethodHandle$Species_" + >>>> LambdaForm.shortenSignature(types)); >>>> 496 } catch (ClassNotFoundException cnf) { >>>> 497 // Not pregenerated, generate the >>>> class >>>> 498 return >>>> generateConcreteBMHClass(types); >>>> 499 } >>>> >>>> >>>> ...note that the function passed to CLASS_CACHE.computeIfAbsent is >>>> executed just once per distinct 'types' argument. Even if you put >>>> the generated switch between a call to getConcreteBMHClass and >>>> CLASS_CACHE.computeIfAbsent, getConcreteBMHClass(String types) is >>>> executed just once per distinct 'types' argument (except in rare >>>> occasions when VM can not initialize the loaded class). >>>> >>>> In this respect a successful Class.forName() is not any worse than >>>> static resolving. It's just that unsuccessful Class.forName() >>>> represents some overhead for classes that are not pre-generated. So >>>> an alternative way to get rid of that overhead is to have a HashSet >>>> of 'types' strings for pre-generated classes at hand in order to >>>> decide whether to call Class.forName or generateConcreteBMHClass. >>>> >>>> What's easier to support is another question. >>>> >>>> Regards, Peter >>> >>> to have something to compare with I built a version which, like you >>> suggest, >>> generates a HashSet with the set of generated classes here: >>> >>> http://cr.openjdk.java.net/~redestad/8152641/webrev.02/ >>> >>> This adds a fair bit of complexity to the plugin and requires we add >>> a nested >>> class in BoundMethodHandle that we can replace. Using the anonymous >>> compute Function for this seems like the best choice for this. >> >> ...what I had in mind as alternative to a pregenerated class with a >> switch was a simple textual resource file, generated by plugin, >> read-in by BMH into a HashSet. No special-purpose class generation >> and much less complexity for the plugin. >> >>> >>> I've not been able to measure any statistical difference in real >>> startup terms, >>> though, and not figured out a smart way to benchmark the overhead of >>> the >>> CNFE in relation to the class generation (my guess it adds a >>> fraction to the >>> total cost) and since this adds ever so little footprint and an >>> extra lookup to the >>> fast path it would seem that this is the wrong trade-off to do here. >> >> Yes, perhaps it would be best to just use Class.forName(module, >> className) instead. I have created a little benchmark to compare >> overheads (just overheads) of unsuccessful lookups for pregenerated >> classes (a situation where a BMH class is requested that has not been >> pregenerated) and here's the result for overhead of 5 unsuccessfull >> lookups: >> >> Benchmark (generate) (lookup) Mode Cnt >> Score Error Units >> ClassForNameBench.classForName LL,LLL,LLLL,LLLLL,LLLLLL >> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 6800.878 ? 421.424 ns/op >> ClassForNameBench.classForNameInModule LL,LLL,LLLL,LLLLL,LLLLLL >> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 209.574 ? 2.114 ns/op >> ClassForNameBench.hashSetContains LL,LLL,LLLL,LLLLL,LLLLLL >> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 6.813 ? 0.317 ns/op >> ClassForNameBench.switchStatement LL,LLL,LLLL,LLLLL,LLLLLL >> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 6.601 ? 0.061 ns/op >> >> ...compared to runtime BMH class generation and loading this is >> really a very minor overhead. I would just use Class.forName(module, >> className) and reduce the complexity of the plugin. >> >> What do you think? >> >> >> Here's the benchmark: >> >> package jdk.test; >> >> import org.openjdk.jmh.annotations.*; >> import org.openjdk.jmh.infra.Blackhole; >> >> import java.io.Serializable; >> import java.lang.invoke.MethodHandle; >> import java.util.Iterator; >> import java.util.Set; >> import java.util.concurrent.TimeUnit; >> import java.util.stream.Collectors; >> import java.util.stream.Stream; >> >> @BenchmarkMode(Mode.AverageTime) >> @Fork(value = 1, warmups = 0) >> @Warmup(iterations = 10) >> @Measurement(iterations = 10) >> @OutputTimeUnit(TimeUnit.NANOSECONDS) >> @State(Scope.Thread) >> public class ClassForNameBench { >> >> static final String BMH = "java/lang/invoke/BoundMethodHandle"; >> static final String SPECIES_PREFIX_NAME = "Species_"; >> static final String SPECIES_PREFIX_PATH = BMH + "$" + >> SPECIES_PREFIX_NAME; >> >> @Param({"LL,LLL,LLLL,LLLLL,LLLLLL"}) >> public String generate; >> >> @Param({"LLI,LLLI,LLLLI,LLLLLI,LLLLLLI"}) >> public String lookup; >> >> private String[] generatedTypes; >> private String[] lookedUpTypes; >> private Set generatedNames; >> private String[] lookedUpNames; >> >> @Setup(Level.Trial) >> public void setup() { >> generatedTypes = generate.trim().split("\\s+,\\s+"); >> lookedUpTypes = lookup.trim().split("\\s+,\\s+"); >> generatedNames = Stream.of(generatedTypes) >> .map(types -> SPECIES_PREFIX_PATH + >> shortenSignature(types)) >> .collect(Collectors.toSet()); >> lookedUpNames = Stream.of(lookedUpTypes) >> .map(types -> SPECIES_PREFIX_PATH + >> shortenSignature(types)) >> .toArray(String[]::new); >> } >> >> @Benchmark >> public void classForName(Blackhole bh) { >> for (String name : lookedUpNames) { >> try { >> bh.consume(Class.forName(name, false, >> MethodHandle.class.getClassLoader())); >> } catch (ClassNotFoundException e) { >> bh.consume(e); >> } >> } >> } >> >> @Benchmark >> public void classForNameInModule(Blackhole bh) { >> for (String name : lookedUpNames) { >> bh.consume(Class.forName(MethodHandle.class.getModule(), name)); >> } >> } >> >> @Benchmark >> public void hashSetContains(Blackhole bh) { >> for (String name : lookedUpNames) { >> bh.consume(generatedNames.contains(name)); >> } >> } >> >> @Benchmark >> public void switchStatement(Blackhole bh) { >> for (String types : lookedUpTypes) { >> bh.consume(getBMHSwitch(types)); >> } >> } >> >> static Class getBMHSwitch(String types) { >> // should be in sync with @Param generate above... >> switch (types) { >> case "LL": return Object.class; >> case "LLL": return Serializable.class; >> case "LLLL": return Iterator.class; >> case "LLLLL": return Throwable.class; >> case "LLLLLL": return String.class; >> default: return null; >> } >> } >> >> // copied from non-public LambdaForm >> static String shortenSignature(String signature) { >> // Hack to make signatures more readable when they show up in >> method names. >> final int NO_CHAR = -1, MIN_RUN = 3; >> int c0, c1 = NO_CHAR, c1reps = 0; >> StringBuilder buf = null; >> int len = signature.length(); >> if (len < MIN_RUN) return signature; >> for (int i = 0; i <= len; i++) { >> // shift in the next char: >> c0 = c1; c1 = (i == len ? NO_CHAR : signature.charAt(i)); >> if (c1 == c0) { ++c1reps; continue; } >> // shift in the next count: >> int c0reps = c1reps; c1reps = 1; >> // end of a character run >> if (c0reps < MIN_RUN) { >> if (buf != null) { >> while (--c0reps >= 0) >> buf.append((char) c0); >> } >> continue; >> } >> // found three or more in a row >> if (buf == null) >> buf = new StringBuilder().append(signature, 0, i - >> c0reps); >> buf.append((char) c0).append(c0reps); >> } >> return (buf == null) ? signature : buf.toString(); >> } >> } >> >> >> >> Regards, Peter >> >>> >>> All-in-all I lean towards moving forward with the first, simpler >>> revision of this >>> patch[1] and then evaluate if webrev.02 or a String-switch+static >>> resolve >>> as a follow-up. >>> >>> A compromise would be to keep the SpeciesLookup class introduced here >>> to allow removing all overhead in case the plugin is disabled. >>> >>> Mandy: I've not found any test (under jdk/test/tools/jlink or >>> elsewhere) which >>> has to be updated when adding a plugin like this. >>> >>> Thanks! >>> >>> /Claes >>> >>> [1] http://cr.openjdk.java.net/~redestad/8152641/webrev.01/ >> > From forax at univ-mlv.fr Wed Mar 30 11:11:21 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 30 Mar 2016 13:11:21 +0200 (CEST) Subject: RFR: 8152641: Plugin to generate BMH$Species classes ahead-of-time In-Reply-To: <56FBB014.6050002@oracle.com> References: <56F3EEAB.4090600@oracle.com> <56F50EC5.6020500@gmail.com> <56F5520D.3080205@oracle.com> <56F676CA.5000803@gmail.com> <56FB09D3.4090000@oracle.com> <56FB82FE.5010209@gmail.com> <56FB8607.8030000@gmail.com> <56FBB014.6050002@oracle.com> Message-ID: <647493225.2086628.1459336281484.JavaMail.zimbra@u-pem.fr> Hi Claes, Did you considere to use return c.asSubclass(BoundMethodHandle.class); instead of return (Class)c; to avoid the @SupressWarnings, like in generateConcreteBMHClass ? cheers, R?mi ----- Mail original ----- > De: "Claes Redestad" > ?: "Peter Levart" , "Mandy Chung" > Cc: "jigsaw-dev" , "core-libs-dev" > Envoy?: Mercredi 30 Mars 2016 12:53:08 > Objet: Re: RFR: 8152641: Plugin to generate BMH$Species classes ahead-of-time > > Hi, > > I think Class.forName(Module, String) seemed like a nice > efficiency/simplicity compromise, but there is some usage of > lambdas/method-refs in the Module lookup code, especially for exploded > modules (which get exercised during JDK build). Depending on a lambda > from code in java.lang.invoke means we fail to bootstrap. > > But hey, we're living in an encapsulated world now, and this is in > java.base, so why not go directly to the BootLoader: > > http://cr.openjdk.java.net/~redestad/8152641/webrev.03/ > > Since this is what's called from Class.forName(Module, String), the > overhead should be even smaller than in your classForNameInModule test. > > If I call this final, will you say "Reviewed"? :-) > > /Claes > > PS: The default list of types is generated in a few adhoc tests not part > of this patch. I'm considering proposing add support for generating this > list at build time. Maybe a JEP called "Build system support for > profile-guided optimizations", which could also handle > https://bugs.openjdk.java.net/browse/JDK-8150044 > > On 2016-03-30 09:53, Peter Levart wrote: > > Hi Claes, > > > > Sorry, I found a flaw in the benchmark (the regex pattern to split > > comma-separated string into substrings was wrong). What the benchmark > > did was compare the overheads of a single lookup of a longer class > > name containing commas. Here's the corrected result of overheads of 5 > > unsuccessful lookups: > > > > Benchmark (generate) (lookup) Mode Cnt > > Score Error Units > > ClassForNameBench.classForName LL,LLL,LLLL,LLLLL,LLLLLL > > LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 29627.141 ? 567.427 ns/op > > ClassForNameBench.classForNameInModule LL,LLL,LLLL,LLLLL,LLLLLL > > LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 1073.256 ? 23.794 ns/op > > ClassForNameBench.hashSetContains LL,LLL,LLLL,LLLLL,LLLLLL > > LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 33.022 ? 0.066 ns/op > > ClassForNameBench.switchStatement LL,LLL,LLLL,LLLLL,LLLLLL > > LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 38.498 ? 5.842 ns/op > > > > ...overheads are a little bigger (x5 approx.). > > > > > > Here's the corrected benchmark: > > > > > > package jdk.test; > > > > import org.openjdk.jmh.annotations.*; > > import org.openjdk.jmh.infra.Blackhole; > > > > import java.io.Serializable; > > import java.lang.invoke.MethodHandle; > > import java.util.Iterator; > > import java.util.Set; > > import java.util.concurrent.TimeUnit; > > import java.util.stream.Collectors; > > import java.util.stream.Stream; > > > > @BenchmarkMode(Mode.AverageTime) > > @Fork(value = 1, warmups = 0) > > @Warmup(iterations = 10) > > @Measurement(iterations = 10) > > @OutputTimeUnit(TimeUnit.NANOSECONDS) > > @State(Scope.Thread) > > public class ClassForNameBench { > > > > static final String BMH = "java/lang/invoke/BoundMethodHandle"; > > static final String SPECIES_PREFIX_NAME = "Species_"; > > static final String SPECIES_PREFIX_PATH = BMH + "$" + > > SPECIES_PREFIX_NAME; > > > > @Param({"LL,LLL,LLLL,LLLLL,LLLLLL"}) > > public String generate; > > > > @Param({"LLI,LLLI,LLLLI,LLLLLI,LLLLLLI"}) > > public String lookup; > > > > private String[] generatedTypes; > > private String[] lookedUpTypes; > > private Set generatedNames; > > private String[] lookedUpNames; > > > > @Setup(Level.Trial) > > public void setup() { > > generatedTypes = generate.trim().split("\\s*,\\s*"); > > lookedUpTypes = lookup.trim().split("\\s*,\\s*"); > > generatedNames = Stream.of(generatedTypes) > > .map(types -> SPECIES_PREFIX_PATH + > > shortenSignature(types)) > > .collect(Collectors.toSet()); > > lookedUpNames = Stream.of(lookedUpTypes) > > .map(types -> SPECIES_PREFIX_PATH + > > shortenSignature(types)) > > .toArray(String[]::new); > > } > > > > @Benchmark > > public void classForName(Blackhole bh) { > > for (String name : lookedUpNames) { > > try { > > bh.consume(Class.forName(name, false, > > MethodHandle.class.getClassLoader())); > > } catch (ClassNotFoundException e) { > > bh.consume(e); > > } > > } > > } > > > > @Benchmark > > public void classForNameInModule(Blackhole bh) { > > for (String name : lookedUpNames) { > > bh.consume(Class.forName(MethodHandle.class.getModule(), name)); > > } > > } > > > > @Benchmark > > public void hashSetContains(Blackhole bh) { > > for (String name : lookedUpNames) { > > bh.consume(generatedNames.contains(name)); > > } > > } > > > > @Benchmark > > public void switchStatement(Blackhole bh) { > > for (String types : lookedUpTypes) { > > bh.consume(getBMHSwitch(types)); > > } > > } > > > > static Class getBMHSwitch(String types) { > > // should be in sync with @Param generate above... > > switch (types) { > > case "LL": return Object.class; > > case "LLL": return Serializable.class; > > case "LLLL": return Iterator.class; > > case "LLLLL": return Throwable.class; > > case "LLLLLL": return String.class; > > default: return null; > > } > > } > > > > // copied from non-public LambdaForm > > static String shortenSignature(String signature) { > > // Hack to make signatures more readable when they show up in > > method names. > > final int NO_CHAR = -1, MIN_RUN = 3; > > int c0, c1 = NO_CHAR, c1reps = 0; > > StringBuilder buf = null; > > int len = signature.length(); > > if (len < MIN_RUN) return signature; > > for (int i = 0; i <= len; i++) { > > // shift in the next char: > > c0 = c1; c1 = (i == len ? NO_CHAR : signature.charAt(i)); > > if (c1 == c0) { ++c1reps; continue; } > > // shift in the next count: > > int c0reps = c1reps; c1reps = 1; > > // end of a character run > > if (c0reps < MIN_RUN) { > > if (buf != null) { > > while (--c0reps >= 0) > > buf.append((char) c0); > > } > > continue; > > } > > // found three or more in a row > > if (buf == null) > > buf = new StringBuilder().append(signature, 0, i - > > c0reps); > > buf.append((char) c0).append(c0reps); > > } > > return (buf == null) ? signature : buf.toString(); > > } > > } > > > > > > Regards, Peter > > > > > > > > On 03/30/2016 09:40 AM, Peter Levart wrote: > >> Hi Claes, > >> > >> On 03/30/2016 01:03 AM, Claes Redestad wrote: > >>> Hi Peter, Mandy, > >>> > >>> On 2016-03-26 12:47, Peter Levart wrote: > >>>> > >>>> Comparing this with proposed code from webrev: > >>>> > >>>> 493 try { > >>>> 494 return (Class >>>> BoundMethodHandle>) > >>>> 495 Class.forName("java.lang.invoke.BoundMethodHandle$Species_" + > >>>> LambdaForm.shortenSignature(types)); > >>>> 496 } catch (ClassNotFoundException cnf) { > >>>> 497 // Not pregenerated, generate the > >>>> class > >>>> 498 return > >>>> generateConcreteBMHClass(types); > >>>> 499 } > >>>> > >>>> > >>>> ...note that the function passed to CLASS_CACHE.computeIfAbsent is > >>>> executed just once per distinct 'types' argument. Even if you put > >>>> the generated switch between a call to getConcreteBMHClass and > >>>> CLASS_CACHE.computeIfAbsent, getConcreteBMHClass(String types) is > >>>> executed just once per distinct 'types' argument (except in rare > >>>> occasions when VM can not initialize the loaded class). > >>>> > >>>> In this respect a successful Class.forName() is not any worse than > >>>> static resolving. It's just that unsuccessful Class.forName() > >>>> represents some overhead for classes that are not pre-generated. So > >>>> an alternative way to get rid of that overhead is to have a HashSet > >>>> of 'types' strings for pre-generated classes at hand in order to > >>>> decide whether to call Class.forName or generateConcreteBMHClass. > >>>> > >>>> What's easier to support is another question. > >>>> > >>>> Regards, Peter > >>> > >>> to have something to compare with I built a version which, like you > >>> suggest, > >>> generates a HashSet with the set of generated classes here: > >>> > >>> http://cr.openjdk.java.net/~redestad/8152641/webrev.02/ > >>> > >>> This adds a fair bit of complexity to the plugin and requires we add > >>> a nested > >>> class in BoundMethodHandle that we can replace. Using the anonymous > >>> compute Function for this seems like the best choice for this. > >> > >> ...what I had in mind as alternative to a pregenerated class with a > >> switch was a simple textual resource file, generated by plugin, > >> read-in by BMH into a HashSet. No special-purpose class generation > >> and much less complexity for the plugin. > >> > >>> > >>> I've not been able to measure any statistical difference in real > >>> startup terms, > >>> though, and not figured out a smart way to benchmark the overhead of > >>> the > >>> CNFE in relation to the class generation (my guess it adds a > >>> fraction to the > >>> total cost) and since this adds ever so little footprint and an > >>> extra lookup to the > >>> fast path it would seem that this is the wrong trade-off to do here. > >> > >> Yes, perhaps it would be best to just use Class.forName(module, > >> className) instead. I have created a little benchmark to compare > >> overheads (just overheads) of unsuccessful lookups for pregenerated > >> classes (a situation where a BMH class is requested that has not been > >> pregenerated) and here's the result for overhead of 5 unsuccessfull > >> lookups: > >> > >> Benchmark (generate) (lookup) Mode Cnt > >> Score Error Units > >> ClassForNameBench.classForName LL,LLL,LLLL,LLLLL,LLLLLL > >> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 6800.878 ? 421.424 ns/op > >> ClassForNameBench.classForNameInModule LL,LLL,LLLL,LLLLL,LLLLLL > >> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 209.574 ? 2.114 ns/op > >> ClassForNameBench.hashSetContains LL,LLL,LLLL,LLLLL,LLLLLL > >> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 6.813 ? 0.317 ns/op > >> ClassForNameBench.switchStatement LL,LLL,LLLL,LLLLL,LLLLLL > >> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 6.601 ? 0.061 ns/op > >> > >> ...compared to runtime BMH class generation and loading this is > >> really a very minor overhead. I would just use Class.forName(module, > >> className) and reduce the complexity of the plugin. > >> > >> What do you think? > >> > >> > >> Here's the benchmark: > >> > >> package jdk.test; > >> > >> import org.openjdk.jmh.annotations.*; > >> import org.openjdk.jmh.infra.Blackhole; > >> > >> import java.io.Serializable; > >> import java.lang.invoke.MethodHandle; > >> import java.util.Iterator; > >> import java.util.Set; > >> import java.util.concurrent.TimeUnit; > >> import java.util.stream.Collectors; > >> import java.util.stream.Stream; > >> > >> @BenchmarkMode(Mode.AverageTime) > >> @Fork(value = 1, warmups = 0) > >> @Warmup(iterations = 10) > >> @Measurement(iterations = 10) > >> @OutputTimeUnit(TimeUnit.NANOSECONDS) > >> @State(Scope.Thread) > >> public class ClassForNameBench { > >> > >> static final String BMH = "java/lang/invoke/BoundMethodHandle"; > >> static final String SPECIES_PREFIX_NAME = "Species_"; > >> static final String SPECIES_PREFIX_PATH = BMH + "$" + > >> SPECIES_PREFIX_NAME; > >> > >> @Param({"LL,LLL,LLLL,LLLLL,LLLLLL"}) > >> public String generate; > >> > >> @Param({"LLI,LLLI,LLLLI,LLLLLI,LLLLLLI"}) > >> public String lookup; > >> > >> private String[] generatedTypes; > >> private String[] lookedUpTypes; > >> private Set generatedNames; > >> private String[] lookedUpNames; > >> > >> @Setup(Level.Trial) > >> public void setup() { > >> generatedTypes = generate.trim().split("\\s+,\\s+"); > >> lookedUpTypes = lookup.trim().split("\\s+,\\s+"); > >> generatedNames = Stream.of(generatedTypes) > >> .map(types -> SPECIES_PREFIX_PATH + > >> shortenSignature(types)) > >> .collect(Collectors.toSet()); > >> lookedUpNames = Stream.of(lookedUpTypes) > >> .map(types -> SPECIES_PREFIX_PATH + > >> shortenSignature(types)) > >> .toArray(String[]::new); > >> } > >> > >> @Benchmark > >> public void classForName(Blackhole bh) { > >> for (String name : lookedUpNames) { > >> try { > >> bh.consume(Class.forName(name, false, > >> MethodHandle.class.getClassLoader())); > >> } catch (ClassNotFoundException e) { > >> bh.consume(e); > >> } > >> } > >> } > >> > >> @Benchmark > >> public void classForNameInModule(Blackhole bh) { > >> for (String name : lookedUpNames) { > >> bh.consume(Class.forName(MethodHandle.class.getModule(), name)); > >> } > >> } > >> > >> @Benchmark > >> public void hashSetContains(Blackhole bh) { > >> for (String name : lookedUpNames) { > >> bh.consume(generatedNames.contains(name)); > >> } > >> } > >> > >> @Benchmark > >> public void switchStatement(Blackhole bh) { > >> for (String types : lookedUpTypes) { > >> bh.consume(getBMHSwitch(types)); > >> } > >> } > >> > >> static Class getBMHSwitch(String types) { > >> // should be in sync with @Param generate above... > >> switch (types) { > >> case "LL": return Object.class; > >> case "LLL": return Serializable.class; > >> case "LLLL": return Iterator.class; > >> case "LLLLL": return Throwable.class; > >> case "LLLLLL": return String.class; > >> default: return null; > >> } > >> } > >> > >> // copied from non-public LambdaForm > >> static String shortenSignature(String signature) { > >> // Hack to make signatures more readable when they show up in > >> method names. > >> final int NO_CHAR = -1, MIN_RUN = 3; > >> int c0, c1 = NO_CHAR, c1reps = 0; > >> StringBuilder buf = null; > >> int len = signature.length(); > >> if (len < MIN_RUN) return signature; > >> for (int i = 0; i <= len; i++) { > >> // shift in the next char: > >> c0 = c1; c1 = (i == len ? NO_CHAR : signature.charAt(i)); > >> if (c1 == c0) { ++c1reps; continue; } > >> // shift in the next count: > >> int c0reps = c1reps; c1reps = 1; > >> // end of a character run > >> if (c0reps < MIN_RUN) { > >> if (buf != null) { > >> while (--c0reps >= 0) > >> buf.append((char) c0); > >> } > >> continue; > >> } > >> // found three or more in a row > >> if (buf == null) > >> buf = new StringBuilder().append(signature, 0, i - > >> c0reps); > >> buf.append((char) c0).append(c0reps); > >> } > >> return (buf == null) ? signature : buf.toString(); > >> } > >> } > >> > >> > >> > >> Regards, Peter > >> > >>> > >>> All-in-all I lean towards moving forward with the first, simpler > >>> revision of this > >>> patch[1] and then evaluate if webrev.02 or a String-switch+static > >>> resolve > >>> as a follow-up. > >>> > >>> A compromise would be to keep the SpeciesLookup class introduced here > >>> to allow removing all overhead in case the plugin is disabled. > >>> > >>> Mandy: I've not found any test (under jdk/test/tools/jlink or > >>> elsewhere) which > >>> has to be updated when adding a plugin like this. > >>> > >>> Thanks! > >>> > >>> /Claes > >>> > >>> [1] http://cr.openjdk.java.net/~redestad/8152641/webrev.01/ > >> > > > > From georgiy.rakov at oracle.com Wed Mar 30 11:18:30 2016 From: georgiy.rakov at oracle.com (Georgiy Rakov) Date: Wed, 30 Mar 2016 14:18:30 +0300 Subject: javac accepts enums, annotations and final classes being referenced by 'uses' statement Message-ID: <56FBB606.7030000@oracle.com> Hello, currently JDK9b111 javac successfully compiles following code: a/module-info.java: module a { uses pkg.FinalClassST; uses pkg.EnumST; uses pkg.AnnotationST; } a/pkg/AnnotationST.java: package pkg; public @interface AnnotationST{} a/pkg/EnumST.java: package pkg; public enum EnumST {A,B} a/pkg/FinalClassST.java: package pkg; public final class FinalClassST{} Could you please tell if this is javac, spec or both issue that type being referenced by 'uses' statement is not checked at compile-time for ability to be a service interface. The minimized testcase is attached; in order to run it please: 1. unzip attached archive on Windows machine; 2. rename test9\test_bat to test9\test.bat; 3. modify test.bat by changing JDK_HOME variable to point to your JDK installation; 4. run test.bat. BTW: provided the type name references non existing type javac does produce compile error. Thanks, Georgiy. From claes.redestad at oracle.com Wed Mar 30 11:14:39 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 30 Mar 2016 13:14:39 +0200 Subject: RFR: 8152641: Plugin to generate BMH$Species classes ahead-of-time In-Reply-To: <647493225.2086628.1459336281484.JavaMail.zimbra@u-pem.fr> References: <56F3EEAB.4090600@oracle.com> <56F50EC5.6020500@gmail.com> <56F5520D.3080205@oracle.com> <56F676CA.5000803@gmail.com> <56FB09D3.4090000@oracle.com> <56FB82FE.5010209@gmail.com> <56FB8607.8030000@gmail.com> <56FBB014.6050002@oracle.com> <647493225.2086628.1459336281484.JavaMail.zimbra@u-pem.fr> Message-ID: <56FBB51F.2040304@oracle.com> Hi, On 2016-03-30 13:11, Remi Forax wrote: > Hi Claes, > Did you considere to use > return c.asSubclass(BoundMethodHandle.class); > instead of > return (Class)c; > to avoid the @SupressWarnings, like in generateConcreteBMHClass ? no, but it's a good cleanup. :-) Updated in-place: http://cr.openjdk.java.net/~redestad/8152641/webrev.03/ /Claes From forax at univ-mlv.fr Wed Mar 30 12:00:30 2016 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Wed, 30 Mar 2016 14:00:30 +0200 (CEST) Subject: RFR: 8152641: Plugin to generate BMH$Species classes ahead-of-time In-Reply-To: <56FBB51F.2040304@oracle.com> References: <56F3EEAB.4090600@oracle.com> <56F676CA.5000803@gmail.com> <56FB09D3.4090000@oracle.com> <56FB82FE.5010209@gmail.com> <56FB8607.8030000@gmail.com> <56FBB014.6050002@oracle.com> <647493225.2086628.1459336281484.JavaMail.zimbra@u-pem.fr> <56FBB51F.2040304@oracle.com> Message-ID: <374246915.2118211.1459339230643.JavaMail.zimbra@u-pem.fr> Patch looks Ok to me. R?mi ----- Mail original ----- > De: "Claes Redestad" > ?: "Remi Forax" > Cc: "Peter Levart" , "Mandy Chung" , "jigsaw-dev" > , "core-libs-dev" > Envoy?: Mercredi 30 Mars 2016 13:14:39 > Objet: Re: RFR: 8152641: Plugin to generate BMH$Species classes ahead-of-time > > Hi, > > On 2016-03-30 13:11, Remi Forax wrote: > > Hi Claes, > > Did you considere to use > > return c.asSubclass(BoundMethodHandle.class); > > instead of > > return (Class)c; > > to avoid the @SupressWarnings, like in generateConcreteBMHClass ? > > no, but it's a good cleanup. :-) > > Updated in-place: http://cr.openjdk.java.net/~redestad/8152641/webrev.03/ > > /Claes > > From peter.levart at gmail.com Wed Mar 30 12:21:44 2016 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 30 Mar 2016 14:21:44 +0200 Subject: RFR: 8152641: Plugin to generate BMH$Species classes ahead-of-time In-Reply-To: <56FBB014.6050002@oracle.com> References: <56F3EEAB.4090600@oracle.com> <1FE3F7A6-1C7B-4DC6-875C-E3FAEDED08F5@oracle.com> <56F50EC5.6020500@gmail.com> <56F5520D.3080205@oracle.com> <56F676CA.5000803@gmail.com> <56FB09D3.4090000@oracle.com> <56FB82FE.5010209@gmail.com> <56FB8607.8030000@gmail.com> <56FBB014.6050002@oracle.com> Message-ID: <56FBC4D8.8010603@gmail.com> Hi Claes, On 03/30/2016 12:53 PM, Claes Redestad wrote: > Hi, > > I think Class.forName(Module, String) seemed like a nice > efficiency/simplicity compromise, but there is some usage of > lambdas/method-refs in the Module lookup code, especially for exploded > modules (which get exercised during JDK build). Depending on a lambda > from code in java.lang.invoke means we fail to bootstrap. > > But hey, we're living in an encapsulated world now, and this is in > java.base, so why not go directly to the BootLoader: > > http://cr.openjdk.java.net/~redestad/8152641/webrev.03/ > > Since this is what's called from Class.forName(Module, String), the > overhead should be even smaller than in your classForNameInModule test. Good idea. > > If I call this final, will you say "Reviewed"? :-) Sorry, I don't posses the powers. :-) I could say "rEVIEWED", but... In the plugin, the input is shortened speciesTypes strings. What guarantees that they really are normalized? For example, If one specifies "LLL" as input, it will get expanded into "LLL", the generated class will have "_L3" as a name suffix, but you will pack it in the image with "_LLL.class" filename suffix. That's another reason why a method in BoundMethodHandle$Factory with the following signature: Map.Entry generateConcreteBMHClassBytes(String types); ...would be a good idea. It would return class bytes and the name of the class which you could use to derive the class filename without hardcoding the same logic in plugin and in BMH. You just move the "LambdaForm.shortenSignature(types)" from getConcreteBMHClass and className/sourceFile calculation from generateConcreteBMHClass down to generateConcreteBMHClassBytes method and change the signatures... Regards, Peter > > /Claes > > PS: The default list of types is generated in a few adhoc tests not > part of this patch. I'm considering proposing add support for > generating this list at build time. Maybe a JEP called "Build system > support for profile-guided optimizations", which could also handle > https://bugs.openjdk.java.net/browse/JDK-8150044 > > On 2016-03-30 09:53, Peter Levart wrote: >> Hi Claes, >> >> Sorry, I found a flaw in the benchmark (the regex pattern to split >> comma-separated string into substrings was wrong). What the benchmark >> did was compare the overheads of a single lookup of a longer class >> name containing commas. Here's the corrected result of overheads of 5 >> unsuccessful lookups: >> >> Benchmark (generate) (lookup) Mode Cnt >> Score Error Units >> ClassForNameBench.classForName LL,LLL,LLLL,LLLLL,LLLLLL >> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 29627.141 ? 567.427 ns/op >> ClassForNameBench.classForNameInModule LL,LLL,LLLL,LLLLL,LLLLLL >> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 1073.256 ? 23.794 ns/op >> ClassForNameBench.hashSetContains LL,LLL,LLLL,LLLLL,LLLLLL >> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 33.022 ? 0.066 ns/op >> ClassForNameBench.switchStatement LL,LLL,LLLL,LLLLL,LLLLLL >> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 38.498 ? 5.842 ns/op >> >> ...overheads are a little bigger (x5 approx.). >> >> >> Here's the corrected benchmark: >> >> >> package jdk.test; >> >> import org.openjdk.jmh.annotations.*; >> import org.openjdk.jmh.infra.Blackhole; >> >> import java.io.Serializable; >> import java.lang.invoke.MethodHandle; >> import java.util.Iterator; >> import java.util.Set; >> import java.util.concurrent.TimeUnit; >> import java.util.stream.Collectors; >> import java.util.stream.Stream; >> >> @BenchmarkMode(Mode.AverageTime) >> @Fork(value = 1, warmups = 0) >> @Warmup(iterations = 10) >> @Measurement(iterations = 10) >> @OutputTimeUnit(TimeUnit.NANOSECONDS) >> @State(Scope.Thread) >> public class ClassForNameBench { >> >> static final String BMH = "java/lang/invoke/BoundMethodHandle"; >> static final String SPECIES_PREFIX_NAME = "Species_"; >> static final String SPECIES_PREFIX_PATH = BMH + "$" + >> SPECIES_PREFIX_NAME; >> >> @Param({"LL,LLL,LLLL,LLLLL,LLLLLL"}) >> public String generate; >> >> @Param({"LLI,LLLI,LLLLI,LLLLLI,LLLLLLI"}) >> public String lookup; >> >> private String[] generatedTypes; >> private String[] lookedUpTypes; >> private Set generatedNames; >> private String[] lookedUpNames; >> >> @Setup(Level.Trial) >> public void setup() { >> generatedTypes = generate.trim().split("\\s*,\\s*"); >> lookedUpTypes = lookup.trim().split("\\s*,\\s*"); >> generatedNames = Stream.of(generatedTypes) >> .map(types -> SPECIES_PREFIX_PATH + >> shortenSignature(types)) >> .collect(Collectors.toSet()); >> lookedUpNames = Stream.of(lookedUpTypes) >> .map(types -> SPECIES_PREFIX_PATH + >> shortenSignature(types)) >> .toArray(String[]::new); >> } >> >> @Benchmark >> public void classForName(Blackhole bh) { >> for (String name : lookedUpNames) { >> try { >> bh.consume(Class.forName(name, false, >> MethodHandle.class.getClassLoader())); >> } catch (ClassNotFoundException e) { >> bh.consume(e); >> } >> } >> } >> >> @Benchmark >> public void classForNameInModule(Blackhole bh) { >> for (String name : lookedUpNames) { >> bh.consume(Class.forName(MethodHandle.class.getModule(), name)); >> } >> } >> >> @Benchmark >> public void hashSetContains(Blackhole bh) { >> for (String name : lookedUpNames) { >> bh.consume(generatedNames.contains(name)); >> } >> } >> >> @Benchmark >> public void switchStatement(Blackhole bh) { >> for (String types : lookedUpTypes) { >> bh.consume(getBMHSwitch(types)); >> } >> } >> >> static Class getBMHSwitch(String types) { >> // should be in sync with @Param generate above... >> switch (types) { >> case "LL": return Object.class; >> case "LLL": return Serializable.class; >> case "LLLL": return Iterator.class; >> case "LLLLL": return Throwable.class; >> case "LLLLLL": return String.class; >> default: return null; >> } >> } >> >> // copied from non-public LambdaForm >> static String shortenSignature(String signature) { >> // Hack to make signatures more readable when they show up in >> method names. >> final int NO_CHAR = -1, MIN_RUN = 3; >> int c0, c1 = NO_CHAR, c1reps = 0; >> StringBuilder buf = null; >> int len = signature.length(); >> if (len < MIN_RUN) return signature; >> for (int i = 0; i <= len; i++) { >> // shift in the next char: >> c0 = c1; c1 = (i == len ? NO_CHAR : signature.charAt(i)); >> if (c1 == c0) { ++c1reps; continue; } >> // shift in the next count: >> int c0reps = c1reps; c1reps = 1; >> // end of a character run >> if (c0reps < MIN_RUN) { >> if (buf != null) { >> while (--c0reps >= 0) >> buf.append((char) c0); >> } >> continue; >> } >> // found three or more in a row >> if (buf == null) >> buf = new StringBuilder().append(signature, 0, i - >> c0reps); >> buf.append((char) c0).append(c0reps); >> } >> return (buf == null) ? signature : buf.toString(); >> } >> } >> >> >> Regards, Peter >> >> >> >> On 03/30/2016 09:40 AM, Peter Levart wrote: >>> Hi Claes, >>> >>> On 03/30/2016 01:03 AM, Claes Redestad wrote: >>>> Hi Peter, Mandy, >>>> >>>> On 2016-03-26 12:47, Peter Levart wrote: >>>>> >>>>> Comparing this with proposed code from webrev: >>>>> >>>>> 493 try { >>>>> 494 return (Class>>>> BoundMethodHandle>) >>>>> 495 Class.forName("java.lang.invoke.BoundMethodHandle$Species_" + >>>>> LambdaForm.shortenSignature(types)); >>>>> 496 } catch (ClassNotFoundException cnf) { >>>>> 497 // Not pregenerated, generate the >>>>> class >>>>> 498 return >>>>> generateConcreteBMHClass(types); >>>>> 499 } >>>>> >>>>> >>>>> ...note that the function passed to CLASS_CACHE.computeIfAbsent is >>>>> executed just once per distinct 'types' argument. Even if you put >>>>> the generated switch between a call to getConcreteBMHClass and >>>>> CLASS_CACHE.computeIfAbsent, getConcreteBMHClass(String types) is >>>>> executed just once per distinct 'types' argument (except in rare >>>>> occasions when VM can not initialize the loaded class). >>>>> >>>>> In this respect a successful Class.forName() is not any worse than >>>>> static resolving. It's just that unsuccessful Class.forName() >>>>> represents some overhead for classes that are not pre-generated. >>>>> So an alternative way to get rid of that overhead is to have a >>>>> HashSet of 'types' strings for pre-generated classes at hand in >>>>> order to decide whether to call Class.forName or >>>>> generateConcreteBMHClass. >>>>> >>>>> What's easier to support is another question. >>>>> >>>>> Regards, Peter >>>> >>>> to have something to compare with I built a version which, like you >>>> suggest, >>>> generates a HashSet with the set of generated classes here: >>>> >>>> http://cr.openjdk.java.net/~redestad/8152641/webrev.02/ >>>> >>>> This adds a fair bit of complexity to the plugin and requires we >>>> add a nested >>>> class in BoundMethodHandle that we can replace. Using the anonymous >>>> compute Function for this seems like the best choice for this. >>> >>> ...what I had in mind as alternative to a pregenerated class with a >>> switch was a simple textual resource file, generated by plugin, >>> read-in by BMH into a HashSet. No special-purpose class generation >>> and much less complexity for the plugin. >>> >>>> >>>> I've not been able to measure any statistical difference in real >>>> startup terms, >>>> though, and not figured out a smart way to benchmark the overhead >>>> of the >>>> CNFE in relation to the class generation (my guess it adds a >>>> fraction to the >>>> total cost) and since this adds ever so little footprint and an >>>> extra lookup to the >>>> fast path it would seem that this is the wrong trade-off to do here. >>> >>> Yes, perhaps it would be best to just use Class.forName(module, >>> className) instead. I have created a little benchmark to compare >>> overheads (just overheads) of unsuccessful lookups for pregenerated >>> classes (a situation where a BMH class is requested that has not >>> been pregenerated) and here's the result for overhead of 5 >>> unsuccessfull lookups: >>> >>> Benchmark (generate) (lookup) Mode Cnt >>> Score Error Units >>> ClassForNameBench.classForName LL,LLL,LLLL,LLLLL,LLLLLL >>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 6800.878 ? 421.424 ns/op >>> ClassForNameBench.classForNameInModule LL,LLL,LLLL,LLLLL,LLLLLL >>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 209.574 ? 2.114 ns/op >>> ClassForNameBench.hashSetContains LL,LLL,LLLL,LLLLL,LLLLLL >>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 6.813 ? 0.317 ns/op >>> ClassForNameBench.switchStatement LL,LLL,LLLL,LLLLL,LLLLLL >>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 6.601 ? 0.061 ns/op >>> >>> ...compared to runtime BMH class generation and loading this is >>> really a very minor overhead. I would just use Class.forName(module, >>> className) and reduce the complexity of the plugin. >>> >>> What do you think? >>> >>> >>> Here's the benchmark: >>> >>> package jdk.test; >>> >>> import org.openjdk.jmh.annotations.*; >>> import org.openjdk.jmh.infra.Blackhole; >>> >>> import java.io.Serializable; >>> import java.lang.invoke.MethodHandle; >>> import java.util.Iterator; >>> import java.util.Set; >>> import java.util.concurrent.TimeUnit; >>> import java.util.stream.Collectors; >>> import java.util.stream.Stream; >>> >>> @BenchmarkMode(Mode.AverageTime) >>> @Fork(value = 1, warmups = 0) >>> @Warmup(iterations = 10) >>> @Measurement(iterations = 10) >>> @OutputTimeUnit(TimeUnit.NANOSECONDS) >>> @State(Scope.Thread) >>> public class ClassForNameBench { >>> >>> static final String BMH = "java/lang/invoke/BoundMethodHandle"; >>> static final String SPECIES_PREFIX_NAME = "Species_"; >>> static final String SPECIES_PREFIX_PATH = BMH + "$" + >>> SPECIES_PREFIX_NAME; >>> >>> @Param({"LL,LLL,LLLL,LLLLL,LLLLLL"}) >>> public String generate; >>> >>> @Param({"LLI,LLLI,LLLLI,LLLLLI,LLLLLLI"}) >>> public String lookup; >>> >>> private String[] generatedTypes; >>> private String[] lookedUpTypes; >>> private Set generatedNames; >>> private String[] lookedUpNames; >>> >>> @Setup(Level.Trial) >>> public void setup() { >>> generatedTypes = generate.trim().split("\\s+,\\s+"); >>> lookedUpTypes = lookup.trim().split("\\s+,\\s+"); >>> generatedNames = Stream.of(generatedTypes) >>> .map(types -> SPECIES_PREFIX_PATH + >>> shortenSignature(types)) >>> .collect(Collectors.toSet()); >>> lookedUpNames = Stream.of(lookedUpTypes) >>> .map(types -> SPECIES_PREFIX_PATH + >>> shortenSignature(types)) >>> .toArray(String[]::new); >>> } >>> >>> @Benchmark >>> public void classForName(Blackhole bh) { >>> for (String name : lookedUpNames) { >>> try { >>> bh.consume(Class.forName(name, false, >>> MethodHandle.class.getClassLoader())); >>> } catch (ClassNotFoundException e) { >>> bh.consume(e); >>> } >>> } >>> } >>> >>> @Benchmark >>> public void classForNameInModule(Blackhole bh) { >>> for (String name : lookedUpNames) { >>> bh.consume(Class.forName(MethodHandle.class.getModule(), name)); >>> } >>> } >>> >>> @Benchmark >>> public void hashSetContains(Blackhole bh) { >>> for (String name : lookedUpNames) { >>> bh.consume(generatedNames.contains(name)); >>> } >>> } >>> >>> @Benchmark >>> public void switchStatement(Blackhole bh) { >>> for (String types : lookedUpTypes) { >>> bh.consume(getBMHSwitch(types)); >>> } >>> } >>> >>> static Class getBMHSwitch(String types) { >>> // should be in sync with @Param generate above... >>> switch (types) { >>> case "LL": return Object.class; >>> case "LLL": return Serializable.class; >>> case "LLLL": return Iterator.class; >>> case "LLLLL": return Throwable.class; >>> case "LLLLLL": return String.class; >>> default: return null; >>> } >>> } >>> >>> // copied from non-public LambdaForm >>> static String shortenSignature(String signature) { >>> // Hack to make signatures more readable when they show up >>> in method names. >>> final int NO_CHAR = -1, MIN_RUN = 3; >>> int c0, c1 = NO_CHAR, c1reps = 0; >>> StringBuilder buf = null; >>> int len = signature.length(); >>> if (len < MIN_RUN) return signature; >>> for (int i = 0; i <= len; i++) { >>> // shift in the next char: >>> c0 = c1; c1 = (i == len ? NO_CHAR : signature.charAt(i)); >>> if (c1 == c0) { ++c1reps; continue; } >>> // shift in the next count: >>> int c0reps = c1reps; c1reps = 1; >>> // end of a character run >>> if (c0reps < MIN_RUN) { >>> if (buf != null) { >>> while (--c0reps >= 0) >>> buf.append((char) c0); >>> } >>> continue; >>> } >>> // found three or more in a row >>> if (buf == null) >>> buf = new StringBuilder().append(signature, 0, i - >>> c0reps); >>> buf.append((char) c0).append(c0reps); >>> } >>> return (buf == null) ? signature : buf.toString(); >>> } >>> } >>> >>> >>> >>> Regards, Peter >>> >>>> >>>> All-in-all I lean towards moving forward with the first, simpler >>>> revision of this >>>> patch[1] and then evaluate if webrev.02 or a String-switch+static >>>> resolve >>>> as a follow-up. >>>> >>>> A compromise would be to keep the SpeciesLookup class introduced here >>>> to allow removing all overhead in case the plugin is disabled. >>>> >>>> Mandy: I've not found any test (under jdk/test/tools/jlink or >>>> elsewhere) which >>>> has to be updated when adding a plugin like this. >>>> >>>> Thanks! >>>> >>>> /Claes >>>> >>>> [1] http://cr.openjdk.java.net/~redestad/8152641/webrev.01/ >>> >> > From russell.gold at oracle.com Wed Mar 30 12:28:36 2016 From: russell.gold at oracle.com (Russell Gold) Date: Wed, 30 Mar 2016 08:28:36 -0400 Subject: modulepath and classpath mixture In-Reply-To: References: <56CC57A1.2050109@oracle.com> <56F2440A.7010505@oracle.com> <56F2914C.3030706@oracle.com> <56F2B3DA.402@oracle.com> <1228911717.349701.1459160027285.JavaMail.zimbra@u-pem.fr> <0CC4E4A6-4152-4BB0-BB42-B9E284540BB6@oracle.com> Message-ID: <6FB0B05A-6850-42F4-A6A3-42B7486CCDAA@oracle.com> Hi Paul, Could you explain? What kind of code do you mean cannot access it? And what do you mean by ?a split package situation?? From a conversation I had with Alan, earlier in this thread: > On Mar 23, 2016, at 11:42 AM, Alan Bateman wrote: > > On 23/03/2016 14:15, Russell Gold wrote: >> Here are my assumptions, which you can correct. >> >> 1. A jar or classes directory placed on a class path are treated as part of the unnamed module > Yes So if the tests and main code are both in directories, which they have been up to now in Maven, why would there be a problem? Both would be in the unnamed module and able to access one another. - Russ > On Mar 29, 2016, at 10:47 PM, Paul Benedict wrote: > > Russell, when you drop a jar on the classpath, module code will not be able to access it in a split package situation. That's the big barrier here. Maven test projects are typically written with the same package shared with the "main" code. > > Cheers, > Paul > > On Tue, Mar 29, 2016 at 11:33 AM, Russell Gold > wrote: > Hi Stephen, > > Why do you need any kind of friend access? > > It seems to me that this is making things harder than they need to be. The tests can simply run with the production code on the class path, and then there are no module issues at all. > > I think a larger problem is that you can do what I just said with the jars, even a jar which has been designated as a module by virtue of having a module-info.class in it. That means that, when users are up taking jars, they are not prevented from accessing module internals. They can put the jars on the module path, of course, but they can still use them on the class path! > > - Russ > > > > > On 28 March 2016 at 11:13, Remi Forax > wrote: > >> Hi Stephen, Hi all, > >> I think that delivering tests as a separated module is a bad idea. > >> > >> I see that from the point of a developer, seeing the code and the test as different modules can be attractive because everything seems to be put at the right place but there is a big drawback. Because modules are reified at runtime, it means that the runtime environment of the tests will be different from the production environment. > > > > This last sentence doesn't make sense to me - tests are not run in a > > production environment. > > > > Tests have all the qualities of modules - code, dependencies, > > compilation phase, deployment. The only special part is the need for > > special "friend-like" access, which Jigsaw already has for other cases > > (the export...to clause). > > > > Put simply, I consider that module = > > deployment-artifact-with-dependencies. With that mental model, putting > > tests inside the module is just not acceptable, because tests should > > not be deployed with the main application and they have different > > dependencies. If we disagree that module = > > deployment-artifact-with-dependencies, then perhaps we have bigger > > problems to solve here. > > > > Stephen > > (And to Paul Benedict, the classpath is going to die over time, so any > > solution that uses that is flawed IMO). > > > > > >> So as Alan said, from the jigsaw point of view at runtime, the tests and the code should be in the same module. > >> > >> So the building tools have to come with a way to support to have 2 different module-info.java in two different folders and package them as one module, > >> maybe javac should help by providing a way to merge 2 module-info at compile time. > >> > >> R?mi > >> > >> ----- Mail original ----- > >>> De: "Alan Bateman" > > >>> ?: "Stephen Colebourne" >, "jigsaw-dev" > > >>> Envoy?: Mercredi 23 Mars 2016 16:18:50 > >>> Objet: Re: modulepath and classpath mixture > >>> > >>> > >>> On 23/03/2016 14:42, Stephen Colebourne wrote: > >>>> : > >>>> > >>>> I don't particularly care what the mechanism is for this, but at the > >>>> requirements level: > >>>> - there are two modules - main and test > >>>> - each has its own source tree > >>>> - each has its own dependencies > >>>> - each is released separately > >>>> - each could be hosted on a central repo > >>>> - the test module needs to be able to contain the same packages as the > >>>> main module > >>>> - the test module needs to be able to invoke package-scoped code in > >>>> the same package in the main module > >>>> > >>>> To clarify further consider 4 modules, A, B, A-test and B-test where B > >>>> depends on A. Module A-test may have a method foo() that uses package > >>>> scope to access something in A. Module B-test will depend on A-test > >>>> and rely on foo() to get access to that internal object. > >>> To your list, I would add the ability to make use of testing frameworks > >>> like TestNG and JUnit. > >>> > >>> In any case, and as things currently stand, you've got most of the > >>> above. One differences is that the tests are not a separate module, they > >>> are instead compiled and run in a way that patches the main module. The > >>> second difference is that they don't have their own module declaration, > >>> instead the compilation or run augments the dependences with any > >>> additional dependences that the tests have. As I said, if they tools > >>> makes it easy then I don't think it's too bad. > >>> > >>>> > >>>> (Note that I view the thread discussion of > >>>> references to test classes on the classpath as another hack. > >>>> > >>> Packages can't be split between modules and classpath so there is no > >>> support for that. > >>> > >>> -Alan > >>> > > From Alan.Bateman at oracle.com Wed Mar 30 13:09:00 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 30 Mar 2016 14:09:00 +0100 Subject: Jigsaw + Web Start In-Reply-To: <956263C2-5958-4E15-8D07-5F9D92A1D259@yahoo.com> References: <59A16BCA-975A-413D-A46C-F93F88704035@yahoo.com> <56FA4D67.2010705@oracle.com> <56FA55D0.1010503@oracle.com> <956263C2-5958-4E15-8D07-5F9D92A1D259@yahoo.com> Message-ID: <56FBCFEC.7070809@oracle.com> On 29/03/2016 11:30, Robert Gibson wrote: > : > Like I said, we will get around to rewriting what absolutely needs to be tweaked where we can, but being able to use the escape hatch like a command-line app (along with fixes for 8152838 and 8152839) will allow us to continue our testing. > > I've created JDK-8153077 to look into whether -XaddExports could be allowed in the JNLP java-vm-args attribute. It mostly seems consideration from a security perspective. -Alan From felix.yang at oracle.com Wed Mar 30 13:39:06 2016 From: felix.yang at oracle.com (Felix Yang) Date: Wed, 30 Mar 2016 21:39:06 +0800 Subject: RFR 8141609: Need test for jrtfs that runs on JDK 8 to target a JDK 9 image In-Reply-To: <56D7EC31.5080701@oracle.com> References: <56CBD497.9090609@oracle.com> <56CC6F5A.5090901@oracle.com> <56CC80A6.9020401@oracle.com> <56CEB135.2070005@oracle.com> <56CED599.6060307@oracle.com> <56D52CE2.9060107@oracle.com> <56D54DD8.5060503@oracle.com> <56D7EC31.5080701@oracle.com> Message-ID: <56FBD6FA.1090802@oracle.com> Hi all, renamed the test to distinguish with other jrt fs tests and also fixed some misc issues. New webrev: http://cr.openjdk.java.net/~xiaofeya/8141609/webrev.03/ Thanks, Felix On 2016/3/3 15:48, Felix Yang wrote: > Hi Alan and Sundar, > please review the new webrev. Simplified the test app as discussed. > http://cr.openjdk.java.net/~xiaofeya/8141609/webrev.02/ > > Thanks, > Felix > On 2016/3/1 16:07, Alan Bateman wrote: >> >> >> On 01/03/2016 05:47, Felix Yang wrote: >>> Hi Alan, >>> please review the new webrev: >>> http://cr.openjdk.java.net/~xiaofeya/8141609/webrev.02/ >>> >>> Major changes: >>> 1. remove checking for 'java.version' in JrtfsTestMain and add new >>> check for 'release' file >>> 2. In order to avoid dup tests with Basic.java, add new >>> BaseTest.java, which is a plain java app rather than testng tests. >>> As stated before, only moved those tests more related with >>> 'functionality', not contents. >>> >> This refactors the main unit test for jrtfs and means it can't use >> newer APIs or language features. I'm interested in Sundar's view on >> this but I think I would prefer to need to keep the test separate so >> that it can compile to -target 8. Also I assume it just needs to do a >> few sanity checks, like walk the file system. Once we have something >> simple in place then we can add tests to it if needed. >> >> -Alan > From sundararajan.athijegannathan at oracle.com Wed Mar 30 13:41:27 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 30 Mar 2016 19:11:27 +0530 Subject: RFR 8141609: Need test for jrtfs that runs on JDK 8 to target a JDK 9 image In-Reply-To: <56FBD6FA.1090802@oracle.com> References: <56CBD497.9090609@oracle.com> <56CC6F5A.5090901@oracle.com> <56CC80A6.9020401@oracle.com> <56CEB135.2070005@oracle.com> <56CED599.6060307@oracle.com> <56D52CE2.9060107@oracle.com> <56D54DD8.5060503@oracle.com> <56D7EC31.5080701@oracle.com> <56FBD6FA.1090802@oracle.com> Message-ID: <56FBD787.4020302@oracle.com> +1 -Sundar On 3/30/2016 7:09 PM, Felix Yang wrote: > Hi all, > renamed the test to distinguish with other jrt fs tests and also > fixed some misc issues. > New webrev: http://cr.openjdk.java.net/~xiaofeya/8141609/webrev.03/ > > Thanks, > Felix > On 2016/3/3 15:48, Felix Yang wrote: >> Hi Alan and Sundar, >> please review the new webrev. Simplified the test app as discussed. >> http://cr.openjdk.java.net/~xiaofeya/8141609/webrev.02/ >> >> Thanks, >> Felix >> On 2016/3/1 16:07, Alan Bateman wrote: >>> >>> >>> On 01/03/2016 05:47, Felix Yang wrote: >>>> Hi Alan, >>>> please review the new webrev: >>>> http://cr.openjdk.java.net/~xiaofeya/8141609/webrev.02/ >>>> >>>> Major changes: >>>> 1. remove checking for 'java.version' in JrtfsTestMain and add new >>>> check for 'release' file >>>> 2. In order to avoid dup tests with Basic.java, add new >>>> BaseTest.java, which is a plain java app rather than testng tests. >>>> As stated before, only moved those tests more related with >>>> 'functionality', not contents. >>>> >>> This refactors the main unit test for jrtfs and means it can't use >>> newer APIs or language features. I'm interested in Sundar's view on >>> this but I think I would prefer to need to keep the test separate so >>> that it can compile to -target 8. Also I assume it just needs to do >>> a few sanity checks, like walk the file system. Once we have >>> something simple in place then we can add tests to it if needed. >>> >>> -Alan >> > From Alan.Bateman at oracle.com Wed Mar 30 13:45:03 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 30 Mar 2016 14:45:03 +0100 Subject: modulepath and classpath mixture In-Reply-To: <6FB0B05A-6850-42F4-A6A3-42B7486CCDAA@oracle.com> References: <56CC57A1.2050109@oracle.com> <56F2440A.7010505@oracle.com> <56F2914C.3030706@oracle.com> <56F2B3DA.402@oracle.com> <1228911717.349701.1459160027285.JavaMail.zimbra@u-pem.fr> <0CC4E4A6-4152-4BB0-BB42-B9E284540BB6@oracle.com> <6FB0B05A-6850-42F4-A6A3-42B7486CCDAA@oracle.com> Message-ID: <56FBD85F.6070103@oracle.com> On 30/03/2016 13:28, Russell Gold wrote: > : > > > So if the tests and main code are both in directories, which they have been up to now in Maven, why would there be a problem? Both would be in the unnamed module and able to access one another. > There shouldn't any issue there, it should just work as it has always done. The thread here has meandered a bit but I think the scenario under discussion is tests for a module that need to nestmate with the module under test. The tests are in their own test tree. The tests are compiled separately from the module they test and may have additional dependences (such as on TestNG or JUnit for example). When compiling or running then the tests need to access public types in non-exported packages and maybe package private members too. The support for this has been in jake for a long time but involves command line options that many developers or build environments won't immediately grok. In particular the tests have to be compiled "as if" they augment the already compiled module - that is what javac -Xmodule is about. There is no need to co-locate source files or class files of course. When run then the -Xpatch option is what brings the tests and the module classes together. If we get the tools right then most developers won't ever see this of course. One other thing to say that we've already been through some of this with the JDK tests. The jtreg test harness that we use for the JDK tests has been updated (thanks to Jon Gibbons) with useful support for modules [1]. It's enough for us to write tests that use JDK-internal APIs or write tests that nestmate with types in system modules so that they get access to package private type or public types in non-exported packages. It has rudimentary support for user modules too. Additional dependences are still an issue but our tests don't require additional dependences beyond TestNG. The test harness employs a bit of hackery to get things done, important when starting out, but I expect will go away in time. -Alan. [1] http://hg.openjdk.java.net/code-tools/jtreg/raw-file/tip/src/share/doc/javatest/regtest/tag-spec.html From robbiexgibson at yahoo.com Wed Mar 30 13:49:40 2016 From: robbiexgibson at yahoo.com (Robert Gibson) Date: Wed, 30 Mar 2016 15:49:40 +0200 Subject: Jigsaw + Web Start In-Reply-To: <56FBCFEC.7070809@oracle.com> References: <59A16BCA-975A-413D-A46C-F93F88704035@yahoo.com> <56FA4D67.2010705@oracle.com> <56FA55D0.1010503@oracle.com> <956263C2-5958-4E15-8D07-5F9D92A1D259@yahoo.com> <56FBCFEC.7070809@oracle.com> Message-ID: <4685ECBB-3D1E-4821-B255-C942A9923C3E@yahoo.com> > On 30 Mar 2016, at 15:09, Alan Bateman wrote: > > > >> On 29/03/2016 11:30, Robert Gibson wrote: >> : >> Like I said, we will get around to rewriting what absolutely needs to be tweaked where we can, but being able to use the escape hatch like a command-line app (along with fixes for 8152838 and 8152839) will allow us to continue our testing. > I've created JDK-8153077 to look into whether -XaddExports could be allowed in the JNLP java-vm-args attribute. It mostly seems consideration from a security perspective. > > -Alan Thanks Alan. From Alan.Bateman at oracle.com Wed Mar 30 13:49:44 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 30 Mar 2016 14:49:44 +0100 Subject: RFR 8141609: Need test for jrtfs that runs on JDK 8 to target a JDK 9 image In-Reply-To: <56FBD6FA.1090802@oracle.com> References: <56CBD497.9090609@oracle.com> <56CC6F5A.5090901@oracle.com> <56CC80A6.9020401@oracle.com> <56CEB135.2070005@oracle.com> <56CED599.6060307@oracle.com> <56D52CE2.9060107@oracle.com> <56D54DD8.5060503@oracle.com> <56D7EC31.5080701@oracle.com> <56FBD6FA.1090802@oracle.com> Message-ID: <56FBD978.4050708@oracle.com> On 30/03/2016 14:39, Felix Yang wrote: > Hi all, > renamed the test to distinguish with other jrt fs tests and also > fixed some misc issues. > New webrev: http://cr.openjdk.java.net/~xiaofeya/8141609/webrev.03/ This looks good. A minor nit is that it compiles to the bin directory, shouldn't that be "classes"? -Alan From alan.bateman at oracle.com Wed Mar 30 14:03:55 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 30 Mar 2016 14:03:55 +0000 Subject: hg: jigsaw/jake/jdk: 5 new changesets Message-ID: <201603301403.u2UE3u3d004292@aojmv0008.oracle.com> Changeset: 110effbd2dd5 Author: alanb Date: 2016-03-30 09:33 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/110effbd2dd5 Improve usage message for java -m ! src/java.base/share/classes/sun/launcher/resources/launcher.properties Changeset: c0067fe155ef Author: alanb Date: 2016-03-30 12:18 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c0067fe155ef Refactor module hashes ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java ! src/java.base/share/classes/java/lang/module/ModuleInfo.java ! src/java.base/share/classes/java/lang/module/ModuleReference.java ! src/java.base/share/classes/java/lang/module/ModuleReferences.java ! src/java.base/share/classes/java/lang/module/Resolver.java ! src/java.base/share/classes/jdk/internal/module/ClassFileAttributes.java - src/java.base/share/classes/jdk/internal/module/Hasher.java + src/java.base/share/classes/jdk/internal/module/ModuleHashes.java ! src/java.base/share/classes/jdk/internal/module/ModuleInfoExtender.java ! src/jdk.jartool/share/classes/sun/tools/jar/Main.java ! src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java ! test/tools/jar/modularJar/src/bar/jdk/test/bar/Bar.java Changeset: b01d645f1530 Author: alanb Date: 2016-03-30 12:24 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b01d645f1530 uses/provides checks not applicable to automatic modules ! src/java.base/share/classes/java/lang/module/Resolver.java Changeset: bed56749ff3d Author: alanb Date: 2016-03-30 14:53 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/bed56749ff3d Allow dynamic modules to export to parent layers ! src/java.base/share/classes/java/lang/reflect/Layer.java ! src/java.base/share/classes/java/lang/reflect/Module.java Changeset: f7189ebd8e32 Author: alanb Date: 2016-03-30 14:53 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f7189ebd8e32 Merge From scolebourne at joda.org Wed Mar 30 14:03:38 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 30 Mar 2016 15:03:38 +0100 Subject: modulepath and classpath mixture In-Reply-To: <56FBD85F.6070103@oracle.com> References: <56CC57A1.2050109@oracle.com> <56F2440A.7010505@oracle.com> <56F2914C.3030706@oracle.com> <56F2B3DA.402@oracle.com> <1228911717.349701.1459160027285.JavaMail.zimbra@u-pem.fr> <0CC4E4A6-4152-4BB0-BB42-B9E284540BB6@oracle.com> <6FB0B05A-6850-42F4-A6A3-42B7486CCDAA@oracle.com> <56FBD85F.6070103@oracle.com> Message-ID: On 30 March 2016 at 14:45, Alan Bateman wrote: > The thread here has meandered a bit but I think the scenario under > discussion is tests for a module that need to nestmate with the module under > test. The tests are in their own test tree. The tests are compiled > separately from the module they test and may have additional dependences > (such as on TestNG or JUnit for example). When compiling or running then the > tests need to access public types in non-exported packages and maybe package > private members too. Yes, plus there is a need for one set of tests to depend on another set of tests - ie. tests can be an artifact. > The support for this has been in jake for a long time > but involves command line options that many developers or build environments > won't immediately grok. In particular the tests have to be compiled "as if" > they augment the already compiled module - that is what javac -Xmodule is > about. There is no need to co-locate source files or class files of course. > When run then the -Xpatch option is what brings the tests and the module > classes together. If we get the tools right then most developers won't ever > see this of course. This is perhaps a solution that works, but it comes across as highly esoteric. Two different command line flags, augmenting/patching modules. What I see is a nightmare to explain. And while tools can make things easy, it is inadvisable for the design for running something as basic as tests to be so complex that it cannot practically be done without tools. What I see as a better solution is the same approach as I argued for with optional dependencies - enhancing the syntax of module-info.java to avoid the need for command line flags Stephen From alan.bateman at oracle.com Wed Mar 30 14:04:04 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 30 Mar 2016 14:04:04 +0000 Subject: hg: jigsaw/jake/jaxp: Translet modules can be in their own layer Message-ID: <201603301404.u2UE44vS004406@aojmv0008.oracle.com> Changeset: 0321dee1f2fb Author: alanb Date: 2016-03-30 14:52 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/0321dee1f2fb Translet modules can be in their own layer ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java From felix.yang at oracle.com Wed Mar 30 14:11:39 2016 From: felix.yang at oracle.com (Felix Yang) Date: Wed, 30 Mar 2016 22:11:39 +0800 Subject: RFR 8141609: Need test for jrtfs that runs on JDK 8 to target a JDK 9 image In-Reply-To: <56FBD978.4050708@oracle.com> References: <56CBD497.9090609@oracle.com> <56CC6F5A.5090901@oracle.com> <56CC80A6.9020401@oracle.com> <56CEB135.2070005@oracle.com> <56CED599.6060307@oracle.com> <56D52CE2.9060107@oracle.com> <56D54DD8.5060503@oracle.com> <56D7EC31.5080701@oracle.com> <56FBD6FA.1090802@oracle.com> <56FBD978.4050708@oracle.com> Message-ID: <56FBDE9B.4020901@oracle.com> Hi Alan, fixed "bin" to "classes". By the way, I need a sponsor for this change. Webrev: http://cr.openjdk.java.net/~xiaofeya/8141609/webrev.04/ Thanks, Felix On 2016/3/30 21:49, Alan Bateman wrote: > > > On 30/03/2016 14:39, Felix Yang wrote: >> Hi all, >> renamed the test to distinguish with other jrt fs tests and also >> fixed some misc issues. >> New webrev: http://cr.openjdk.java.net/~xiaofeya/8141609/webrev.03/ > This looks good. A minor nit is that it compiles to the bin directory, > shouldn't that be "classes"? > > -Alan From forax at univ-mlv.fr Wed Mar 30 14:12:59 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 30 Mar 2016 16:12:59 +0200 (CEST) Subject: modulepath and classpath mixture In-Reply-To: <56FBD85F.6070103@oracle.com> References: <56F2B3DA.402@oracle.com> <1228911717.349701.1459160027285.JavaMail.zimbra@u-pem.fr> <0CC4E4A6-4152-4BB0-BB42-B9E284540BB6@oracle.com> <6FB0B05A-6850-42F4-A6A3-42B7486CCDAA@oracle.com> <56FBD85F.6070103@oracle.com> Message-ID: <583721482.2221663.1459347179231.JavaMail.zimbra@u-pem.fr> Alan, Jon, i think javac -Xmodule should merge the module-info.java from the existing module and the one declared in the directory, with the current semantics of the module-info, merging of modules is easy and with no corner cases, so for testing, the test will be able to declare their own dependencies inside their own module-info.java. Proposed semantics for merging, - do the union of the required modules - if one required module is required publicly, it will be required publicly. - do the union of the exported packages - if one exported package is restricted, do the union of the restriction - do the union of the uses. - do the union of the provides. so merging two modules is symmetric and will always succeed. R?mi ----- Mail original ----- > De: "Alan Bateman" > ?: "Russell Gold" > Cc: "jigsaw-dev" > Envoy?: Mercredi 30 Mars 2016 15:45:03 > Objet: Re: modulepath and classpath mixture > > On 30/03/2016 13:28, Russell Gold wrote: > > : > > > > > > So if the tests and main code are both in directories, which they have been > > up to now in Maven, why would there be a problem? Both would be in the > > unnamed module and able to access one another. > > > There shouldn't any issue there, it should just work as it has always done. > > The thread here has meandered a bit but I think the scenario under > discussion is tests for a module that need to nestmate with the module > under test. The tests are in their own test tree. The tests are compiled > separately from the module they test and may have additional dependences > (such as on TestNG or JUnit for example). When compiling or running then > the tests need to access public types in non-exported packages and maybe > package private members too. The support for this has been in jake for a > long time but involves command line options that many developers or > build environments won't immediately grok. In particular the tests have > to be compiled "as if" they augment the already compiled module - that > is what javac -Xmodule is about. There is no need to co-locate source > files or class files of course. When run then the -Xpatch option is what > brings the tests and the module classes together. If we get the tools > right then most developers won't ever see this of course. > > One other thing to say that we've already been through some of this with > the JDK tests. The jtreg test harness that we use for the JDK tests has > been updated (thanks to Jon Gibbons) with useful support for modules > [1]. It's enough for us to write tests that use JDK-internal APIs or > write tests that nestmate with types in system modules so that they get > access to package private type or public types in non-exported packages. > It has rudimentary support for user modules too. Additional dependences > are still an issue but our tests don't require additional dependences > beyond TestNG. The test harness employs a bit of hackery to get things > done, important when starting out, but I expect will go away in time. > > -Alan. > > [1] > http://hg.openjdk.java.net/code-tools/jtreg/raw-file/tip/src/share/doc/javatest/regtest/tag-spec.html > > > From peter.levart at gmail.com Wed Mar 30 14:16:10 2016 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 30 Mar 2016 16:16:10 +0200 Subject: javac accepts enums, annotations and final classes being referenced by 'uses' statement In-Reply-To: <56FBB606.7030000@oracle.com> References: <56FBB606.7030000@oracle.com> Message-ID: <56FBDFAA.8060701@gmail.com> Hi Georgiy, From the 3 cases below, I think only enum case is maybe problematic. And only because we know that no enum implementation class defines a public no-argument constructor. Final class is perfectly fine (it can be provided by its module with itself as the implementation class). Annotation interface has a history of being no exception in Java language for implementing by normal classes, so I would also not limit it here. For enum case then perhaps the module descriptor could enlist an enum constant name instead of class name as the implementation. This could also be the alternative when specifying service implementations for interfaces. For example: a/module-info.java: module a { uses pkg.Service; } b/module-info.java: module b { exports pkg; provides pkg.Service with [instance?] pkg.impl.ServiceImpl.ONE; } b/pkg/Service.java: package pkg; public interface Service {} b/pkg/impl/ServiceImpl.java: package pkg.impl; public enum ServiceImpl implements Service { ONE } Regards, Peter On 03/30/2016 01:18 PM, Georgiy Rakov wrote: > Hello, > > currently JDK9b111 javac successfully compiles following code: > > a/module-info.java: > module a { > uses pkg.FinalClassST; > uses pkg.EnumST; > uses pkg.AnnotationST; > } > > a/pkg/AnnotationST.java: > package pkg; > public @interface AnnotationST{} > > a/pkg/EnumST.java: > package pkg; > public enum EnumST {A,B} > > a/pkg/FinalClassST.java: > package pkg; > public final class FinalClassST{} > > > Could you please tell if this is javac, spec or both issue that type > being referenced by 'uses' statement is not checked at compile-time > for ability to be a service interface. > > The minimized testcase is attached; in order to run it please: > 1. unzip attached archive on Windows machine; > 2. rename test9\test_bat to test9\test.bat; > 3. modify test.bat by changing JDK_HOME variable to point to your JDK > installation; > 4. run test.bat. > > BTW: provided the type name references non existing type javac does > produce compile error. > > Thanks, > Georgiy. From Alan.Bateman at oracle.com Wed Mar 30 14:17:54 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 30 Mar 2016 15:17:54 +0100 Subject: RFR 8141609: Need test for jrtfs that runs on JDK 8 to target a JDK 9 image In-Reply-To: <56FBDE9B.4020901@oracle.com> References: <56CBD497.9090609@oracle.com> <56CC6F5A.5090901@oracle.com> <56CC80A6.9020401@oracle.com> <56CEB135.2070005@oracle.com> <56CED599.6060307@oracle.com> <56D52CE2.9060107@oracle.com> <56D54DD8.5060503@oracle.com> <56D7EC31.5080701@oracle.com> <56FBD6FA.1090802@oracle.com> <56FBD978.4050708@oracle.com> <56FBDE9B.4020901@oracle.com> Message-ID: <56FBE012.8010205@oracle.com> On 30/03/2016 15:11, Felix Yang wrote: > Hi Alan, > fixed "bin" to "classes". By the way, I need a sponsor for this > change. > Webrev: http://cr.openjdk.java.net/~xiaofeya/8141609/webrev.04/ No problem, I can sponsor this for you. -Alan From claes.redestad at oracle.com Wed Mar 30 14:15:52 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 30 Mar 2016 16:15:52 +0200 Subject: RFR: 8152641: Plugin to generate BMH$Species classes ahead-of-time In-Reply-To: <56FBC4D8.8010603@gmail.com> References: <56F3EEAB.4090600@oracle.com> <1FE3F7A6-1C7B-4DC6-875C-E3FAEDED08F5@oracle.com> <56F50EC5.6020500@gmail.com> <56F5520D.3080205@oracle.com> <56F676CA.5000803@gmail.com> <56FB09D3.4090000@oracle.com> <56FB82FE.5010209@gmail.com> <56FB8607.8030000@gmail.com> <56FBB014.6050002@oracle.com> <56FBC4D8.8010603@gmail.com> Message-ID: <56FBDF98.4090102@oracle.com> On 2016-03-30 14:21, Peter Levart wrote: > Hi Claes, > > On 03/30/2016 12:53 PM, Claes Redestad wrote: >> Hi, >> >> I think Class.forName(Module, String) seemed like a nice >> efficiency/simplicity compromise, but there is some usage of >> lambdas/method-refs in the Module lookup code, especially for >> exploded modules (which get exercised during JDK build). Depending on >> a lambda from code in java.lang.invoke means we fail to bootstrap. >> >> But hey, we're living in an encapsulated world now, and this is in >> java.base, so why not go directly to the BootLoader: >> >> http://cr.openjdk.java.net/~redestad/8152641/webrev.03/ >> >> Since this is what's called from Class.forName(Module, String), the >> overhead should be even smaller than in your classForNameInModule test. > > Good idea. > >> >> If I call this final, will you say "Reviewed"? :-) > > Sorry, I don't posses the powers. :-) > > I could say "rEVIEWED", but... > > In the plugin, the input is shortened speciesTypes strings. What > guarantees that they really are normalized? For example, If one > specifies "LLL" as input, it will get expanded into "LLL", the > generated class will have "_L3" as a name suffix, but you will pack it > in the image with "_LLL.class" filename suffix. > > That's another reason why a method in BoundMethodHandle$Factory with > the following signature: > > Map.Entry generateConcreteBMHClassBytes(String types); > > ...would be a good idea. It would return class bytes and the name of > the class which you could use to derive the class filename without > hardcoding the same logic in plugin and in BMH. > > You just move the "LambdaForm.shortenSignature(types)" from > getConcreteBMHClass and className/sourceFile calculation from > generateConcreteBMHClass down to generateConcreteBMHClassBytes method > and change the signatures... Yes, it makes sense to keep control over the class name inside the factory class, and this does allow specifying shortened or expanded forms (L3 vs LLL) interchangeably as input to the plugin, which reduces possibility for user errors. How about this: http://cr.openjdk.java.net/~redestad/8152641/webrev.04/ /Claes > > Regards, Peter > >> >> /Claes >> >> PS: The default list of types is generated in a few adhoc tests not >> part of this patch. I'm considering proposing add support for >> generating this list at build time. Maybe a JEP called "Build system >> support for profile-guided optimizations", which could also handle >> https://bugs.openjdk.java.net/browse/JDK-8150044 >> >> On 2016-03-30 09:53, Peter Levart wrote: >>> Hi Claes, >>> >>> Sorry, I found a flaw in the benchmark (the regex pattern to split >>> comma-separated string into substrings was wrong). What the >>> benchmark did was compare the overheads of a single lookup of a >>> longer class name containing commas. Here's the corrected result of >>> overheads of 5 unsuccessful lookups: >>> >>> Benchmark (generate) (lookup) Mode Cnt >>> Score Error Units >>> ClassForNameBench.classForName LL,LLL,LLLL,LLLLL,LLLLLL >>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 29627.141 ? 567.427 ns/op >>> ClassForNameBench.classForNameInModule LL,LLL,LLLL,LLLLL,LLLLLL >>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 1073.256 ? 23.794 ns/op >>> ClassForNameBench.hashSetContains LL,LLL,LLLL,LLLLL,LLLLLL >>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 33.022 ? 0.066 ns/op >>> ClassForNameBench.switchStatement LL,LLL,LLLL,LLLLL,LLLLLL >>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 38.498 ? 5.842 ns/op >>> >>> ...overheads are a little bigger (x5 approx.). >>> >>> >>> Here's the corrected benchmark: >>> >>> >>> package jdk.test; >>> >>> import org.openjdk.jmh.annotations.*; >>> import org.openjdk.jmh.infra.Blackhole; >>> >>> import java.io.Serializable; >>> import java.lang.invoke.MethodHandle; >>> import java.util.Iterator; >>> import java.util.Set; >>> import java.util.concurrent.TimeUnit; >>> import java.util.stream.Collectors; >>> import java.util.stream.Stream; >>> >>> @BenchmarkMode(Mode.AverageTime) >>> @Fork(value = 1, warmups = 0) >>> @Warmup(iterations = 10) >>> @Measurement(iterations = 10) >>> @OutputTimeUnit(TimeUnit.NANOSECONDS) >>> @State(Scope.Thread) >>> public class ClassForNameBench { >>> >>> static final String BMH = "java/lang/invoke/BoundMethodHandle"; >>> static final String SPECIES_PREFIX_NAME = "Species_"; >>> static final String SPECIES_PREFIX_PATH = BMH + "$" + >>> SPECIES_PREFIX_NAME; >>> >>> @Param({"LL,LLL,LLLL,LLLLL,LLLLLL"}) >>> public String generate; >>> >>> @Param({"LLI,LLLI,LLLLI,LLLLLI,LLLLLLI"}) >>> public String lookup; >>> >>> private String[] generatedTypes; >>> private String[] lookedUpTypes; >>> private Set generatedNames; >>> private String[] lookedUpNames; >>> >>> @Setup(Level.Trial) >>> public void setup() { >>> generatedTypes = generate.trim().split("\\s*,\\s*"); >>> lookedUpTypes = lookup.trim().split("\\s*,\\s*"); >>> generatedNames = Stream.of(generatedTypes) >>> .map(types -> SPECIES_PREFIX_PATH + >>> shortenSignature(types)) >>> .collect(Collectors.toSet()); >>> lookedUpNames = Stream.of(lookedUpTypes) >>> .map(types -> SPECIES_PREFIX_PATH + >>> shortenSignature(types)) >>> .toArray(String[]::new); >>> } >>> >>> @Benchmark >>> public void classForName(Blackhole bh) { >>> for (String name : lookedUpNames) { >>> try { >>> bh.consume(Class.forName(name, false, >>> MethodHandle.class.getClassLoader())); >>> } catch (ClassNotFoundException e) { >>> bh.consume(e); >>> } >>> } >>> } >>> >>> @Benchmark >>> public void classForNameInModule(Blackhole bh) { >>> for (String name : lookedUpNames) { >>> bh.consume(Class.forName(MethodHandle.class.getModule(), name)); >>> } >>> } >>> >>> @Benchmark >>> public void hashSetContains(Blackhole bh) { >>> for (String name : lookedUpNames) { >>> bh.consume(generatedNames.contains(name)); >>> } >>> } >>> >>> @Benchmark >>> public void switchStatement(Blackhole bh) { >>> for (String types : lookedUpTypes) { >>> bh.consume(getBMHSwitch(types)); >>> } >>> } >>> >>> static Class getBMHSwitch(String types) { >>> // should be in sync with @Param generate above... >>> switch (types) { >>> case "LL": return Object.class; >>> case "LLL": return Serializable.class; >>> case "LLLL": return Iterator.class; >>> case "LLLLL": return Throwable.class; >>> case "LLLLLL": return String.class; >>> default: return null; >>> } >>> } >>> >>> // copied from non-public LambdaForm >>> static String shortenSignature(String signature) { >>> // Hack to make signatures more readable when they show up >>> in method names. >>> final int NO_CHAR = -1, MIN_RUN = 3; >>> int c0, c1 = NO_CHAR, c1reps = 0; >>> StringBuilder buf = null; >>> int len = signature.length(); >>> if (len < MIN_RUN) return signature; >>> for (int i = 0; i <= len; i++) { >>> // shift in the next char: >>> c0 = c1; c1 = (i == len ? NO_CHAR : signature.charAt(i)); >>> if (c1 == c0) { ++c1reps; continue; } >>> // shift in the next count: >>> int c0reps = c1reps; c1reps = 1; >>> // end of a character run >>> if (c0reps < MIN_RUN) { >>> if (buf != null) { >>> while (--c0reps >= 0) >>> buf.append((char) c0); >>> } >>> continue; >>> } >>> // found three or more in a row >>> if (buf == null) >>> buf = new StringBuilder().append(signature, 0, i - >>> c0reps); >>> buf.append((char) c0).append(c0reps); >>> } >>> return (buf == null) ? signature : buf.toString(); >>> } >>> } >>> >>> >>> Regards, Peter >>> >>> >>> >>> On 03/30/2016 09:40 AM, Peter Levart wrote: >>>> Hi Claes, >>>> >>>> On 03/30/2016 01:03 AM, Claes Redestad wrote: >>>>> Hi Peter, Mandy, >>>>> >>>>> On 2016-03-26 12:47, Peter Levart wrote: >>>>>> >>>>>> Comparing this with proposed code from webrev: >>>>>> >>>>>> 493 try { >>>>>> 494 return (Class>>>>> BoundMethodHandle>) >>>>>> 495 Class.forName("java.lang.invoke.BoundMethodHandle$Species_" >>>>>> + LambdaForm.shortenSignature(types)); >>>>>> 496 } catch (ClassNotFoundException cnf) { >>>>>> 497 // Not pregenerated, generate >>>>>> the class >>>>>> 498 return >>>>>> generateConcreteBMHClass(types); >>>>>> 499 } >>>>>> >>>>>> >>>>>> ...note that the function passed to CLASS_CACHE.computeIfAbsent >>>>>> is executed just once per distinct 'types' argument. Even if you >>>>>> put the generated switch between a call to getConcreteBMHClass >>>>>> and CLASS_CACHE.computeIfAbsent, getConcreteBMHClass(String >>>>>> types) is executed just once per distinct 'types' argument >>>>>> (except in rare occasions when VM can not initialize the loaded >>>>>> class). >>>>>> >>>>>> In this respect a successful Class.forName() is not any worse >>>>>> than static resolving. It's just that unsuccessful >>>>>> Class.forName() represents some overhead for classes that are not >>>>>> pre-generated. So an alternative way to get rid of that overhead >>>>>> is to have a HashSet of 'types' strings for pre-generated classes >>>>>> at hand in order to decide whether to call Class.forName or >>>>>> generateConcreteBMHClass. >>>>>> >>>>>> What's easier to support is another question. >>>>>> >>>>>> Regards, Peter >>>>> >>>>> to have something to compare with I built a version which, like >>>>> you suggest, >>>>> generates a HashSet with the set of generated classes here: >>>>> >>>>> http://cr.openjdk.java.net/~redestad/8152641/webrev.02/ >>>>> >>>>> This adds a fair bit of complexity to the plugin and requires we >>>>> add a nested >>>>> class in BoundMethodHandle that we can replace. Using the anonymous >>>>> compute Function for this seems like the best choice for this. >>>> >>>> ...what I had in mind as alternative to a pregenerated class with a >>>> switch was a simple textual resource file, generated by plugin, >>>> read-in by BMH into a HashSet. No special-purpose class generation >>>> and much less complexity for the plugin. >>>> >>>>> >>>>> I've not been able to measure any statistical difference in real >>>>> startup terms, >>>>> though, and not figured out a smart way to benchmark the overhead >>>>> of the >>>>> CNFE in relation to the class generation (my guess it adds a >>>>> fraction to the >>>>> total cost) and since this adds ever so little footprint and an >>>>> extra lookup to the >>>>> fast path it would seem that this is the wrong trade-off to do here. >>>> >>>> Yes, perhaps it would be best to just use Class.forName(module, >>>> className) instead. I have created a little benchmark to compare >>>> overheads (just overheads) of unsuccessful lookups for pregenerated >>>> classes (a situation where a BMH class is requested that has not >>>> been pregenerated) and here's the result for overhead of 5 >>>> unsuccessfull lookups: >>>> >>>> Benchmark (generate) (lookup) Mode Cnt >>>> Score Error Units >>>> ClassForNameBench.classForName LL,LLL,LLLL,LLLLL,LLLLLL >>>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 6800.878 ? 421.424 ns/op >>>> ClassForNameBench.classForNameInModule LL,LLL,LLLL,LLLLL,LLLLLL >>>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 209.574 ? 2.114 ns/op >>>> ClassForNameBench.hashSetContains LL,LLL,LLLL,LLLLL,LLLLLL >>>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 6.813 ? 0.317 ns/op >>>> ClassForNameBench.switchStatement LL,LLL,LLLL,LLLLL,LLLLLL >>>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 6.601 ? 0.061 ns/op >>>> >>>> ...compared to runtime BMH class generation and loading this is >>>> really a very minor overhead. I would just use >>>> Class.forName(module, className) and reduce the complexity of the >>>> plugin. >>>> >>>> What do you think? >>>> >>>> >>>> Here's the benchmark: >>>> >>>> package jdk.test; >>>> >>>> import org.openjdk.jmh.annotations.*; >>>> import org.openjdk.jmh.infra.Blackhole; >>>> >>>> import java.io.Serializable; >>>> import java.lang.invoke.MethodHandle; >>>> import java.util.Iterator; >>>> import java.util.Set; >>>> import java.util.concurrent.TimeUnit; >>>> import java.util.stream.Collectors; >>>> import java.util.stream.Stream; >>>> >>>> @BenchmarkMode(Mode.AverageTime) >>>> @Fork(value = 1, warmups = 0) >>>> @Warmup(iterations = 10) >>>> @Measurement(iterations = 10) >>>> @OutputTimeUnit(TimeUnit.NANOSECONDS) >>>> @State(Scope.Thread) >>>> public class ClassForNameBench { >>>> >>>> static final String BMH = "java/lang/invoke/BoundMethodHandle"; >>>> static final String SPECIES_PREFIX_NAME = "Species_"; >>>> static final String SPECIES_PREFIX_PATH = BMH + "$" + >>>> SPECIES_PREFIX_NAME; >>>> >>>> @Param({"LL,LLL,LLLL,LLLLL,LLLLLL"}) >>>> public String generate; >>>> >>>> @Param({"LLI,LLLI,LLLLI,LLLLLI,LLLLLLI"}) >>>> public String lookup; >>>> >>>> private String[] generatedTypes; >>>> private String[] lookedUpTypes; >>>> private Set generatedNames; >>>> private String[] lookedUpNames; >>>> >>>> @Setup(Level.Trial) >>>> public void setup() { >>>> generatedTypes = generate.trim().split("\\s+,\\s+"); >>>> lookedUpTypes = lookup.trim().split("\\s+,\\s+"); >>>> generatedNames = Stream.of(generatedTypes) >>>> .map(types -> SPECIES_PREFIX_PATH + >>>> shortenSignature(types)) >>>> .collect(Collectors.toSet()); >>>> lookedUpNames = Stream.of(lookedUpTypes) >>>> .map(types -> SPECIES_PREFIX_PATH + >>>> shortenSignature(types)) >>>> .toArray(String[]::new); >>>> } >>>> >>>> @Benchmark >>>> public void classForName(Blackhole bh) { >>>> for (String name : lookedUpNames) { >>>> try { >>>> bh.consume(Class.forName(name, false, >>>> MethodHandle.class.getClassLoader())); >>>> } catch (ClassNotFoundException e) { >>>> bh.consume(e); >>>> } >>>> } >>>> } >>>> >>>> @Benchmark >>>> public void classForNameInModule(Blackhole bh) { >>>> for (String name : lookedUpNames) { >>>> bh.consume(Class.forName(MethodHandle.class.getModule(), name)); >>>> } >>>> } >>>> >>>> @Benchmark >>>> public void hashSetContains(Blackhole bh) { >>>> for (String name : lookedUpNames) { >>>> bh.consume(generatedNames.contains(name)); >>>> } >>>> } >>>> >>>> @Benchmark >>>> public void switchStatement(Blackhole bh) { >>>> for (String types : lookedUpTypes) { >>>> bh.consume(getBMHSwitch(types)); >>>> } >>>> } >>>> >>>> static Class getBMHSwitch(String types) { >>>> // should be in sync with @Param generate above... >>>> switch (types) { >>>> case "LL": return Object.class; >>>> case "LLL": return Serializable.class; >>>> case "LLLL": return Iterator.class; >>>> case "LLLLL": return Throwable.class; >>>> case "LLLLLL": return String.class; >>>> default: return null; >>>> } >>>> } >>>> >>>> // copied from non-public LambdaForm >>>> static String shortenSignature(String signature) { >>>> // Hack to make signatures more readable when they show up >>>> in method names. >>>> final int NO_CHAR = -1, MIN_RUN = 3; >>>> int c0, c1 = NO_CHAR, c1reps = 0; >>>> StringBuilder buf = null; >>>> int len = signature.length(); >>>> if (len < MIN_RUN) return signature; >>>> for (int i = 0; i <= len; i++) { >>>> // shift in the next char: >>>> c0 = c1; c1 = (i == len ? NO_CHAR : signature.charAt(i)); >>>> if (c1 == c0) { ++c1reps; continue; } >>>> // shift in the next count: >>>> int c0reps = c1reps; c1reps = 1; >>>> // end of a character run >>>> if (c0reps < MIN_RUN) { >>>> if (buf != null) { >>>> while (--c0reps >= 0) >>>> buf.append((char) c0); >>>> } >>>> continue; >>>> } >>>> // found three or more in a row >>>> if (buf == null) >>>> buf = new StringBuilder().append(signature, 0, i - >>>> c0reps); >>>> buf.append((char) c0).append(c0reps); >>>> } >>>> return (buf == null) ? signature : buf.toString(); >>>> } >>>> } >>>> >>>> >>>> >>>> Regards, Peter >>>> >>>>> >>>>> All-in-all I lean towards moving forward with the first, simpler >>>>> revision of this >>>>> patch[1] and then evaluate if webrev.02 or a String-switch+static >>>>> resolve >>>>> as a follow-up. >>>>> >>>>> A compromise would be to keep the SpeciesLookup class introduced here >>>>> to allow removing all overhead in case the plugin is disabled. >>>>> >>>>> Mandy: I've not found any test (under jdk/test/tools/jlink or >>>>> elsewhere) which >>>>> has to be updated when adding a plugin like this. >>>>> >>>>> Thanks! >>>>> >>>>> /Claes >>>>> >>>>> [1] http://cr.openjdk.java.net/~redestad/8152641/webrev.01/ >>>> >>> >> > From pbenedict at apache.org Wed Mar 30 14:47:04 2016 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 30 Mar 2016 09:47:04 -0500 Subject: modulepath and classpath mixture In-Reply-To: <6FB0B05A-6850-42F4-A6A3-42B7486CCDAA@oracle.com> References: <56CC57A1.2050109@oracle.com> <56F2440A.7010505@oracle.com> <56F2914C.3030706@oracle.com> <56F2B3DA.402@oracle.com> <1228911717.349701.1459160027285.JavaMail.zimbra@u-pem.fr> <0CC4E4A6-4152-4BB0-BB42-B9E284540BB6@oracle.com> <6FB0B05A-6850-42F4-A6A3-42B7486CCDAA@oracle.com> Message-ID: Russell, if you have a module with package X and a classpath jar with package X, the module can't see package X from the classpath. In the last several posts, there's been discussion on putting tests on the classpath; keeping the "main" code in the module. So given what I stated above, that's what I've been referring to. Cheers, Paul On Wed, Mar 30, 2016 at 7:28 AM, Russell Gold wrote: > Hi Paul, > > Could you explain? What kind of code do you mean cannot access it? And > what do you mean by ?a split package situation?? > > From a conversation I had with Alan, earlier in this thread: > > > On Mar 23, 2016, at 11:42 AM, Alan Bateman > wrote: > > On 23/03/2016 14:15, Russell Gold wrote: > > Here are my assumptions, which you can correct. > > 1. A jar or classes directory placed on a class path are treated as part > of the unnamed module > > Yes > > > So if the tests and main code are both in directories, which they have > been up to now in Maven, why would there be a problem? Both would be in the > unnamed module and able to access one another. > > - Russ > > On Mar 29, 2016, at 10:47 PM, Paul Benedict wrote: > > Russell, when you drop a jar on the classpath, module code will not be > able to access it in a split package situation. That's the big barrier > here. Maven test projects are typically written with the same package > shared with the "main" code. > > Cheers, > Paul > > On Tue, Mar 29, 2016 at 11:33 AM, Russell Gold > wrote: > >> Hi Stephen, >> >> Why do you need any kind of friend access? >> >> It seems to me that this is making things harder than they need to be. >> The tests can simply run with the production code on the class path, and >> then there are no module issues at all. >> >> I think a larger problem is that you can do what I just said with the >> jars, even a jar which has been designated as a module by virtue of having >> a module-info.class in it. That means that, when users are up taking jars, >> they are not prevented from accessing module internals. They can put the >> jars on the module path, of course, but they can still use them on the >> class path! >> >> - Russ >> >> > >> > On 28 March 2016 at 11:13, Remi Forax wrote: >> >> Hi Stephen, Hi all, >> >> I think that delivering tests as a separated module is a bad idea. >> >> >> >> I see that from the point of a developer, seeing the code and the test >> as different modules can be attractive because everything seems to be put >> at the right place but there is a big drawback. Because modules are reified >> at runtime, it means that the runtime environment of the tests will be >> different from the production environment. >> > >> > This last sentence doesn't make sense to me - tests are not run in a >> > production environment. >> > >> > Tests have all the qualities of modules - code, dependencies, >> > compilation phase, deployment. The only special part is the need for >> > special "friend-like" access, which Jigsaw already has for other cases >> > (the export...to clause). >> > >> > Put simply, I consider that module = >> > deployment-artifact-with-dependencies. With that mental model, putting >> > tests inside the module is just not acceptable, because tests should >> > not be deployed with the main application and they have different >> > dependencies. If we disagree that module = >> > deployment-artifact-with-dependencies, then perhaps we have bigger >> > problems to solve here. >> > >> > Stephen >> > (And to Paul Benedict, the classpath is going to die over time, so any >> > solution that uses that is flawed IMO). >> > >> > >> >> So as Alan said, from the jigsaw point of view at runtime, the tests >> and the code should be in the same module. >> >> >> >> So the building tools have to come with a way to support to have 2 >> different module-info.java in two different folders and package them as one >> module, >> >> maybe javac should help by providing a way to merge 2 module-info at >> compile time. >> >> >> >> R?mi >> >> >> >> ----- Mail original ----- >> >>> De: "Alan Bateman" >> >>> ?: "Stephen Colebourne" , "jigsaw-dev" < >> jigsaw-dev at openjdk.java.net> >> >>> Envoy?: Mercredi 23 Mars 2016 16:18:50 >> >>> Objet: Re: modulepath and classpath mixture >> >>> >> >>> >> >>> On 23/03/2016 14:42, Stephen Colebourne wrote: >> >>>> : >> >>>> >> >>>> I don't particularly care what the mechanism is for this, but at the >> >>>> requirements level: >> >>>> - there are two modules - main and test >> >>>> - each has its own source tree >> >>>> - each has its own dependencies >> >>>> - each is released separately >> >>>> - each could be hosted on a central repo >> >>>> - the test module needs to be able to contain the same packages as >> the >> >>>> main module >> >>>> - the test module needs to be able to invoke package-scoped code in >> >>>> the same package in the main module >> >>>> >> >>>> To clarify further consider 4 modules, A, B, A-test and B-test where >> B >> >>>> depends on A. Module A-test may have a method foo() that uses package >> >>>> scope to access something in A. Module B-test will depend on A-test >> >>>> and rely on foo() to get access to that internal object. >> >>> To your list, I would add the ability to make use of testing >> frameworks >> >>> like TestNG and JUnit. >> >>> >> >>> In any case, and as things currently stand, you've got most of the >> >>> above. One differences is that the tests are not a separate module, >> they >> >>> are instead compiled and run in a way that patches the main module. >> The >> >>> second difference is that they don't have their own module >> declaration, >> >>> instead the compilation or run augments the dependences with any >> >>> additional dependences that the tests have. As I said, if they tools >> >>> makes it easy then I don't think it's too bad. >> >>> >> >>>> >> >>>> (Note that I view the thread discussion of >> >>>> references to test classes on the classpath as another hack. >> >>>> >> >>> Packages can't be split between modules and classpath so there is no >> >>> support for that. >> >>> >> >>> -Alan >> >>> >> >> > > From ali.ebrahimi1781 at gmail.com Wed Mar 30 15:12:22 2016 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Wed, 30 Mar 2016 19:42:22 +0430 Subject: modulepath and classpath mixture In-Reply-To: <583721482.2221663.1459347179231.JavaMail.zimbra@u-pem.fr> References: <56F2B3DA.402@oracle.com> <1228911717.349701.1459160027285.JavaMail.zimbra@u-pem.fr> <0CC4E4A6-4152-4BB0-BB42-B9E284540BB6@oracle.com> <6FB0B05A-6850-42F4-A6A3-42B7486CCDAA@oracle.com> <56FBD85F.6070103@oracle.com> <583721482.2221663.1459347179231.JavaMail.zimbra@u-pem.fr> Message-ID: So, do you suggest partial modules or module fragments? Why we make things so complex for writing single test method. I think testing is an essential part of development, so modular java should have first class support for that. I don't see command line options as developer friendly solution, even things gets worse when have dozen of modules. On Wed, Mar 30, 2016 at 6:42 PM, Remi Forax wrote: > Alan, Jon, > i think javac -Xmodule should merge the module-info.java from the existing > module and the one declared in the directory, > with the current semantics of the module-info, merging of modules is easy > and with no corner cases, > so for testing, the test will be able to declare their own dependencies > inside their own module-info.java. > > Proposed semantics for merging, > - do the union of the required modules > - if one required module is required publicly, it will be required > publicly. > - do the union of the exported packages > - if one exported package is restricted, do the union of the restriction > - do the union of the uses. > - do the union of the provides. > > so merging two modules is symmetric and will always succeed. > > R?mi > > ----- Mail original ----- > > De: "Alan Bateman" > > ?: "Russell Gold" > > Cc: "jigsaw-dev" > > Envoy?: Mercredi 30 Mars 2016 15:45:03 > > Objet: Re: modulepath and classpath mixture > > > > On 30/03/2016 13:28, Russell Gold wrote: > > > : > > > > > > > > > So if the tests and main code are both in directories, which they have > been > > > up to now in Maven, why would there be a problem? Both would be in the > > > unnamed module and able to access one another. > > > > > There shouldn't any issue there, it should just work as it has always > done. > > > > The thread here has meandered a bit but I think the scenario under > > discussion is tests for a module that need to nestmate with the module > > under test. The tests are in their own test tree. The tests are compiled > > separately from the module they test and may have additional dependences > > (such as on TestNG or JUnit for example). When compiling or running then > > the tests need to access public types in non-exported packages and maybe > > package private members too. The support for this has been in jake for a > > long time but involves command line options that many developers or > > build environments won't immediately grok. In particular the tests have > > to be compiled "as if" they augment the already compiled module - that > > is what javac -Xmodule is about. There is no need to co-locate source > > files or class files of course. When run then the -Xpatch option is what > > brings the tests and the module classes together. If we get the tools > > right then most developers won't ever see this of course. > > > > One other thing to say that we've already been through some of this with > > the JDK tests. The jtreg test harness that we use for the JDK tests has > > been updated (thanks to Jon Gibbons) with useful support for modules > > [1]. It's enough for us to write tests that use JDK-internal APIs or > > write tests that nestmate with types in system modules so that they get > > access to package private type or public types in non-exported packages. > > It has rudimentary support for user modules too. Additional dependences > > are still an issue but our tests don't require additional dependences > > beyond TestNG. The test harness employs a bit of hackery to get things > > done, important when starting out, but I expect will go away in time. > > > > -Alan. > > > > [1] > > > http://hg.openjdk.java.net/code-tools/jtreg/raw-file/tip/src/share/doc/javatest/regtest/tag-spec.html > > > > > > > -- Best Regards, Ali Ebrahimi From peter.levart at gmail.com Wed Mar 30 15:17:28 2016 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 30 Mar 2016 17:17:28 +0200 Subject: RFR: 8152641: Plugin to generate BMH$Species classes ahead-of-time In-Reply-To: <56FBDF98.4090102@oracle.com> References: <56F3EEAB.4090600@oracle.com> <1FE3F7A6-1C7B-4DC6-875C-E3FAEDED08F5@oracle.com> <56F50EC5.6020500@gmail.com> <56F5520D.3080205@oracle.com> <56F676CA.5000803@gmail.com> <56FB09D3.4090000@oracle.com> <56FB82FE.5010209@gmail.com> <56FB8607.8030000@gmail.com> <56FBB014.6050002@oracle.com> <56FBC4D8.8010603@gmail.com> <56FBDF98.4090102@oracle.com> Message-ID: <56FBEE08.7010600@gmail.com> Hi Claes, webrev.04 looks good now. Maybe just one nit. For production quality, plugin input could be verified that after expansion it is composed of just the following characters: "LIJFD". Otherwise ClassWriter might generate an unusable class without complaining (for example if someone sneaks-in characters 'S' 'Z' 'B' or 'C')... Or, better yet, create another method in BMH that will be the "public" API between the plugin and BMH which does the validation and calls generateConcreteBMHClassBytes(). Internally in BMH the validation is not necessary as the types strings are composed programmatically and are guaranteed to be correct. Regards, Peter On 03/30/2016 04:15 PM, Claes Redestad wrote: > > > On 2016-03-30 14:21, Peter Levart wrote: >> Hi Claes, >> >> On 03/30/2016 12:53 PM, Claes Redestad wrote: >>> Hi, >>> >>> I think Class.forName(Module, String) seemed like a nice >>> efficiency/simplicity compromise, but there is some usage of >>> lambdas/method-refs in the Module lookup code, especially for >>> exploded modules (which get exercised during JDK build). Depending >>> on a lambda from code in java.lang.invoke means we fail to bootstrap. >>> >>> But hey, we're living in an encapsulated world now, and this is in >>> java.base, so why not go directly to the BootLoader: >>> >>> http://cr.openjdk.java.net/~redestad/8152641/webrev.03/ >>> >>> Since this is what's called from Class.forName(Module, String), the >>> overhead should be even smaller than in your classForNameInModule test. >> >> Good idea. >> >>> >>> If I call this final, will you say "Reviewed"? :-) >> >> Sorry, I don't posses the powers. :-) >> >> I could say "rEVIEWED", but... >> >> In the plugin, the input is shortened speciesTypes strings. What >> guarantees that they really are normalized? For example, If one >> specifies "LLL" as input, it will get expanded into "LLL", the >> generated class will have "_L3" as a name suffix, but you will pack >> it in the image with "_LLL.class" filename suffix. >> >> That's another reason why a method in BoundMethodHandle$Factory with >> the following signature: >> >> Map.Entry generateConcreteBMHClassBytes(String types); >> >> ...would be a good idea. It would return class bytes and the name of >> the class which you could use to derive the class filename without >> hardcoding the same logic in plugin and in BMH. >> >> You just move the "LambdaForm.shortenSignature(types)" from >> getConcreteBMHClass and className/sourceFile calculation from >> generateConcreteBMHClass down to generateConcreteBMHClassBytes method >> and change the signatures... > > Yes, it makes sense to keep control over the class name inside the > factory class, and this does allow specifying shortened or expanded > forms (L3 vs LLL) interchangeably as input to the plugin, which > reduces possibility for user errors. > > How about this: http://cr.openjdk.java.net/~redestad/8152641/webrev.04/ > > /Claes > >> >> Regards, Peter >> >>> >>> /Claes >>> >>> PS: The default list of types is generated in a few adhoc tests not >>> part of this patch. I'm considering proposing add support for >>> generating this list at build time. Maybe a JEP called "Build system >>> support for profile-guided optimizations", which could also handle >>> https://bugs.openjdk.java.net/browse/JDK-8150044 >>> >>> On 2016-03-30 09:53, Peter Levart wrote: >>>> Hi Claes, >>>> >>>> Sorry, I found a flaw in the benchmark (the regex pattern to split >>>> comma-separated string into substrings was wrong). What the >>>> benchmark did was compare the overheads of a single lookup of a >>>> longer class name containing commas. Here's the corrected result of >>>> overheads of 5 unsuccessful lookups: >>>> >>>> Benchmark (generate) (lookup) Mode Cnt >>>> Score Error Units >>>> ClassForNameBench.classForName LL,LLL,LLLL,LLLLL,LLLLLL >>>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 29627.141 ? 567.427 ns/op >>>> ClassForNameBench.classForNameInModule LL,LLL,LLLL,LLLLL,LLLLLL >>>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 1073.256 ? 23.794 ns/op >>>> ClassForNameBench.hashSetContains LL,LLL,LLLL,LLLLL,LLLLLL >>>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 33.022 ? 0.066 ns/op >>>> ClassForNameBench.switchStatement LL,LLL,LLLL,LLLLL,LLLLLL >>>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 38.498 ? 5.842 ns/op >>>> >>>> ...overheads are a little bigger (x5 approx.). >>>> >>>> >>>> Here's the corrected benchmark: >>>> >>>> >>>> package jdk.test; >>>> >>>> import org.openjdk.jmh.annotations.*; >>>> import org.openjdk.jmh.infra.Blackhole; >>>> >>>> import java.io.Serializable; >>>> import java.lang.invoke.MethodHandle; >>>> import java.util.Iterator; >>>> import java.util.Set; >>>> import java.util.concurrent.TimeUnit; >>>> import java.util.stream.Collectors; >>>> import java.util.stream.Stream; >>>> >>>> @BenchmarkMode(Mode.AverageTime) >>>> @Fork(value = 1, warmups = 0) >>>> @Warmup(iterations = 10) >>>> @Measurement(iterations = 10) >>>> @OutputTimeUnit(TimeUnit.NANOSECONDS) >>>> @State(Scope.Thread) >>>> public class ClassForNameBench { >>>> >>>> static final String BMH = "java/lang/invoke/BoundMethodHandle"; >>>> static final String SPECIES_PREFIX_NAME = "Species_"; >>>> static final String SPECIES_PREFIX_PATH = BMH + "$" + >>>> SPECIES_PREFIX_NAME; >>>> >>>> @Param({"LL,LLL,LLLL,LLLLL,LLLLLL"}) >>>> public String generate; >>>> >>>> @Param({"LLI,LLLI,LLLLI,LLLLLI,LLLLLLI"}) >>>> public String lookup; >>>> >>>> private String[] generatedTypes; >>>> private String[] lookedUpTypes; >>>> private Set generatedNames; >>>> private String[] lookedUpNames; >>>> >>>> @Setup(Level.Trial) >>>> public void setup() { >>>> generatedTypes = generate.trim().split("\\s*,\\s*"); >>>> lookedUpTypes = lookup.trim().split("\\s*,\\s*"); >>>> generatedNames = Stream.of(generatedTypes) >>>> .map(types -> SPECIES_PREFIX_PATH + >>>> shortenSignature(types)) >>>> .collect(Collectors.toSet()); >>>> lookedUpNames = Stream.of(lookedUpTypes) >>>> .map(types -> SPECIES_PREFIX_PATH + >>>> shortenSignature(types)) >>>> .toArray(String[]::new); >>>> } >>>> >>>> @Benchmark >>>> public void classForName(Blackhole bh) { >>>> for (String name : lookedUpNames) { >>>> try { >>>> bh.consume(Class.forName(name, false, >>>> MethodHandle.class.getClassLoader())); >>>> } catch (ClassNotFoundException e) { >>>> bh.consume(e); >>>> } >>>> } >>>> } >>>> >>>> @Benchmark >>>> public void classForNameInModule(Blackhole bh) { >>>> for (String name : lookedUpNames) { >>>> bh.consume(Class.forName(MethodHandle.class.getModule(), name)); >>>> } >>>> } >>>> >>>> @Benchmark >>>> public void hashSetContains(Blackhole bh) { >>>> for (String name : lookedUpNames) { >>>> bh.consume(generatedNames.contains(name)); >>>> } >>>> } >>>> >>>> @Benchmark >>>> public void switchStatement(Blackhole bh) { >>>> for (String types : lookedUpTypes) { >>>> bh.consume(getBMHSwitch(types)); >>>> } >>>> } >>>> >>>> static Class getBMHSwitch(String types) { >>>> // should be in sync with @Param generate above... >>>> switch (types) { >>>> case "LL": return Object.class; >>>> case "LLL": return Serializable.class; >>>> case "LLLL": return Iterator.class; >>>> case "LLLLL": return Throwable.class; >>>> case "LLLLLL": return String.class; >>>> default: return null; >>>> } >>>> } >>>> >>>> // copied from non-public LambdaForm >>>> static String shortenSignature(String signature) { >>>> // Hack to make signatures more readable when they show up >>>> in method names. >>>> final int NO_CHAR = -1, MIN_RUN = 3; >>>> int c0, c1 = NO_CHAR, c1reps = 0; >>>> StringBuilder buf = null; >>>> int len = signature.length(); >>>> if (len < MIN_RUN) return signature; >>>> for (int i = 0; i <= len; i++) { >>>> // shift in the next char: >>>> c0 = c1; c1 = (i == len ? NO_CHAR : signature.charAt(i)); >>>> if (c1 == c0) { ++c1reps; continue; } >>>> // shift in the next count: >>>> int c0reps = c1reps; c1reps = 1; >>>> // end of a character run >>>> if (c0reps < MIN_RUN) { >>>> if (buf != null) { >>>> while (--c0reps >= 0) >>>> buf.append((char) c0); >>>> } >>>> continue; >>>> } >>>> // found three or more in a row >>>> if (buf == null) >>>> buf = new StringBuilder().append(signature, 0, i - >>>> c0reps); >>>> buf.append((char) c0).append(c0reps); >>>> } >>>> return (buf == null) ? signature : buf.toString(); >>>> } >>>> } >>>> >>>> >>>> Regards, Peter >>>> >>>> >>>> >>>> On 03/30/2016 09:40 AM, Peter Levart wrote: >>>>> Hi Claes, >>>>> >>>>> On 03/30/2016 01:03 AM, Claes Redestad wrote: >>>>>> Hi Peter, Mandy, >>>>>> >>>>>> On 2016-03-26 12:47, Peter Levart wrote: >>>>>>> >>>>>>> Comparing this with proposed code from webrev: >>>>>>> >>>>>>> 493 try { >>>>>>> 494 return (Class>>>>>> BoundMethodHandle>) >>>>>>> 495 Class.forName("java.lang.invoke.BoundMethodHandle$Species_" >>>>>>> + LambdaForm.shortenSignature(types)); >>>>>>> 496 } catch (ClassNotFoundException cnf) { >>>>>>> 497 // Not pregenerated, generate >>>>>>> the class >>>>>>> 498 return >>>>>>> generateConcreteBMHClass(types); >>>>>>> 499 } >>>>>>> >>>>>>> >>>>>>> ...note that the function passed to CLASS_CACHE.computeIfAbsent >>>>>>> is executed just once per distinct 'types' argument. Even if you >>>>>>> put the generated switch between a call to getConcreteBMHClass >>>>>>> and CLASS_CACHE.computeIfAbsent, getConcreteBMHClass(String >>>>>>> types) is executed just once per distinct 'types' argument >>>>>>> (except in rare occasions when VM can not initialize the loaded >>>>>>> class). >>>>>>> >>>>>>> In this respect a successful Class.forName() is not any worse >>>>>>> than static resolving. It's just that unsuccessful >>>>>>> Class.forName() represents some overhead for classes that are >>>>>>> not pre-generated. So an alternative way to get rid of that >>>>>>> overhead is to have a HashSet of 'types' strings for >>>>>>> pre-generated classes at hand in order to decide whether to call >>>>>>> Class.forName or generateConcreteBMHClass. >>>>>>> >>>>>>> What's easier to support is another question. >>>>>>> >>>>>>> Regards, Peter >>>>>> >>>>>> to have something to compare with I built a version which, like >>>>>> you suggest, >>>>>> generates a HashSet with the set of generated classes here: >>>>>> >>>>>> http://cr.openjdk.java.net/~redestad/8152641/webrev.02/ >>>>>> >>>>>> This adds a fair bit of complexity to the plugin and requires we >>>>>> add a nested >>>>>> class in BoundMethodHandle that we can replace. Using the anonymous >>>>>> compute Function for this seems like the best choice for this. >>>>> >>>>> ...what I had in mind as alternative to a pregenerated class with >>>>> a switch was a simple textual resource file, generated by plugin, >>>>> read-in by BMH into a HashSet. No special-purpose class generation >>>>> and much less complexity for the plugin. >>>>> >>>>>> >>>>>> I've not been able to measure any statistical difference in real >>>>>> startup terms, >>>>>> though, and not figured out a smart way to benchmark the overhead >>>>>> of the >>>>>> CNFE in relation to the class generation (my guess it adds a >>>>>> fraction to the >>>>>> total cost) and since this adds ever so little footprint and an >>>>>> extra lookup to the >>>>>> fast path it would seem that this is the wrong trade-off to do here. >>>>> >>>>> Yes, perhaps it would be best to just use Class.forName(module, >>>>> className) instead. I have created a little benchmark to compare >>>>> overheads (just overheads) of unsuccessful lookups for >>>>> pregenerated classes (a situation where a BMH class is requested >>>>> that has not been pregenerated) and here's the result for overhead >>>>> of 5 unsuccessfull lookups: >>>>> >>>>> Benchmark (generate) (lookup) Mode Cnt >>>>> Score Error Units >>>>> ClassForNameBench.classForName LL,LLL,LLLL,LLLLL,LLLLLL >>>>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 6800.878 ? 421.424 ns/op >>>>> ClassForNameBench.classForNameInModule LL,LLL,LLLL,LLLLL,LLLLLL >>>>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 209.574 ? 2.114 ns/op >>>>> ClassForNameBench.hashSetContains LL,LLL,LLLL,LLLLL,LLLLLL >>>>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 6.813 ? 0.317 ns/op >>>>> ClassForNameBench.switchStatement LL,LLL,LLLL,LLLLL,LLLLLL >>>>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 6.601 ? 0.061 ns/op >>>>> >>>>> ...compared to runtime BMH class generation and loading this is >>>>> really a very minor overhead. I would just use >>>>> Class.forName(module, className) and reduce the complexity of the >>>>> plugin. >>>>> >>>>> What do you think? >>>>> >>>>> >>>>> Here's the benchmark: >>>>> >>>>> package jdk.test; >>>>> >>>>> import org.openjdk.jmh.annotations.*; >>>>> import org.openjdk.jmh.infra.Blackhole; >>>>> >>>>> import java.io.Serializable; >>>>> import java.lang.invoke.MethodHandle; >>>>> import java.util.Iterator; >>>>> import java.util.Set; >>>>> import java.util.concurrent.TimeUnit; >>>>> import java.util.stream.Collectors; >>>>> import java.util.stream.Stream; >>>>> >>>>> @BenchmarkMode(Mode.AverageTime) >>>>> @Fork(value = 1, warmups = 0) >>>>> @Warmup(iterations = 10) >>>>> @Measurement(iterations = 10) >>>>> @OutputTimeUnit(TimeUnit.NANOSECONDS) >>>>> @State(Scope.Thread) >>>>> public class ClassForNameBench { >>>>> >>>>> static final String BMH = "java/lang/invoke/BoundMethodHandle"; >>>>> static final String SPECIES_PREFIX_NAME = "Species_"; >>>>> static final String SPECIES_PREFIX_PATH = BMH + "$" + >>>>> SPECIES_PREFIX_NAME; >>>>> >>>>> @Param({"LL,LLL,LLLL,LLLLL,LLLLLL"}) >>>>> public String generate; >>>>> >>>>> @Param({"LLI,LLLI,LLLLI,LLLLLI,LLLLLLI"}) >>>>> public String lookup; >>>>> >>>>> private String[] generatedTypes; >>>>> private String[] lookedUpTypes; >>>>> private Set generatedNames; >>>>> private String[] lookedUpNames; >>>>> >>>>> @Setup(Level.Trial) >>>>> public void setup() { >>>>> generatedTypes = generate.trim().split("\\s+,\\s+"); >>>>> lookedUpTypes = lookup.trim().split("\\s+,\\s+"); >>>>> generatedNames = Stream.of(generatedTypes) >>>>> .map(types -> SPECIES_PREFIX_PATH + >>>>> shortenSignature(types)) >>>>> .collect(Collectors.toSet()); >>>>> lookedUpNames = Stream.of(lookedUpTypes) >>>>> .map(types -> SPECIES_PREFIX_PATH + >>>>> shortenSignature(types)) >>>>> .toArray(String[]::new); >>>>> } >>>>> >>>>> @Benchmark >>>>> public void classForName(Blackhole bh) { >>>>> for (String name : lookedUpNames) { >>>>> try { >>>>> bh.consume(Class.forName(name, false, >>>>> MethodHandle.class.getClassLoader())); >>>>> } catch (ClassNotFoundException e) { >>>>> bh.consume(e); >>>>> } >>>>> } >>>>> } >>>>> >>>>> @Benchmark >>>>> public void classForNameInModule(Blackhole bh) { >>>>> for (String name : lookedUpNames) { >>>>> bh.consume(Class.forName(MethodHandle.class.getModule(), name)); >>>>> } >>>>> } >>>>> >>>>> @Benchmark >>>>> public void hashSetContains(Blackhole bh) { >>>>> for (String name : lookedUpNames) { >>>>> bh.consume(generatedNames.contains(name)); >>>>> } >>>>> } >>>>> >>>>> @Benchmark >>>>> public void switchStatement(Blackhole bh) { >>>>> for (String types : lookedUpTypes) { >>>>> bh.consume(getBMHSwitch(types)); >>>>> } >>>>> } >>>>> >>>>> static Class getBMHSwitch(String types) { >>>>> // should be in sync with @Param generate above... >>>>> switch (types) { >>>>> case "LL": return Object.class; >>>>> case "LLL": return Serializable.class; >>>>> case "LLLL": return Iterator.class; >>>>> case "LLLLL": return Throwable.class; >>>>> case "LLLLLL": return String.class; >>>>> default: return null; >>>>> } >>>>> } >>>>> >>>>> // copied from non-public LambdaForm >>>>> static String shortenSignature(String signature) { >>>>> // Hack to make signatures more readable when they show up >>>>> in method names. >>>>> final int NO_CHAR = -1, MIN_RUN = 3; >>>>> int c0, c1 = NO_CHAR, c1reps = 0; >>>>> StringBuilder buf = null; >>>>> int len = signature.length(); >>>>> if (len < MIN_RUN) return signature; >>>>> for (int i = 0; i <= len; i++) { >>>>> // shift in the next char: >>>>> c0 = c1; c1 = (i == len ? NO_CHAR : signature.charAt(i)); >>>>> if (c1 == c0) { ++c1reps; continue; } >>>>> // shift in the next count: >>>>> int c0reps = c1reps; c1reps = 1; >>>>> // end of a character run >>>>> if (c0reps < MIN_RUN) { >>>>> if (buf != null) { >>>>> while (--c0reps >= 0) >>>>> buf.append((char) c0); >>>>> } >>>>> continue; >>>>> } >>>>> // found three or more in a row >>>>> if (buf == null) >>>>> buf = new StringBuilder().append(signature, 0, i - >>>>> c0reps); >>>>> buf.append((char) c0).append(c0reps); >>>>> } >>>>> return (buf == null) ? signature : buf.toString(); >>>>> } >>>>> } >>>>> >>>>> >>>>> >>>>> Regards, Peter >>>>> >>>>>> >>>>>> All-in-all I lean towards moving forward with the first, simpler >>>>>> revision of this >>>>>> patch[1] and then evaluate if webrev.02 or a String-switch+static >>>>>> resolve >>>>>> as a follow-up. >>>>>> >>>>>> A compromise would be to keep the SpeciesLookup class introduced >>>>>> here >>>>>> to allow removing all overhead in case the plugin is disabled. >>>>>> >>>>>> Mandy: I've not found any test (under jdk/test/tools/jlink or >>>>>> elsewhere) which >>>>>> has to be updated when adding a plugin like this. >>>>>> >>>>>> Thanks! >>>>>> >>>>>> /Claes >>>>>> >>>>>> [1] http://cr.openjdk.java.net/~redestad/8152641/webrev.01/ >>>>> >>>> >>> >> > From tomas.zezula at oracle.com Wed Mar 30 15:55:03 2016 From: tomas.zezula at oracle.com (Tomas Zezula) Date: Wed, 30 Mar 2016 17:55:03 +0200 Subject: Jigsaw + Ant In-Reply-To: <867636023.1980264.1459329484654.JavaMail.zimbra@u-pem.fr> References: <1FA6EB1D-7DE3-4200-A8D4-3DB77FC4E2D5@oracle.com> <867636023.1980264.1459329484654.JavaMail.zimbra@u-pem.fr> Message-ID: <58DF2822-BE48-4C92-800E-2CD41F40EC5C@oracle.com> Hi R?mi, I plan to work on the jar and jlink tasks. But now I am evaluating how to run JUnit tests of a modular project using Ant?s JUnit task. It seems that it also requires changes in the Ant. ? Tomas > On 30 Mar 2016, at 11:18, Remi Forax wrote: > > Hi Tomas, > many thanks for your work, > it seems, i will be able to ditch the shell scripts i currently used soon :) > > May i ask you to also add the support for modules in the jar task and to create a jlink task ? > > regards, > R?mi > > ----- Mail original ----- >> De: "Tomas Zezula" >> ?: jigsaw-dev at openjdk.java.net >> Envoy?: Mercredi 30 Mars 2016 07:53:56 >> Objet: Jigsaw + Ant >> >> Hi All, >> the Ant 1.9.7alpha (https://ant.apache.org/nightlies.html) now supports >> modules in the Javac and Java tasks. >> >> The Javac single module compilation example: >> >> > destdir="${build}" >> includeantruntime="false" >> modulepath="modules" >> source="9" >> /> >> >> >> The Javac multi-module compilation example: >> >> > destdir="${build}" >> includeantruntime="false" >> modulepath="modules" >> source="9" >> /> >> >> The main module execution example: >> >> > module="TestModule" >> modulepath="lib:dist/test.jar?/> >> >> An execution of an explicit main class in a module: >> >> > module="TestModule" >> classname="Main"> >> >> >> >> >> >> >> >> ? Tomas From claes.redestad at oracle.com Wed Mar 30 16:17:39 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 30 Mar 2016 18:17:39 +0200 Subject: RFR: 8152641: Plugin to generate BMH$Species classes ahead-of-time In-Reply-To: <56FBEE08.7010600@gmail.com> References: <56F3EEAB.4090600@oracle.com> <1FE3F7A6-1C7B-4DC6-875C-E3FAEDED08F5@oracle.com> <56F50EC5.6020500@gmail.com> <56F5520D.3080205@oracle.com> <56F676CA.5000803@gmail.com> <56FB09D3.4090000@oracle.com> <56FB82FE.5010209@gmail.com> <56FB8607.8030000@gmail.com> <56FBB014.6050002@oracle.com> <56FBC4D8.8010603@gmail.com> <56FBDF98.4090102@oracle.com> <56FBEE08.7010600@gmail.com> Message-ID: <56FBFC23.5090104@oracle.com> Hi Peter, something like this, then: http://cr.openjdk.java.net/~redestad/8152641/webrev.05/ - Added a method only used by the plugin which validates input; added a comment about the dependency - Invalid types are logged but otherwise ignored now (I bet someone might suggest a better way to handle user errors) - Some cleanup, introduced constant for class name prefix and removed duplicate type string shortening etc /Claes On 2016-03-30 17:17, Peter Levart wrote: > Hi Claes, > > webrev.04 looks good now. > > Maybe just one nit. For production quality, plugin input could be > verified that after expansion it is composed of just the following > characters: "LIJFD". Otherwise ClassWriter might generate an unusable > class without complaining (for example if someone sneaks-in characters > 'S' 'Z' 'B' or 'C')... > > Or, better yet, create another method in BMH that will be the "public" > API between the plugin and BMH which does the validation and calls > generateConcreteBMHClassBytes(). Internally in BMH the validation is > not necessary as the types strings are composed programmatically and > are guaranteed to be correct. > > Regards, Peter > > On 03/30/2016 04:15 PM, Claes Redestad wrote: >> >> >> On 2016-03-30 14:21, Peter Levart wrote: >>> Hi Claes, >>> >>> On 03/30/2016 12:53 PM, Claes Redestad wrote: >>>> Hi, >>>> >>>> I think Class.forName(Module, String) seemed like a nice >>>> efficiency/simplicity compromise, but there is some usage of >>>> lambdas/method-refs in the Module lookup code, especially for >>>> exploded modules (which get exercised during JDK build). Depending >>>> on a lambda from code in java.lang.invoke means we fail to bootstrap. >>>> >>>> But hey, we're living in an encapsulated world now, and this is in >>>> java.base, so why not go directly to the BootLoader: >>>> >>>> http://cr.openjdk.java.net/~redestad/8152641/webrev.03/ >>>> >>>> Since this is what's called from Class.forName(Module, String), the >>>> overhead should be even smaller than in your classForNameInModule test. >>> >>> Good idea. >>> >>>> >>>> If I call this final, will you say "Reviewed"? :-) >>> >>> Sorry, I don't posses the powers. :-) >>> >>> I could say "rEVIEWED", but... >>> >>> In the plugin, the input is shortened speciesTypes strings. What >>> guarantees that they really are normalized? For example, If one >>> specifies "LLL" as input, it will get expanded into "LLL", the >>> generated class will have "_L3" as a name suffix, but you will pack >>> it in the image with "_LLL.class" filename suffix. >>> >>> That's another reason why a method in BoundMethodHandle$Factory with >>> the following signature: >>> >>> Map.Entry generateConcreteBMHClassBytes(String types); >>> >>> ...would be a good idea. It would return class bytes and the name of >>> the class which you could use to derive the class filename without >>> hardcoding the same logic in plugin and in BMH. >>> >>> You just move the "LambdaForm.shortenSignature(types)" from >>> getConcreteBMHClass and className/sourceFile calculation from >>> generateConcreteBMHClass down to generateConcreteBMHClassBytes >>> method and change the signatures... >> >> Yes, it makes sense to keep control over the class name inside the >> factory class, and this does allow specifying shortened or expanded >> forms (L3 vs LLL) interchangeably as input to the plugin, which >> reduces possibility for user errors. >> >> How about this: http://cr.openjdk.java.net/~redestad/8152641/webrev.04/ >> >> /Claes >> >>> >>> Regards, Peter >>> >>>> >>>> /Claes >>>> >>>> PS: The default list of types is generated in a few adhoc tests not >>>> part of this patch. I'm considering proposing add support for >>>> generating this list at build time. Maybe a JEP called "Build >>>> system support for profile-guided optimizations", which could also >>>> handle https://bugs.openjdk.java.net/browse/JDK-8150044 >>>> >>>> On 2016-03-30 09:53, Peter Levart wrote: >>>>> Hi Claes, >>>>> >>>>> Sorry, I found a flaw in the benchmark (the regex pattern to split >>>>> comma-separated string into substrings was wrong). What the >>>>> benchmark did was compare the overheads of a single lookup of a >>>>> longer class name containing commas. Here's the corrected result >>>>> of overheads of 5 unsuccessful lookups: >>>>> >>>>> Benchmark (generate) (lookup) Mode Cnt >>>>> Score Error Units >>>>> ClassForNameBench.classForName LL,LLL,LLLL,LLLLL,LLLLLL >>>>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 29627.141 ? 567.427 ns/op >>>>> ClassForNameBench.classForNameInModule LL,LLL,LLLL,LLLLL,LLLLLL >>>>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 1073.256 ? 23.794 ns/op >>>>> ClassForNameBench.hashSetContains LL,LLL,LLLL,LLLLL,LLLLLL >>>>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 33.022 ? 0.066 ns/op >>>>> ClassForNameBench.switchStatement LL,LLL,LLLL,LLLLL,LLLLLL >>>>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 38.498 ? 5.842 ns/op >>>>> >>>>> ...overheads are a little bigger (x5 approx.). >>>>> >>>>> >>>>> Here's the corrected benchmark: >>>>> >>>>> >>>>> package jdk.test; >>>>> >>>>> import org.openjdk.jmh.annotations.*; >>>>> import org.openjdk.jmh.infra.Blackhole; >>>>> >>>>> import java.io.Serializable; >>>>> import java.lang.invoke.MethodHandle; >>>>> import java.util.Iterator; >>>>> import java.util.Set; >>>>> import java.util.concurrent.TimeUnit; >>>>> import java.util.stream.Collectors; >>>>> import java.util.stream.Stream; >>>>> >>>>> @BenchmarkMode(Mode.AverageTime) >>>>> @Fork(value = 1, warmups = 0) >>>>> @Warmup(iterations = 10) >>>>> @Measurement(iterations = 10) >>>>> @OutputTimeUnit(TimeUnit.NANOSECONDS) >>>>> @State(Scope.Thread) >>>>> public class ClassForNameBench { >>>>> >>>>> static final String BMH = "java/lang/invoke/BoundMethodHandle"; >>>>> static final String SPECIES_PREFIX_NAME = "Species_"; >>>>> static final String SPECIES_PREFIX_PATH = BMH + "$" + >>>>> SPECIES_PREFIX_NAME; >>>>> >>>>> @Param({"LL,LLL,LLLL,LLLLL,LLLLLL"}) >>>>> public String generate; >>>>> >>>>> @Param({"LLI,LLLI,LLLLI,LLLLLI,LLLLLLI"}) >>>>> public String lookup; >>>>> >>>>> private String[] generatedTypes; >>>>> private String[] lookedUpTypes; >>>>> private Set generatedNames; >>>>> private String[] lookedUpNames; >>>>> >>>>> @Setup(Level.Trial) >>>>> public void setup() { >>>>> generatedTypes = generate.trim().split("\\s*,\\s*"); >>>>> lookedUpTypes = lookup.trim().split("\\s*,\\s*"); >>>>> generatedNames = Stream.of(generatedTypes) >>>>> .map(types -> SPECIES_PREFIX_PATH + >>>>> shortenSignature(types)) >>>>> .collect(Collectors.toSet()); >>>>> lookedUpNames = Stream.of(lookedUpTypes) >>>>> .map(types -> SPECIES_PREFIX_PATH + >>>>> shortenSignature(types)) >>>>> .toArray(String[]::new); >>>>> } >>>>> >>>>> @Benchmark >>>>> public void classForName(Blackhole bh) { >>>>> for (String name : lookedUpNames) { >>>>> try { >>>>> bh.consume(Class.forName(name, false, >>>>> MethodHandle.class.getClassLoader())); >>>>> } catch (ClassNotFoundException e) { >>>>> bh.consume(e); >>>>> } >>>>> } >>>>> } >>>>> >>>>> @Benchmark >>>>> public void classForNameInModule(Blackhole bh) { >>>>> for (String name : lookedUpNames) { >>>>> bh.consume(Class.forName(MethodHandle.class.getModule(), name)); >>>>> } >>>>> } >>>>> >>>>> @Benchmark >>>>> public void hashSetContains(Blackhole bh) { >>>>> for (String name : lookedUpNames) { >>>>> bh.consume(generatedNames.contains(name)); >>>>> } >>>>> } >>>>> >>>>> @Benchmark >>>>> public void switchStatement(Blackhole bh) { >>>>> for (String types : lookedUpTypes) { >>>>> bh.consume(getBMHSwitch(types)); >>>>> } >>>>> } >>>>> >>>>> static Class getBMHSwitch(String types) { >>>>> // should be in sync with @Param generate above... >>>>> switch (types) { >>>>> case "LL": return Object.class; >>>>> case "LLL": return Serializable.class; >>>>> case "LLLL": return Iterator.class; >>>>> case "LLLLL": return Throwable.class; >>>>> case "LLLLLL": return String.class; >>>>> default: return null; >>>>> } >>>>> } >>>>> >>>>> // copied from non-public LambdaForm >>>>> static String shortenSignature(String signature) { >>>>> // Hack to make signatures more readable when they show up >>>>> in method names. >>>>> final int NO_CHAR = -1, MIN_RUN = 3; >>>>> int c0, c1 = NO_CHAR, c1reps = 0; >>>>> StringBuilder buf = null; >>>>> int len = signature.length(); >>>>> if (len < MIN_RUN) return signature; >>>>> for (int i = 0; i <= len; i++) { >>>>> // shift in the next char: >>>>> c0 = c1; c1 = (i == len ? NO_CHAR : signature.charAt(i)); >>>>> if (c1 == c0) { ++c1reps; continue; } >>>>> // shift in the next count: >>>>> int c0reps = c1reps; c1reps = 1; >>>>> // end of a character run >>>>> if (c0reps < MIN_RUN) { >>>>> if (buf != null) { >>>>> while (--c0reps >= 0) >>>>> buf.append((char) c0); >>>>> } >>>>> continue; >>>>> } >>>>> // found three or more in a row >>>>> if (buf == null) >>>>> buf = new StringBuilder().append(signature, 0, i - >>>>> c0reps); >>>>> buf.append((char) c0).append(c0reps); >>>>> } >>>>> return (buf == null) ? signature : buf.toString(); >>>>> } >>>>> } >>>>> >>>>> >>>>> Regards, Peter >>>>> >>>>> >>>>> >>>>> On 03/30/2016 09:40 AM, Peter Levart wrote: >>>>>> Hi Claes, >>>>>> >>>>>> On 03/30/2016 01:03 AM, Claes Redestad wrote: >>>>>>> Hi Peter, Mandy, >>>>>>> >>>>>>> On 2016-03-26 12:47, Peter Levart wrote: >>>>>>>> >>>>>>>> Comparing this with proposed code from webrev: >>>>>>>> >>>>>>>> 493 try { >>>>>>>> 494 return (Class>>>>>>> BoundMethodHandle>) >>>>>>>> 495 >>>>>>>> Class.forName("java.lang.invoke.BoundMethodHandle$Species_" + >>>>>>>> LambdaForm.shortenSignature(types)); >>>>>>>> 496 } catch (ClassNotFoundException cnf) { >>>>>>>> 497 // Not pregenerated, generate >>>>>>>> the class >>>>>>>> 498 return >>>>>>>> generateConcreteBMHClass(types); >>>>>>>> 499 } >>>>>>>> >>>>>>>> >>>>>>>> ...note that the function passed to CLASS_CACHE.computeIfAbsent >>>>>>>> is executed just once per distinct 'types' argument. Even if >>>>>>>> you put the generated switch between a call to >>>>>>>> getConcreteBMHClass and CLASS_CACHE.computeIfAbsent, >>>>>>>> getConcreteBMHClass(String types) is executed just once per >>>>>>>> distinct 'types' argument (except in rare occasions when VM can >>>>>>>> not initialize the loaded class). >>>>>>>> >>>>>>>> In this respect a successful Class.forName() is not any worse >>>>>>>> than static resolving. It's just that unsuccessful >>>>>>>> Class.forName() represents some overhead for classes that are >>>>>>>> not pre-generated. So an alternative way to get rid of that >>>>>>>> overhead is to have a HashSet of 'types' strings for >>>>>>>> pre-generated classes at hand in order to decide whether to >>>>>>>> call Class.forName or generateConcreteBMHClass. >>>>>>>> >>>>>>>> What's easier to support is another question. >>>>>>>> >>>>>>>> Regards, Peter >>>>>>> >>>>>>> to have something to compare with I built a version which, like >>>>>>> you suggest, >>>>>>> generates a HashSet with the set of generated classes here: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~redestad/8152641/webrev.02/ >>>>>>> >>>>>>> This adds a fair bit of complexity to the plugin and requires we >>>>>>> add a nested >>>>>>> class in BoundMethodHandle that we can replace. Using the anonymous >>>>>>> compute Function for this seems like the best choice for this. >>>>>> >>>>>> ...what I had in mind as alternative to a pregenerated class with >>>>>> a switch was a simple textual resource file, generated by plugin, >>>>>> read-in by BMH into a HashSet. No special-purpose class >>>>>> generation and much less complexity for the plugin. >>>>>> >>>>>>> >>>>>>> I've not been able to measure any statistical difference in real >>>>>>> startup terms, >>>>>>> though, and not figured out a smart way to benchmark the >>>>>>> overhead of the >>>>>>> CNFE in relation to the class generation (my guess it adds a >>>>>>> fraction to the >>>>>>> total cost) and since this adds ever so little footprint and an >>>>>>> extra lookup to the >>>>>>> fast path it would seem that this is the wrong trade-off to do here. >>>>>> >>>>>> Yes, perhaps it would be best to just use Class.forName(module, >>>>>> className) instead. I have created a little benchmark to compare >>>>>> overheads (just overheads) of unsuccessful lookups for >>>>>> pregenerated classes (a situation where a BMH class is requested >>>>>> that has not been pregenerated) and here's the result for >>>>>> overhead of 5 unsuccessfull lookups: >>>>>> >>>>>> Benchmark (generate) (lookup) Mode Cnt >>>>>> Score Error Units >>>>>> ClassForNameBench.classForName LL,LLL,LLLL,LLLLL,LLLLLL >>>>>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 6800.878 ? 421.424 ns/op >>>>>> ClassForNameBench.classForNameInModule LL,LLL,LLLL,LLLLL,LLLLLL >>>>>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 209.574 ? 2.114 ns/op >>>>>> ClassForNameBench.hashSetContains LL,LLL,LLLL,LLLLL,LLLLLL >>>>>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 6.813 ? 0.317 ns/op >>>>>> ClassForNameBench.switchStatement LL,LLL,LLLL,LLLLL,LLLLLL >>>>>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 6.601 ? 0.061 ns/op >>>>>> >>>>>> ...compared to runtime BMH class generation and loading this is >>>>>> really a very minor overhead. I would just use >>>>>> Class.forName(module, className) and reduce the complexity of the >>>>>> plugin. >>>>>> >>>>>> What do you think? >>>>>> >>>>>> >>>>>> Here's the benchmark: >>>>>> >>>>>> package jdk.test; >>>>>> >>>>>> import org.openjdk.jmh.annotations.*; >>>>>> import org.openjdk.jmh.infra.Blackhole; >>>>>> >>>>>> import java.io.Serializable; >>>>>> import java.lang.invoke.MethodHandle; >>>>>> import java.util.Iterator; >>>>>> import java.util.Set; >>>>>> import java.util.concurrent.TimeUnit; >>>>>> import java.util.stream.Collectors; >>>>>> import java.util.stream.Stream; >>>>>> >>>>>> @BenchmarkMode(Mode.AverageTime) >>>>>> @Fork(value = 1, warmups = 0) >>>>>> @Warmup(iterations = 10) >>>>>> @Measurement(iterations = 10) >>>>>> @OutputTimeUnit(TimeUnit.NANOSECONDS) >>>>>> @State(Scope.Thread) >>>>>> public class ClassForNameBench { >>>>>> >>>>>> static final String BMH = "java/lang/invoke/BoundMethodHandle"; >>>>>> static final String SPECIES_PREFIX_NAME = "Species_"; >>>>>> static final String SPECIES_PREFIX_PATH = BMH + "$" + >>>>>> SPECIES_PREFIX_NAME; >>>>>> >>>>>> @Param({"LL,LLL,LLLL,LLLLL,LLLLLL"}) >>>>>> public String generate; >>>>>> >>>>>> @Param({"LLI,LLLI,LLLLI,LLLLLI,LLLLLLI"}) >>>>>> public String lookup; >>>>>> >>>>>> private String[] generatedTypes; >>>>>> private String[] lookedUpTypes; >>>>>> private Set generatedNames; >>>>>> private String[] lookedUpNames; >>>>>> >>>>>> @Setup(Level.Trial) >>>>>> public void setup() { >>>>>> generatedTypes = generate.trim().split("\\s+,\\s+"); >>>>>> lookedUpTypes = lookup.trim().split("\\s+,\\s+"); >>>>>> generatedNames = Stream.of(generatedTypes) >>>>>> .map(types -> SPECIES_PREFIX_PATH >>>>>> + shortenSignature(types)) >>>>>> .collect(Collectors.toSet()); >>>>>> lookedUpNames = Stream.of(lookedUpTypes) >>>>>> .map(types -> SPECIES_PREFIX_PATH + >>>>>> shortenSignature(types)) >>>>>> .toArray(String[]::new); >>>>>> } >>>>>> >>>>>> @Benchmark >>>>>> public void classForName(Blackhole bh) { >>>>>> for (String name : lookedUpNames) { >>>>>> try { >>>>>> bh.consume(Class.forName(name, false, >>>>>> MethodHandle.class.getClassLoader())); >>>>>> } catch (ClassNotFoundException e) { >>>>>> bh.consume(e); >>>>>> } >>>>>> } >>>>>> } >>>>>> >>>>>> @Benchmark >>>>>> public void classForNameInModule(Blackhole bh) { >>>>>> for (String name : lookedUpNames) { >>>>>> bh.consume(Class.forName(MethodHandle.class.getModule(), name)); >>>>>> } >>>>>> } >>>>>> >>>>>> @Benchmark >>>>>> public void hashSetContains(Blackhole bh) { >>>>>> for (String name : lookedUpNames) { >>>>>> bh.consume(generatedNames.contains(name)); >>>>>> } >>>>>> } >>>>>> >>>>>> @Benchmark >>>>>> public void switchStatement(Blackhole bh) { >>>>>> for (String types : lookedUpTypes) { >>>>>> bh.consume(getBMHSwitch(types)); >>>>>> } >>>>>> } >>>>>> >>>>>> static Class getBMHSwitch(String types) { >>>>>> // should be in sync with @Param generate above... >>>>>> switch (types) { >>>>>> case "LL": return Object.class; >>>>>> case "LLL": return Serializable.class; >>>>>> case "LLLL": return Iterator.class; >>>>>> case "LLLLL": return Throwable.class; >>>>>> case "LLLLLL": return String.class; >>>>>> default: return null; >>>>>> } >>>>>> } >>>>>> >>>>>> // copied from non-public LambdaForm >>>>>> static String shortenSignature(String signature) { >>>>>> // Hack to make signatures more readable when they show >>>>>> up in method names. >>>>>> final int NO_CHAR = -1, MIN_RUN = 3; >>>>>> int c0, c1 = NO_CHAR, c1reps = 0; >>>>>> StringBuilder buf = null; >>>>>> int len = signature.length(); >>>>>> if (len < MIN_RUN) return signature; >>>>>> for (int i = 0; i <= len; i++) { >>>>>> // shift in the next char: >>>>>> c0 = c1; c1 = (i == len ? NO_CHAR : signature.charAt(i)); >>>>>> if (c1 == c0) { ++c1reps; continue; } >>>>>> // shift in the next count: >>>>>> int c0reps = c1reps; c1reps = 1; >>>>>> // end of a character run >>>>>> if (c0reps < MIN_RUN) { >>>>>> if (buf != null) { >>>>>> while (--c0reps >= 0) >>>>>> buf.append((char) c0); >>>>>> } >>>>>> continue; >>>>>> } >>>>>> // found three or more in a row >>>>>> if (buf == null) >>>>>> buf = new StringBuilder().append(signature, 0, i >>>>>> - c0reps); >>>>>> buf.append((char) c0).append(c0reps); >>>>>> } >>>>>> return (buf == null) ? signature : buf.toString(); >>>>>> } >>>>>> } >>>>>> >>>>>> >>>>>> >>>>>> Regards, Peter >>>>>> >>>>>>> >>>>>>> All-in-all I lean towards moving forward with the first, simpler >>>>>>> revision of this >>>>>>> patch[1] and then evaluate if webrev.02 or a >>>>>>> String-switch+static resolve >>>>>>> as a follow-up. >>>>>>> >>>>>>> A compromise would be to keep the SpeciesLookup class introduced >>>>>>> here >>>>>>> to allow removing all overhead in case the plugin is disabled. >>>>>>> >>>>>>> Mandy: I've not found any test (under jdk/test/tools/jlink or >>>>>>> elsewhere) which >>>>>>> has to be updated when adding a plugin like this. >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> /Claes >>>>>>> >>>>>>> [1] http://cr.openjdk.java.net/~redestad/8152641/webrev.01/ >>>>>> >>>>> >>>> >>> >> > From vladimir.x.ivanov at oracle.com Wed Mar 30 17:11:19 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 30 Mar 2016 20:11:19 +0300 Subject: RFR: 8152641: Plugin to generate BMH$Species classes ahead-of-time In-Reply-To: <56FBFC23.5090104@oracle.com> References: <56F3EEAB.4090600@oracle.com> <1FE3F7A6-1C7B-4DC6-875C-E3FAEDED08F5@oracle.com> <56F50EC5.6020500@gmail.com> <56F5520D.3080205@oracle.com> <56F676CA.5000803@gmail.com> <56FB09D3.4090000@oracle.com> <56FB82FE.5010209@gmail.com> <56FB8607.8030000@gmail.com> <56FBB014.6050002@oracle.com> <56FBC4D8.8010603@gmail.com> <56FBDF98.4090102@oracle.com> <56FBEE08.7010600@gmail.com> <56FBFC23.5090104@oracle.com> Message-ID: <56FC08B7.5010504@oracle.com> Nice work, Claes! j.l.i part looks fine. Best regards, Vladimir Ivanov On 3/30/16 7:17 PM, Claes Redestad wrote: > Hi Peter, > > something like this, then: > > http://cr.openjdk.java.net/~redestad/8152641/webrev.05/ > > - Added a method only used by the plugin which validates input; added a > comment about the dependency > - Invalid types are logged but otherwise ignored now (I bet someone > might suggest a better way to handle user errors) > - Some cleanup, introduced constant for class name prefix and removed > duplicate type string shortening etc > > /Claes > > On 2016-03-30 17:17, Peter Levart wrote: >> Hi Claes, >> >> webrev.04 looks good now. >> >> Maybe just one nit. For production quality, plugin input could be >> verified that after expansion it is composed of just the following >> characters: "LIJFD". Otherwise ClassWriter might generate an unusable >> class without complaining (for example if someone sneaks-in characters >> 'S' 'Z' 'B' or 'C')... >> >> Or, better yet, create another method in BMH that will be the "public" >> API between the plugin and BMH which does the validation and calls >> generateConcreteBMHClassBytes(). Internally in BMH the validation is >> not necessary as the types strings are composed programmatically and >> are guaranteed to be correct. >> >> Regards, Peter >> >> On 03/30/2016 04:15 PM, Claes Redestad wrote: >>> >>> >>> On 2016-03-30 14:21, Peter Levart wrote: >>>> Hi Claes, >>>> >>>> On 03/30/2016 12:53 PM, Claes Redestad wrote: >>>>> Hi, >>>>> >>>>> I think Class.forName(Module, String) seemed like a nice >>>>> efficiency/simplicity compromise, but there is some usage of >>>>> lambdas/method-refs in the Module lookup code, especially for >>>>> exploded modules (which get exercised during JDK build). Depending >>>>> on a lambda from code in java.lang.invoke means we fail to bootstrap. >>>>> >>>>> But hey, we're living in an encapsulated world now, and this is in >>>>> java.base, so why not go directly to the BootLoader: >>>>> >>>>> http://cr.openjdk.java.net/~redestad/8152641/webrev.03/ >>>>> >>>>> Since this is what's called from Class.forName(Module, String), the >>>>> overhead should be even smaller than in your classForNameInModule >>>>> test. >>>> >>>> Good idea. >>>> >>>>> >>>>> If I call this final, will you say "Reviewed"? :-) >>>> >>>> Sorry, I don't posses the powers. :-) >>>> >>>> I could say "rEVIEWED", but... >>>> >>>> In the plugin, the input is shortened speciesTypes strings. What >>>> guarantees that they really are normalized? For example, If one >>>> specifies "LLL" as input, it will get expanded into "LLL", the >>>> generated class will have "_L3" as a name suffix, but you will pack >>>> it in the image with "_LLL.class" filename suffix. >>>> >>>> That's another reason why a method in BoundMethodHandle$Factory with >>>> the following signature: >>>> >>>> Map.Entry generateConcreteBMHClassBytes(String types); >>>> >>>> ...would be a good idea. It would return class bytes and the name of >>>> the class which you could use to derive the class filename without >>>> hardcoding the same logic in plugin and in BMH. >>>> >>>> You just move the "LambdaForm.shortenSignature(types)" from >>>> getConcreteBMHClass and className/sourceFile calculation from >>>> generateConcreteBMHClass down to generateConcreteBMHClassBytes >>>> method and change the signatures... >>> >>> Yes, it makes sense to keep control over the class name inside the >>> factory class, and this does allow specifying shortened or expanded >>> forms (L3 vs LLL) interchangeably as input to the plugin, which >>> reduces possibility for user errors. >>> >>> How about this: http://cr.openjdk.java.net/~redestad/8152641/webrev.04/ >>> >>> /Claes >>> >>>> >>>> Regards, Peter >>>> >>>>> >>>>> /Claes >>>>> >>>>> PS: The default list of types is generated in a few adhoc tests not >>>>> part of this patch. I'm considering proposing add support for >>>>> generating this list at build time. Maybe a JEP called "Build >>>>> system support for profile-guided optimizations", which could also >>>>> handle https://bugs.openjdk.java.net/browse/JDK-8150044 >>>>> >>>>> On 2016-03-30 09:53, Peter Levart wrote: >>>>>> Hi Claes, >>>>>> >>>>>> Sorry, I found a flaw in the benchmark (the regex pattern to split >>>>>> comma-separated string into substrings was wrong). What the >>>>>> benchmark did was compare the overheads of a single lookup of a >>>>>> longer class name containing commas. Here's the corrected result >>>>>> of overheads of 5 unsuccessful lookups: >>>>>> >>>>>> Benchmark (generate) (lookup) Mode Cnt >>>>>> Score Error Units >>>>>> ClassForNameBench.classForName LL,LLL,LLLL,LLLLL,LLLLLL >>>>>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 29627.141 ? 567.427 ns/op >>>>>> ClassForNameBench.classForNameInModule LL,LLL,LLLL,LLLLL,LLLLLL >>>>>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 1073.256 ? 23.794 ns/op >>>>>> ClassForNameBench.hashSetContains LL,LLL,LLLL,LLLLL,LLLLLL >>>>>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 33.022 ? 0.066 ns/op >>>>>> ClassForNameBench.switchStatement LL,LLL,LLLL,LLLLL,LLLLLL >>>>>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 38.498 ? 5.842 ns/op >>>>>> >>>>>> ...overheads are a little bigger (x5 approx.). >>>>>> >>>>>> >>>>>> Here's the corrected benchmark: >>>>>> >>>>>> >>>>>> package jdk.test; >>>>>> >>>>>> import org.openjdk.jmh.annotations.*; >>>>>> import org.openjdk.jmh.infra.Blackhole; >>>>>> >>>>>> import java.io.Serializable; >>>>>> import java.lang.invoke.MethodHandle; >>>>>> import java.util.Iterator; >>>>>> import java.util.Set; >>>>>> import java.util.concurrent.TimeUnit; >>>>>> import java.util.stream.Collectors; >>>>>> import java.util.stream.Stream; >>>>>> >>>>>> @BenchmarkMode(Mode.AverageTime) >>>>>> @Fork(value = 1, warmups = 0) >>>>>> @Warmup(iterations = 10) >>>>>> @Measurement(iterations = 10) >>>>>> @OutputTimeUnit(TimeUnit.NANOSECONDS) >>>>>> @State(Scope.Thread) >>>>>> public class ClassForNameBench { >>>>>> >>>>>> static final String BMH = "java/lang/invoke/BoundMethodHandle"; >>>>>> static final String SPECIES_PREFIX_NAME = "Species_"; >>>>>> static final String SPECIES_PREFIX_PATH = BMH + "$" + >>>>>> SPECIES_PREFIX_NAME; >>>>>> >>>>>> @Param({"LL,LLL,LLLL,LLLLL,LLLLLL"}) >>>>>> public String generate; >>>>>> >>>>>> @Param({"LLI,LLLI,LLLLI,LLLLLI,LLLLLLI"}) >>>>>> public String lookup; >>>>>> >>>>>> private String[] generatedTypes; >>>>>> private String[] lookedUpTypes; >>>>>> private Set generatedNames; >>>>>> private String[] lookedUpNames; >>>>>> >>>>>> @Setup(Level.Trial) >>>>>> public void setup() { >>>>>> generatedTypes = generate.trim().split("\\s*,\\s*"); >>>>>> lookedUpTypes = lookup.trim().split("\\s*,\\s*"); >>>>>> generatedNames = Stream.of(generatedTypes) >>>>>> .map(types -> SPECIES_PREFIX_PATH + >>>>>> shortenSignature(types)) >>>>>> .collect(Collectors.toSet()); >>>>>> lookedUpNames = Stream.of(lookedUpTypes) >>>>>> .map(types -> SPECIES_PREFIX_PATH + >>>>>> shortenSignature(types)) >>>>>> .toArray(String[]::new); >>>>>> } >>>>>> >>>>>> @Benchmark >>>>>> public void classForName(Blackhole bh) { >>>>>> for (String name : lookedUpNames) { >>>>>> try { >>>>>> bh.consume(Class.forName(name, false, >>>>>> MethodHandle.class.getClassLoader())); >>>>>> } catch (ClassNotFoundException e) { >>>>>> bh.consume(e); >>>>>> } >>>>>> } >>>>>> } >>>>>> >>>>>> @Benchmark >>>>>> public void classForNameInModule(Blackhole bh) { >>>>>> for (String name : lookedUpNames) { >>>>>> bh.consume(Class.forName(MethodHandle.class.getModule(), name)); >>>>>> } >>>>>> } >>>>>> >>>>>> @Benchmark >>>>>> public void hashSetContains(Blackhole bh) { >>>>>> for (String name : lookedUpNames) { >>>>>> bh.consume(generatedNames.contains(name)); >>>>>> } >>>>>> } >>>>>> >>>>>> @Benchmark >>>>>> public void switchStatement(Blackhole bh) { >>>>>> for (String types : lookedUpTypes) { >>>>>> bh.consume(getBMHSwitch(types)); >>>>>> } >>>>>> } >>>>>> >>>>>> static Class getBMHSwitch(String types) { >>>>>> // should be in sync with @Param generate above... >>>>>> switch (types) { >>>>>> case "LL": return Object.class; >>>>>> case "LLL": return Serializable.class; >>>>>> case "LLLL": return Iterator.class; >>>>>> case "LLLLL": return Throwable.class; >>>>>> case "LLLLLL": return String.class; >>>>>> default: return null; >>>>>> } >>>>>> } >>>>>> >>>>>> // copied from non-public LambdaForm >>>>>> static String shortenSignature(String signature) { >>>>>> // Hack to make signatures more readable when they show up >>>>>> in method names. >>>>>> final int NO_CHAR = -1, MIN_RUN = 3; >>>>>> int c0, c1 = NO_CHAR, c1reps = 0; >>>>>> StringBuilder buf = null; >>>>>> int len = signature.length(); >>>>>> if (len < MIN_RUN) return signature; >>>>>> for (int i = 0; i <= len; i++) { >>>>>> // shift in the next char: >>>>>> c0 = c1; c1 = (i == len ? NO_CHAR : signature.charAt(i)); >>>>>> if (c1 == c0) { ++c1reps; continue; } >>>>>> // shift in the next count: >>>>>> int c0reps = c1reps; c1reps = 1; >>>>>> // end of a character run >>>>>> if (c0reps < MIN_RUN) { >>>>>> if (buf != null) { >>>>>> while (--c0reps >= 0) >>>>>> buf.append((char) c0); >>>>>> } >>>>>> continue; >>>>>> } >>>>>> // found three or more in a row >>>>>> if (buf == null) >>>>>> buf = new StringBuilder().append(signature, 0, i - >>>>>> c0reps); >>>>>> buf.append((char) c0).append(c0reps); >>>>>> } >>>>>> return (buf == null) ? signature : buf.toString(); >>>>>> } >>>>>> } >>>>>> >>>>>> >>>>>> Regards, Peter >>>>>> >>>>>> >>>>>> >>>>>> On 03/30/2016 09:40 AM, Peter Levart wrote: >>>>>>> Hi Claes, >>>>>>> >>>>>>> On 03/30/2016 01:03 AM, Claes Redestad wrote: >>>>>>>> Hi Peter, Mandy, >>>>>>>> >>>>>>>> On 2016-03-26 12:47, Peter Levart wrote: >>>>>>>>> >>>>>>>>> Comparing this with proposed code from webrev: >>>>>>>>> >>>>>>>>> 493 try { >>>>>>>>> 494 return (Class>>>>>>>> BoundMethodHandle>) >>>>>>>>> 495 >>>>>>>>> Class.forName("java.lang.invoke.BoundMethodHandle$Species_" + >>>>>>>>> LambdaForm.shortenSignature(types)); >>>>>>>>> 496 } catch (ClassNotFoundException >>>>>>>>> cnf) { >>>>>>>>> 497 // Not pregenerated, generate >>>>>>>>> the class >>>>>>>>> 498 return >>>>>>>>> generateConcreteBMHClass(types); >>>>>>>>> 499 } >>>>>>>>> >>>>>>>>> >>>>>>>>> ...note that the function passed to CLASS_CACHE.computeIfAbsent >>>>>>>>> is executed just once per distinct 'types' argument. Even if >>>>>>>>> you put the generated switch between a call to >>>>>>>>> getConcreteBMHClass and CLASS_CACHE.computeIfAbsent, >>>>>>>>> getConcreteBMHClass(String types) is executed just once per >>>>>>>>> distinct 'types' argument (except in rare occasions when VM can >>>>>>>>> not initialize the loaded class). >>>>>>>>> >>>>>>>>> In this respect a successful Class.forName() is not any worse >>>>>>>>> than static resolving. It's just that unsuccessful >>>>>>>>> Class.forName() represents some overhead for classes that are >>>>>>>>> not pre-generated. So an alternative way to get rid of that >>>>>>>>> overhead is to have a HashSet of 'types' strings for >>>>>>>>> pre-generated classes at hand in order to decide whether to >>>>>>>>> call Class.forName or generateConcreteBMHClass. >>>>>>>>> >>>>>>>>> What's easier to support is another question. >>>>>>>>> >>>>>>>>> Regards, Peter >>>>>>>> >>>>>>>> to have something to compare with I built a version which, like >>>>>>>> you suggest, >>>>>>>> generates a HashSet with the set of generated classes here: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~redestad/8152641/webrev.02/ >>>>>>>> >>>>>>>> This adds a fair bit of complexity to the plugin and requires we >>>>>>>> add a nested >>>>>>>> class in BoundMethodHandle that we can replace. Using the anonymous >>>>>>>> compute Function for this seems like the best choice for this. >>>>>>> >>>>>>> ...what I had in mind as alternative to a pregenerated class with >>>>>>> a switch was a simple textual resource file, generated by plugin, >>>>>>> read-in by BMH into a HashSet. No special-purpose class >>>>>>> generation and much less complexity for the plugin. >>>>>>> >>>>>>>> >>>>>>>> I've not been able to measure any statistical difference in real >>>>>>>> startup terms, >>>>>>>> though, and not figured out a smart way to benchmark the >>>>>>>> overhead of the >>>>>>>> CNFE in relation to the class generation (my guess it adds a >>>>>>>> fraction to the >>>>>>>> total cost) and since this adds ever so little footprint and an >>>>>>>> extra lookup to the >>>>>>>> fast path it would seem that this is the wrong trade-off to do >>>>>>>> here. >>>>>>> >>>>>>> Yes, perhaps it would be best to just use Class.forName(module, >>>>>>> className) instead. I have created a little benchmark to compare >>>>>>> overheads (just overheads) of unsuccessful lookups for >>>>>>> pregenerated classes (a situation where a BMH class is requested >>>>>>> that has not been pregenerated) and here's the result for >>>>>>> overhead of 5 unsuccessfull lookups: >>>>>>> >>>>>>> Benchmark (generate) (lookup) Mode Cnt >>>>>>> Score Error Units >>>>>>> ClassForNameBench.classForName LL,LLL,LLLL,LLLLL,LLLLLL >>>>>>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 6800.878 ? 421.424 ns/op >>>>>>> ClassForNameBench.classForNameInModule LL,LLL,LLLL,LLLLL,LLLLLL >>>>>>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 209.574 ? 2.114 ns/op >>>>>>> ClassForNameBench.hashSetContains LL,LLL,LLLL,LLLLL,LLLLLL >>>>>>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 6.813 ? 0.317 ns/op >>>>>>> ClassForNameBench.switchStatement LL,LLL,LLLL,LLLLL,LLLLLL >>>>>>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 6.601 ? 0.061 ns/op >>>>>>> >>>>>>> ...compared to runtime BMH class generation and loading this is >>>>>>> really a very minor overhead. I would just use >>>>>>> Class.forName(module, className) and reduce the complexity of the >>>>>>> plugin. >>>>>>> >>>>>>> What do you think? >>>>>>> >>>>>>> >>>>>>> Here's the benchmark: >>>>>>> >>>>>>> package jdk.test; >>>>>>> >>>>>>> import org.openjdk.jmh.annotations.*; >>>>>>> import org.openjdk.jmh.infra.Blackhole; >>>>>>> >>>>>>> import java.io.Serializable; >>>>>>> import java.lang.invoke.MethodHandle; >>>>>>> import java.util.Iterator; >>>>>>> import java.util.Set; >>>>>>> import java.util.concurrent.TimeUnit; >>>>>>> import java.util.stream.Collectors; >>>>>>> import java.util.stream.Stream; >>>>>>> >>>>>>> @BenchmarkMode(Mode.AverageTime) >>>>>>> @Fork(value = 1, warmups = 0) >>>>>>> @Warmup(iterations = 10) >>>>>>> @Measurement(iterations = 10) >>>>>>> @OutputTimeUnit(TimeUnit.NANOSECONDS) >>>>>>> @State(Scope.Thread) >>>>>>> public class ClassForNameBench { >>>>>>> >>>>>>> static final String BMH = "java/lang/invoke/BoundMethodHandle"; >>>>>>> static final String SPECIES_PREFIX_NAME = "Species_"; >>>>>>> static final String SPECIES_PREFIX_PATH = BMH + "$" + >>>>>>> SPECIES_PREFIX_NAME; >>>>>>> >>>>>>> @Param({"LL,LLL,LLLL,LLLLL,LLLLLL"}) >>>>>>> public String generate; >>>>>>> >>>>>>> @Param({"LLI,LLLI,LLLLI,LLLLLI,LLLLLLI"}) >>>>>>> public String lookup; >>>>>>> >>>>>>> private String[] generatedTypes; >>>>>>> private String[] lookedUpTypes; >>>>>>> private Set generatedNames; >>>>>>> private String[] lookedUpNames; >>>>>>> >>>>>>> @Setup(Level.Trial) >>>>>>> public void setup() { >>>>>>> generatedTypes = generate.trim().split("\\s+,\\s+"); >>>>>>> lookedUpTypes = lookup.trim().split("\\s+,\\s+"); >>>>>>> generatedNames = Stream.of(generatedTypes) >>>>>>> .map(types -> SPECIES_PREFIX_PATH >>>>>>> + shortenSignature(types)) >>>>>>> .collect(Collectors.toSet()); >>>>>>> lookedUpNames = Stream.of(lookedUpTypes) >>>>>>> .map(types -> SPECIES_PREFIX_PATH + >>>>>>> shortenSignature(types)) >>>>>>> .toArray(String[]::new); >>>>>>> } >>>>>>> >>>>>>> @Benchmark >>>>>>> public void classForName(Blackhole bh) { >>>>>>> for (String name : lookedUpNames) { >>>>>>> try { >>>>>>> bh.consume(Class.forName(name, false, >>>>>>> MethodHandle.class.getClassLoader())); >>>>>>> } catch (ClassNotFoundException e) { >>>>>>> bh.consume(e); >>>>>>> } >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> @Benchmark >>>>>>> public void classForNameInModule(Blackhole bh) { >>>>>>> for (String name : lookedUpNames) { >>>>>>> bh.consume(Class.forName(MethodHandle.class.getModule(), name)); >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> @Benchmark >>>>>>> public void hashSetContains(Blackhole bh) { >>>>>>> for (String name : lookedUpNames) { >>>>>>> bh.consume(generatedNames.contains(name)); >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> @Benchmark >>>>>>> public void switchStatement(Blackhole bh) { >>>>>>> for (String types : lookedUpTypes) { >>>>>>> bh.consume(getBMHSwitch(types)); >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> static Class getBMHSwitch(String types) { >>>>>>> // should be in sync with @Param generate above... >>>>>>> switch (types) { >>>>>>> case "LL": return Object.class; >>>>>>> case "LLL": return Serializable.class; >>>>>>> case "LLLL": return Iterator.class; >>>>>>> case "LLLLL": return Throwable.class; >>>>>>> case "LLLLLL": return String.class; >>>>>>> default: return null; >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> // copied from non-public LambdaForm >>>>>>> static String shortenSignature(String signature) { >>>>>>> // Hack to make signatures more readable when they show >>>>>>> up in method names. >>>>>>> final int NO_CHAR = -1, MIN_RUN = 3; >>>>>>> int c0, c1 = NO_CHAR, c1reps = 0; >>>>>>> StringBuilder buf = null; >>>>>>> int len = signature.length(); >>>>>>> if (len < MIN_RUN) return signature; >>>>>>> for (int i = 0; i <= len; i++) { >>>>>>> // shift in the next char: >>>>>>> c0 = c1; c1 = (i == len ? NO_CHAR : >>>>>>> signature.charAt(i)); >>>>>>> if (c1 == c0) { ++c1reps; continue; } >>>>>>> // shift in the next count: >>>>>>> int c0reps = c1reps; c1reps = 1; >>>>>>> // end of a character run >>>>>>> if (c0reps < MIN_RUN) { >>>>>>> if (buf != null) { >>>>>>> while (--c0reps >= 0) >>>>>>> buf.append((char) c0); >>>>>>> } >>>>>>> continue; >>>>>>> } >>>>>>> // found three or more in a row >>>>>>> if (buf == null) >>>>>>> buf = new StringBuilder().append(signature, 0, i >>>>>>> - c0reps); >>>>>>> buf.append((char) c0).append(c0reps); >>>>>>> } >>>>>>> return (buf == null) ? signature : buf.toString(); >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regards, Peter >>>>>>> >>>>>>>> >>>>>>>> All-in-all I lean towards moving forward with the first, simpler >>>>>>>> revision of this >>>>>>>> patch[1] and then evaluate if webrev.02 or a >>>>>>>> String-switch+static resolve >>>>>>>> as a follow-up. >>>>>>>> >>>>>>>> A compromise would be to keep the SpeciesLookup class introduced >>>>>>>> here >>>>>>>> to allow removing all overhead in case the plugin is disabled. >>>>>>>> >>>>>>>> Mandy: I've not found any test (under jdk/test/tools/jlink or >>>>>>>> elsewhere) which >>>>>>>> has to be updated when adding a plugin like this. >>>>>>>> >>>>>>>> Thanks! >>>>>>>> >>>>>>>> /Claes >>>>>>>> >>>>>>>> [1] http://cr.openjdk.java.net/~redestad/8152641/webrev.01/ >>>>>>> >>>>>> >>>>> >>>> >>> >> > From russell.gold at oracle.com Wed Mar 30 19:07:22 2016 From: russell.gold at oracle.com (Russell Gold) Date: Wed, 30 Mar 2016 15:07:22 -0400 Subject: modulepath and classpath mixture In-Reply-To: References: <56CC57A1.2050109@oracle.com> <56F2440A.7010505@oracle.com> <56F2914C.3030706@oracle.com> <56F2B3DA.402@oracle.com> <1228911717.349701.1459160027285.JavaMail.zimbra@u-pem.fr> <0CC4E4A6-4152-4BB0-BB42-B9E284540BB6@oracle.com> <6FB0B05A-6850-42F4-A6A3-42B7486CCDAA@oracle.com> Message-ID: Hi Paul, Why would you put your main code on the module path during a unit test? It seems to me that unit tests are explicitly about making sure that the code works, not the packaging. So you put both main and test code on the classpath, and there is no problem. The unit test can be done before the main code is packaged into a module. - Russ > On Mar 30, 2016, at 10:47 AM, Paul Benedict wrote: > > Russell, if you have a module with package X and a classpath jar with package X, the module can't see package X from the classpath. > > In the last several posts, there's been discussion on putting tests on the classpath; keeping the "main" code in the module. So given what I stated above, that's what I've been referring to. > > Cheers, > Paul > > On Wed, Mar 30, 2016 at 7:28 AM, Russell Gold > wrote: > Hi Paul, > > Could you explain? What kind of code do you mean cannot access it? And what do you mean by ?a split package situation?? > > From a conversation I had with Alan, earlier in this thread: > > >> On Mar 23, 2016, at 11:42 AM, Alan Bateman > wrote: >> >> On 23/03/2016 14:15, Russell Gold wrote: >>> Here are my assumptions, which you can correct. >>> >>> 1. A jar or classes directory placed on a class path are treated as part of the unnamed module >> Yes > > > So if the tests and main code are both in directories, which they have been up to now in Maven, why would there be a problem? Both would be in the unnamed module and able to access one another. > > - Russ > >> On Mar 29, 2016, at 10:47 PM, Paul Benedict > wrote: >> >> Russell, when you drop a jar on the classpath, module code will not be able to access it in a split package situation. That's the big barrier here. Maven test projects are typically written with the same package shared with the "main" code. >> >> Cheers, >> Paul >> >> On Tue, Mar 29, 2016 at 11:33 AM, Russell Gold > wrote: >> Hi Stephen, >> >> Why do you need any kind of friend access? >> >> It seems to me that this is making things harder than they need to be. The tests can simply run with the production code on the class path, and then there are no module issues at all. >> >> I think a larger problem is that you can do what I just said with the jars, even a jar which has been designated as a module by virtue of having a module-info.class in it. That means that, when users are up taking jars, they are not prevented from accessing module internals. They can put the jars on the module path, of course, but they can still use them on the class path! >> >> - Russ >> >> > >> > On 28 March 2016 at 11:13, Remi Forax > wrote: >> >> Hi Stephen, Hi all, >> >> I think that delivering tests as a separated module is a bad idea. >> >> >> >> I see that from the point of a developer, seeing the code and the test as different modules can be attractive because everything seems to be put at the right place but there is a big drawback. Because modules are reified at runtime, it means that the runtime environment of the tests will be different from the production environment. >> > >> > This last sentence doesn't make sense to me - tests are not run in a >> > production environment. >> > >> > Tests have all the qualities of modules - code, dependencies, >> > compilation phase, deployment. The only special part is the need for >> > special "friend-like" access, which Jigsaw already has for other cases >> > (the export...to clause). >> > >> > Put simply, I consider that module = >> > deployment-artifact-with-dependencies. With that mental model, putting >> > tests inside the module is just not acceptable, because tests should >> > not be deployed with the main application and they have different >> > dependencies. If we disagree that module = >> > deployment-artifact-with-dependencies, then perhaps we have bigger >> > problems to solve here. >> > >> > Stephen >> > (And to Paul Benedict, the classpath is going to die over time, so any >> > solution that uses that is flawed IMO). >> > >> > >> >> So as Alan said, from the jigsaw point of view at runtime, the tests and the code should be in the same module. >> >> >> >> So the building tools have to come with a way to support to have 2 different module-info.java in two different folders and package them as one module, >> >> maybe javac should help by providing a way to merge 2 module-info at compile time. >> >> >> >> R?mi >> >> >> >> ----- Mail original ----- >> >>> De: "Alan Bateman" > >> >>> ?: "Stephen Colebourne" >, "jigsaw-dev" > >> >>> Envoy?: Mercredi 23 Mars 2016 16:18:50 >> >>> Objet: Re: modulepath and classpath mixture >> >>> >> >>> >> >>> On 23/03/2016 14:42, Stephen Colebourne wrote: >> >>>> : >> >>>> >> >>>> I don't particularly care what the mechanism is for this, but at the >> >>>> requirements level: >> >>>> - there are two modules - main and test >> >>>> - each has its own source tree >> >>>> - each has its own dependencies >> >>>> - each is released separately >> >>>> - each could be hosted on a central repo >> >>>> - the test module needs to be able to contain the same packages as the >> >>>> main module >> >>>> - the test module needs to be able to invoke package-scoped code in >> >>>> the same package in the main module >> >>>> >> >>>> To clarify further consider 4 modules, A, B, A-test and B-test where B >> >>>> depends on A. Module A-test may have a method foo() that uses package >> >>>> scope to access something in A. Module B-test will depend on A-test >> >>>> and rely on foo() to get access to that internal object. >> >>> To your list, I would add the ability to make use of testing frameworks >> >>> like TestNG and JUnit. >> >>> >> >>> In any case, and as things currently stand, you've got most of the >> >>> above. One differences is that the tests are not a separate module, they >> >>> are instead compiled and run in a way that patches the main module. The >> >>> second difference is that they don't have their own module declaration, >> >>> instead the compilation or run augments the dependences with any >> >>> additional dependences that the tests have. As I said, if they tools >> >>> makes it easy then I don't think it's too bad. >> >>> >> >>>> >> >>>> (Note that I view the thread discussion of >> >>>> references to test classes on the classpath as another hack. >> >>>> >> >>> Packages can't be split between modules and classpath so there is no >> >>> support for that. >> >>> >> >>> -Alan >> >>> From pbenedict at apache.org Wed Mar 30 19:13:10 2016 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 30 Mar 2016 14:13:10 -0500 Subject: modulepath and classpath mixture In-Reply-To: References: <56CC57A1.2050109@oracle.com> <56F2440A.7010505@oracle.com> <56F2914C.3030706@oracle.com> <56F2B3DA.402@oracle.com> <1228911717.349701.1459160027285.JavaMail.zimbra@u-pem.fr> <0CC4E4A6-4152-4BB0-BB42-B9E284540BB6@oracle.com> <6FB0B05A-6850-42F4-A6A3-42B7486CCDAA@oracle.com> Message-ID: Russell, you ask a good question. If an artifact is meant to be a module, wouldn't it make sense for it to run as a module during testing too? Those boundaries should be activated like they are in production to get good confidence in the code. Those are my two cents. I'd like to hear opposing opinions though why the boundaries shouldn't be there. Cheers, Paul On Wed, Mar 30, 2016 at 2:07 PM, Russell Gold wrote: > Hi Paul, > > Why would you put your main code on the module path *during a unit test*? > It seems to me that unit tests are explicitly about making sure that the > code works, not the packaging. So you put both main and test code on the > classpath, and there is no problem. The unit test can be done before the > main code is packaged into a module. > > - Russ > > On Mar 30, 2016, at 10:47 AM, Paul Benedict wrote: > > Russell, if you have a module with package X and a classpath jar with > package X, the module can't see package X from the classpath. > > In the last several posts, there's been discussion on putting tests on the > classpath; keeping the "main" code in the module. So given what I stated > above, that's what I've been referring to. > > Cheers, > Paul > > On Wed, Mar 30, 2016 at 7:28 AM, Russell Gold > wrote: > >> Hi Paul, >> >> Could you explain? What kind of code do you mean cannot access it? And >> what do you mean by ?a split package situation?? >> >> From a conversation I had with Alan, earlier in this thread: >> >> >> On Mar 23, 2016, at 11:42 AM, Alan Bateman >> wrote: >> >> On 23/03/2016 14:15, Russell Gold wrote: >> >> Here are my assumptions, which you can correct. >> >> 1. A jar or classes directory placed on a class path are treated as part >> of the unnamed module >> >> Yes >> >> >> So if the tests and main code are both in directories, which they have >> been up to now in Maven, why would there be a problem? Both would be in the >> unnamed module and able to access one another. >> >> - Russ >> >> On Mar 29, 2016, at 10:47 PM, Paul Benedict wrote: >> >> Russell, when you drop a jar on the classpath, module code will not be >> able to access it in a split package situation. That's the big barrier >> here. Maven test projects are typically written with the same package >> shared with the "main" code. >> >> Cheers, >> Paul >> >> On Tue, Mar 29, 2016 at 11:33 AM, Russell Gold >> wrote: >> >>> Hi Stephen, >>> >>> Why do you need any kind of friend access? >>> >>> It seems to me that this is making things harder than they need to be. >>> The tests can simply run with the production code on the class path, and >>> then there are no module issues at all. >>> >>> I think a larger problem is that you can do what I just said with the >>> jars, even a jar which has been designated as a module by virtue of having >>> a module-info.class in it. That means that, when users are up taking jars, >>> they are not prevented from accessing module internals. They can put the >>> jars on the module path, of course, but they can still use them on the >>> class path! >>> >>> - Russ >>> >>> > >>> > On 28 March 2016 at 11:13, Remi Forax wrote: >>> >> Hi Stephen, Hi all, >>> >> I think that delivering tests as a separated module is a bad idea. >>> >> >>> >> I see that from the point of a developer, seeing the code and the >>> test as different modules can be attractive because everything seems to be >>> put at the right place but there is a big drawback. Because modules are >>> reified at runtime, it means that the runtime environment of the tests will >>> be different from the production environment. >>> > >>> > This last sentence doesn't make sense to me - tests are not run in a >>> > production environment. >>> > >>> > Tests have all the qualities of modules - code, dependencies, >>> > compilation phase, deployment. The only special part is the need for >>> > special "friend-like" access, which Jigsaw already has for other cases >>> > (the export...to clause). >>> > >>> > Put simply, I consider that module = >>> > deployment-artifact-with-dependencies. With that mental model, putting >>> > tests inside the module is just not acceptable, because tests should >>> > not be deployed with the main application and they have different >>> > dependencies. If we disagree that module = >>> > deployment-artifact-with-dependencies, then perhaps we have bigger >>> > problems to solve here. >>> > >>> > Stephen >>> > (And to Paul Benedict, the classpath is going to die over time, so any >>> > solution that uses that is flawed IMO). >>> > >>> > >>> >> So as Alan said, from the jigsaw point of view at runtime, the tests >>> and the code should be in the same module. >>> >> >>> >> So the building tools have to come with a way to support to have 2 >>> different module-info.java in two different folders and package them as one >>> module, >>> >> maybe javac should help by providing a way to merge 2 module-info at >>> compile time. >>> >> >>> >> R?mi >>> >> >>> >> ----- Mail original ----- >>> >>> De: "Alan Bateman" >>> >>> ?: "Stephen Colebourne" , "jigsaw-dev" < >>> jigsaw-dev at openjdk.java.net> >>> >>> Envoy?: Mercredi 23 Mars 2016 16:18:50 >>> >>> Objet: Re: modulepath and classpath mixture >>> >>> >>> >>> >>> >>> On 23/03/2016 14:42, Stephen Colebourne wrote: >>> >>>> : >>> >>>> >>> >>>> I don't particularly care what the mechanism is for this, but at the >>> >>>> requirements level: >>> >>>> - there are two modules - main and test >>> >>>> - each has its own source tree >>> >>>> - each has its own dependencies >>> >>>> - each is released separately >>> >>>> - each could be hosted on a central repo >>> >>>> - the test module needs to be able to contain the same packages as >>> the >>> >>>> main module >>> >>>> - the test module needs to be able to invoke package-scoped code in >>> >>>> the same package in the main module >>> >>>> >>> >>>> To clarify further consider 4 modules, A, B, A-test and B-test >>> where B >>> >>>> depends on A. Module A-test may have a method foo() that uses >>> package >>> >>>> scope to access something in A. Module B-test will depend on A-test >>> >>>> and rely on foo() to get access to that internal object. >>> >>> To your list, I would add the ability to make use of testing >>> frameworks >>> >>> like TestNG and JUnit. >>> >>> >>> >>> In any case, and as things currently stand, you've got most of the >>> >>> above. One differences is that the tests are not a separate module, >>> they >>> >>> are instead compiled and run in a way that patches the main module. >>> The >>> >>> second difference is that they don't have their own module >>> declaration, >>> >>> instead the compilation or run augments the dependences with any >>> >>> additional dependences that the tests have. As I said, if they tools >>> >>> makes it easy then I don't think it's too bad. >>> >>> >>> >>>> >>> >>>> (Note that I view the thread discussion of >>> >>>> references to test classes on the classpath as another hack. >>> >>>> >>> >>> Packages can't be split between modules and classpath so there is no >>> >>> support for that. >>> >>> >>> >>> -Alan >>> >>> >>> >> > From ali.ebrahimi1781 at gmail.com Wed Mar 30 19:24:13 2016 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Wed, 30 Mar 2016 23:54:13 +0430 Subject: modulepath and classpath mixture In-Reply-To: References: <56CC57A1.2050109@oracle.com> <56F2440A.7010505@oracle.com> <56F2914C.3030706@oracle.com> <56F2B3DA.402@oracle.com> <1228911717.349701.1459160027285.JavaMail.zimbra@u-pem.fr> <0CC4E4A6-4152-4BB0-BB42-B9E284540BB6@oracle.com> <6FB0B05A-6850-42F4-A6A3-42B7486CCDAA@oracle.com> Message-ID: Just add these to Paul's response, what about multi-module apps? Do we coming back to non-modular world? On Wed, Mar 30, 2016 at 11:43 PM, Paul Benedict wrote: > Russell, you ask a good question. If an artifact is meant to be a module, > wouldn't it make sense for it to run as a module during testing too? Those > boundaries should be activated like they are in production to get good > confidence in the code. Those are my two cents. I'd like to hear opposing > opinions though why the boundaries shouldn't be there. > > Cheers, > Paul > > On Wed, Mar 30, 2016 at 2:07 PM, Russell Gold > wrote: > > > Hi Paul, > > > > Why would you put your main code on the module path *during a unit test*? > > It seems to me that unit tests are explicitly about making sure that the > > code works, not the packaging. So you put both main and test code on the > > classpath, and there is no problem. The unit test can be done before the > > main code is packaged into a module. > > > > - Russ > > > > On Mar 30, 2016, at 10:47 AM, Paul Benedict > wrote: > > > > Russell, if you have a module with package X and a classpath jar with > > package X, the module can't see package X from the classpath. > > > > In the last several posts, there's been discussion on putting tests on > the > > classpath; keeping the "main" code in the module. So given what I stated > > above, that's what I've been referring to. > > > > Cheers, > > Paul > > > > On Wed, Mar 30, 2016 at 7:28 AM, Russell Gold > > wrote: > > > >> Hi Paul, > >> > >> Could you explain? What kind of code do you mean cannot access it? And > >> what do you mean by ?a split package situation?? > >> > >> From a conversation I had with Alan, earlier in this thread: > >> > >> > >> On Mar 23, 2016, at 11:42 AM, Alan Bateman > >> wrote: > >> > >> On 23/03/2016 14:15, Russell Gold wrote: > >> > >> Here are my assumptions, which you can correct. > >> > >> 1. A jar or classes directory placed on a class path are treated as part > >> of the unnamed module > >> > >> Yes > >> > >> > >> So if the tests and main code are both in directories, which they have > >> been up to now in Maven, why would there be a problem? Both would be in > the > >> unnamed module and able to access one another. > >> > >> - Russ > >> > >> On Mar 29, 2016, at 10:47 PM, Paul Benedict > wrote: > >> > >> Russell, when you drop a jar on the classpath, module code will not be > >> able to access it in a split package situation. That's the big barrier > >> here. Maven test projects are typically written with the same package > >> shared with the "main" code. > >> > >> Cheers, > >> Paul > >> > >> On Tue, Mar 29, 2016 at 11:33 AM, Russell Gold > > >> wrote: > >> > >>> Hi Stephen, > >>> > >>> Why do you need any kind of friend access? > >>> > >>> It seems to me that this is making things harder than they need to be. > >>> The tests can simply run with the production code on the class path, > and > >>> then there are no module issues at all. > >>> > >>> I think a larger problem is that you can do what I just said with the > >>> jars, even a jar which has been designated as a module by virtue of > having > >>> a module-info.class in it. That means that, when users are up taking > jars, > >>> they are not prevented from accessing module internals. They can put > the > >>> jars on the module path, of course, but they can still use them on the > >>> class path! > >>> > >>> - Russ > >>> > >>> > > >>> > On 28 March 2016 at 11:13, Remi Forax wrote: > >>> >> Hi Stephen, Hi all, > >>> >> I think that delivering tests as a separated module is a bad idea. > >>> >> > >>> >> I see that from the point of a developer, seeing the code and the > >>> test as different modules can be attractive because everything seems > to be > >>> put at the right place but there is a big drawback. Because modules are > >>> reified at runtime, it means that the runtime environment of the tests > will > >>> be different from the production environment. > >>> > > >>> > This last sentence doesn't make sense to me - tests are not run in a > >>> > production environment. > >>> > > >>> > Tests have all the qualities of modules - code, dependencies, > >>> > compilation phase, deployment. The only special part is the need for > >>> > special "friend-like" access, which Jigsaw already has for other > cases > >>> > (the export...to clause). > >>> > > >>> > Put simply, I consider that module = > >>> > deployment-artifact-with-dependencies. With that mental model, > putting > >>> > tests inside the module is just not acceptable, because tests should > >>> > not be deployed with the main application and they have different > >>> > dependencies. If we disagree that module = > >>> > deployment-artifact-with-dependencies, then perhaps we have bigger > >>> > problems to solve here. > >>> > > >>> > Stephen > >>> > (And to Paul Benedict, the classpath is going to die over time, so > any > >>> > solution that uses that is flawed IMO). > >>> > > >>> > > >>> >> So as Alan said, from the jigsaw point of view at runtime, the tests > >>> and the code should be in the same module. > >>> >> > >>> >> So the building tools have to come with a way to support to have 2 > >>> different module-info.java in two different folders and package them > as one > >>> module, > >>> >> maybe javac should help by providing a way to merge 2 module-info at > >>> compile time. > >>> >> > >>> >> R?mi > >>> >> > >>> >> ----- Mail original ----- > >>> >>> De: "Alan Bateman" > >>> >>> ?: "Stephen Colebourne" , "jigsaw-dev" < > >>> jigsaw-dev at openjdk.java.net> > >>> >>> Envoy?: Mercredi 23 Mars 2016 16:18:50 > >>> >>> Objet: Re: modulepath and classpath mixture > >>> >>> > >>> >>> > >>> >>> On 23/03/2016 14:42, Stephen Colebourne wrote: > >>> >>>> : > >>> >>>> > >>> >>>> I don't particularly care what the mechanism is for this, but at > the > >>> >>>> requirements level: > >>> >>>> - there are two modules - main and test > >>> >>>> - each has its own source tree > >>> >>>> - each has its own dependencies > >>> >>>> - each is released separately > >>> >>>> - each could be hosted on a central repo > >>> >>>> - the test module needs to be able to contain the same packages as > >>> the > >>> >>>> main module > >>> >>>> - the test module needs to be able to invoke package-scoped code > in > >>> >>>> the same package in the main module > >>> >>>> > >>> >>>> To clarify further consider 4 modules, A, B, A-test and B-test > >>> where B > >>> >>>> depends on A. Module A-test may have a method foo() that uses > >>> package > >>> >>>> scope to access something in A. Module B-test will depend on > A-test > >>> >>>> and rely on foo() to get access to that internal object. > >>> >>> To your list, I would add the ability to make use of testing > >>> frameworks > >>> >>> like TestNG and JUnit. > >>> >>> > >>> >>> In any case, and as things currently stand, you've got most of the > >>> >>> above. One differences is that the tests are not a separate module, > >>> they > >>> >>> are instead compiled and run in a way that patches the main module. > >>> The > >>> >>> second difference is that they don't have their own module > >>> declaration, > >>> >>> instead the compilation or run augments the dependences with any > >>> >>> additional dependences that the tests have. As I said, if they > tools > >>> >>> makes it easy then I don't think it's too bad. > >>> >>> > >>> >>>> > >>> >>>> (Note that I view the thread discussion of > >>> >>>> references to test classes on the classpath as another hack. > >>> >>>> > >>> >>> Packages can't be split between modules and classpath so there is > no > >>> >>> support for that. > >>> >>> > >>> >>> -Alan > >>> >>> > >>> > >> > > > -- Best Regards, Ali Ebrahimi From sgrinove at redhat.com Wed Mar 30 21:39:50 2016 From: sgrinove at redhat.com (Sanne Grinovero) Date: Wed, 30 Mar 2016 22:39:50 +0100 Subject: Unexpected ClassnotFoundException on reflective Class#getMethod Message-ID: Hello all, looks like I've found an issue on invoking Class#getMethod. This method is used by Maven when scanning the project's classpath to identify JUnit tests - which it does by default on any Maven project - so I'm afraid the impact could be quite large. I've been able to narrow it down to this small test which doesn't need neither Maven nor JUnit, however to reproduce the issue the project must have a dependency to some third party jar. In this reproducer I'm using javax.transaction.Synchronization, a copy can be obtained from: - https://repository.jboss.org/nexus/service/local/repositories/central/content/org/jboss/spec/javax/transaction/jboss-transaction-api_1.2_spec/1.0.0.Final/jboss-transaction-api_1.2_spec-1.0.0.Final.jar ==== Main.java ==== public class Main { public static void main(String[] args) { Class clazz = SecondClass.class; try { clazz.getMethod("notexisting", new Class[0]); } catch (NoSuchMethodException e) { e.printStackTrace(); } System.out.println("All good"); } } ==== SecondClass.java ==== import javax.transaction.Synchronization; public class SecondClass { public void registerSynchronization(Synchronization synchronization) { } } ==== EOF ==== On Java8 or Java9 build 9-ea+110 the output is, as expected: > java.lang.NoSuchMethodException: SecondClass.notexisting() > at java.lang.Class.getMethod(Class.java:1786) > at Main.main(Main.java:6) > All good On Java9 build 9-ea+111 though I'll have this: > Exception in thread "main" java.lang.NoClassDefFoundError: javax/transaction/Synchronization > at java.lang.Class.getDeclaredMethods0(java.base at 9-ea/Native Method) > at java.lang.Class.privateGetDeclaredMethods(java.base at 9-ea/Class.java:2937) > at java.lang.Class.privateGetMethodRecursive(java.base at 9-ea/Class.java:3282) > at java.lang.Class.getMethod0(java.base at 9-ea/Class.java:3252) > at java.lang.Class.getMethod(java.base at 9-ea/Class.java:1961) > at Main.main(Main.java:6) > Caused by: java.lang.ClassNotFoundException: javax.transaction.Synchronization > at jdk.internal.loader.BuiltinClassLoader.loadClass(java.base at 9-ea/BuiltinClassLoader.java:368) > at jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(java.base at 9-ea/ClassLoaders.java:185) > at java.lang.ClassLoader.loadClass(java.base at 9-ea/ClassLoader.java:419) > ... 6 more I hope I have sent this to the right mailing list. I've reported the same issue on bugreport.java.com, but the only ID I have about that report is the "Review ID": JI-9033943 The reproducer in this email is much better than in the other report, I can't check what I sent but I believe I might have sent an outdated version; apologies for any confusion. Thanks, Sanne Grinovero From forax at univ-mlv.fr Wed Mar 30 21:45:41 2016 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Wed, 30 Mar 2016 23:45:41 +0200 (CEST) Subject: modulepath and classpath mixture In-Reply-To: References: <0CC4E4A6-4152-4BB0-BB42-B9E284540BB6@oracle.com> <6FB0B05A-6850-42F4-A6A3-42B7486CCDAA@oracle.com> <56FBD85F.6070103@oracle.com> <583721482.2221663.1459347179231.JavaMail.zimbra@u-pem.fr> Message-ID: <1757483708.2475487.1459374341321.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Ali Ebrahimi" > ?: "Remi Forax" > Cc: "Alan Bateman" , "Jonathan Gibbons" > , "jigsaw-dev" > Envoy?: Mercredi 30 Mars 2016 17:12:22 > Objet: Re: modulepath and classpath mixture > So, do you suggest partial modules or module fragments? A kind of exploded module with sources available in more than one directory. Classes are still in one modular jar with one module-info.class (so at runtime, there is only one module). > Why we make things so complex for writing single test method. I think testing > is an essential part of development, so modular java should have first class > support for that. > I don't see command line options as developer friendly solution, even things > gets worse when have dozen of modules. That's another question, i think we first need to agree that we just want to have the main code and the test code into different directory and then we can see if javac -Xmodule is the best syntax or if by example -modulesourcepath can accept to have several directories that describe the same module. cheers, R?mi > On Wed, Mar 30, 2016 at 6:42 PM, Remi Forax < forax at univ-mlv.fr > wrote: > > Alan, Jon, > > > i think javac -Xmodule should merge the module-info.java from the existing > > module and the one declared in the directory, > > > with the current semantics of the module-info, merging of modules is easy > > and > > with no corner cases, > > > so for testing, the test will be able to declare their own dependencies > > inside their own module-info.java. > > > Proposed semantics for merging, > > > - do the union of the required modules > > > - if one required module is required publicly, it will be required > > publicly. > > > - do the union of the exported packages > > > - if one exported package is restricted, do the union of the restriction > > > - do the union of the uses. > > > - do the union of the provides. > > > so merging two modules is symmetric and will always succeed. > > > R?mi > > > ----- Mail original ----- > > > > De: "Alan Bateman" < Alan.Bateman at oracle.com > > > > > ?: "Russell Gold" < russell.gold at oracle.com > > > > > Cc: "jigsaw-dev" < jigsaw-dev at openjdk.java.net > > > > > Envoy?: Mercredi 30 Mars 2016 15:45:03 > > > > Objet: Re: modulepath and classpath mixture > > > > > > > > On 30/03/2016 13:28, Russell Gold wrote: > > > > > : > > > > > > > > > > > > > > > So if the tests and main code are both in directories, which they have > > > > been > > > > > up to now in Maven, why would there be a problem? Both would be in the > > > > > unnamed module and able to access one another. > > > > > > > > > There shouldn't any issue there, it should just work as it has always > > > done. > > > > > > > > The thread here has meandered a bit but I think the scenario under > > > > discussion is tests for a module that need to nestmate with the module > > > > under test. The tests are in their own test tree. The tests are compiled > > > > separately from the module they test and may have additional dependences > > > > (such as on TestNG or JUnit for example). When compiling or running then > > > > the tests need to access public types in non-exported packages and maybe > > > > package private members too. The support for this has been in jake for a > > > > long time but involves command line options that many developers or > > > > build environments won't immediately grok. In particular the tests have > > > > to be compiled "as if" they augment the already compiled module - that > > > > is what javac -Xmodule is about. There is no need to co-locate source > > > > files or class files of course. When run then the -Xpatch option is what > > > > brings the tests and the module classes together. If we get the tools > > > > right then most developers won't ever see this of course. > > > > > > > > One other thing to say that we've already been through some of this with > > > > the JDK tests. The jtreg test harness that we use for the JDK tests has > > > > been updated (thanks to Jon Gibbons) with useful support for modules > > > > [1]. It's enough for us to write tests that use JDK-internal APIs or > > > > write tests that nestmate with types in system modules so that they get > > > > access to package private type or public types in non-exported packages. > > > > It has rudimentary support for user modules too. Additional dependences > > > > are still an issue but our tests don't require additional dependences > > > > beyond TestNG. The test harness employs a bit of hackery to get things > > > > done, important when starting out, but I expect will go away in time. > > > > > > > > -Alan. > > > > > > > > [1] > > > > http://hg.openjdk.java.net/code-tools/jtreg/raw-file/tip/src/share/doc/javatest/regtest/tag-spec.html > > > > > > > > > > > > > > -- > Best Regards, > Ali Ebrahimi From alex.buckley at oracle.com Wed Mar 30 22:07:24 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 30 Mar 2016 15:07:24 -0700 Subject: Unexpected ClassnotFoundException on reflective Class#getMethod In-Reply-To: References: Message-ID: <56FC4E1C.3030301@oracle.com> The JDK 9b111 runtime image includes the java.transaction module which exports the javax.transaction package. The application class loader will try to load javax.transaction.* types from there, not from a JAR on the classpath. As you probably guess, the JDK's java.transaction module does not contain the javax.transaction.Synchronization type. You can either supply an alternate java.transaction module to override the one in the JDK (-upgrademodulepath), or you can inject your additional classes directly into the module in the JDK (-Xpatch). Please see JEP 261. Alex On 3/30/2016 2:39 PM, Sanne Grinovero wrote: > Hello all, > looks like I've found an issue on invoking Class#getMethod. > > This method is used by Maven when scanning the project's classpath to > identify JUnit tests - which it does by default on any Maven project - > so I'm afraid the impact could be quite large. > > I've been able to narrow it down to this small test which doesn't need > neither Maven nor JUnit, however to reproduce the issue the project > must have a dependency to some third party jar. > In this reproducer I'm using javax.transaction.Synchronization, a copy > can be obtained from: > - https://repository.jboss.org/nexus/service/local/repositories/central/content/org/jboss/spec/javax/transaction/jboss-transaction-api_1.2_spec/1.0.0.Final/jboss-transaction-api_1.2_spec-1.0.0.Final.jar > > > ==== Main.java ==== > public class Main { > > public static void main(String[] args) { > Class clazz = SecondClass.class; > try { > clazz.getMethod("notexisting", new Class[0]); > } catch (NoSuchMethodException e) { > e.printStackTrace(); > } > System.out.println("All good"); > } > > } > ==== SecondClass.java ==== > import javax.transaction.Synchronization; > > public class SecondClass { > > public void registerSynchronization(Synchronization synchronization) { > } > > } > ==== EOF ==== > > > On Java8 or Java9 build 9-ea+110 the output is, as expected: > >> java.lang.NoSuchMethodException: SecondClass.notexisting() >> at java.lang.Class.getMethod(Class.java:1786) >> at Main.main(Main.java:6) >> All good > > > On Java9 build 9-ea+111 though I'll have this: > >> Exception in thread "main" java.lang.NoClassDefFoundError: javax/transaction/Synchronization >> at java.lang.Class.getDeclaredMethods0(java.base at 9-ea/Native Method) >> at java.lang.Class.privateGetDeclaredMethods(java.base at 9-ea/Class.java:2937) >> at java.lang.Class.privateGetMethodRecursive(java.base at 9-ea/Class.java:3282) >> at java.lang.Class.getMethod0(java.base at 9-ea/Class.java:3252) >> at java.lang.Class.getMethod(java.base at 9-ea/Class.java:1961) >> at Main.main(Main.java:6) >> Caused by: java.lang.ClassNotFoundException: javax.transaction.Synchronization >> at jdk.internal.loader.BuiltinClassLoader.loadClass(java.base at 9-ea/BuiltinClassLoader.java:368) >> at jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(java.base at 9-ea/ClassLoaders.java:185) >> at java.lang.ClassLoader.loadClass(java.base at 9-ea/ClassLoader.java:419) >> ... 6 more > > I hope I have sent this to the right mailing list. > I've reported the same issue on bugreport.java.com, but the only ID I > have about that report is the "Review ID": JI-9033943 > The reproducer in this email is much better than in the other report, > I can't check what I sent but I believe I might have sent an outdated > version; apologies for any confusion. > > Thanks, > Sanne Grinovero > From jonathan.gibbons at oracle.com Thu Mar 31 00:10:29 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 30 Mar 2016 17:10:29 -0700 Subject: modulepath and classpath mixture In-Reply-To: <1757483708.2475487.1459374341321.JavaMail.zimbra@u-pem.fr> References: <0CC4E4A6-4152-4BB0-BB42-B9E284540BB6@oracle.com> <6FB0B05A-6850-42F4-A6A3-42B7486CCDAA@oracle.com> <56FBD85F.6070103@oracle.com> <583721482.2221663.1459347179231.JavaMail.zimbra@u-pem.fr> <1757483708.2475487.1459374341321.JavaMail.zimbra@u-pem.fr> Message-ID: <56FC6AF5.6020101@oracle.com> On 03/30/2016 02:45 PM, forax at univ-mlv.fr wrote: > > > ------------------------------------------------------------------------ > > *De: *"Ali Ebrahimi" > *?: *"Remi Forax" > *Cc: *"Alan Bateman" , "Jonathan Gibbons" > , "jigsaw-dev" > > *Envoy?: *Mercredi 30 Mars 2016 17:12:22 > *Objet: *Re: modulepath and classpath mixture > > So, do you suggest partial modules or module fragments? > > > A kind of exploded module with sources available in more than one > directory. > Classes are still in one modular jar with one module-info.class (so at > runtime, there is only one module). > > > Why we make things so complex for writing single test method. I > think testing is an essential part of development, so modular java > should have first class support for that. > I don't see command line options as developer friendly solution, > even things gets worse when have dozen of modules. > > > That's another question, i think we first need to agree that we just > want to have the main code and the test code into different directory > and then we can see if javac -Xmodule is the best syntax or if by > example -modulesourcepath can accept to have several directories that > describe the same module. -modulesourcepath can accept several source directories that together comprise the source for a single module. If nothing else, you can see this utilized in the JDK build, where the source structure for a module may contain subdirectories for platform-independent classes, platform-specific classes, and dynamically generated classes. The primary constraints are that there is only one module-info.java file, and the mapping to a class output directory. There is nothing to prevent you recompiling an entire module, including test code, to create a new version of the module, including the test code. If you so choose. -- Jon > > cheers, > R?mi > > > > On Wed, Mar 30, 2016 at 6:42 PM, Remi Forax > wrote: > > Alan, Jon, > i think javac -Xmodule should merge the module-info.java from > the existing module and the one declared in the directory, > with the current semantics of the module-info, merging of > modules is easy and with no corner cases, > so for testing, the test will be able to declare their own > dependencies inside their own module-info.java. > > Proposed semantics for merging, > - do the union of the required modules > - if one required module is required publicly, it will be > required publicly. > - do the union of the exported packages > - if one exported package is restricted, do the union of the > restriction > - do the union of the uses. > - do the union of the provides. > > so merging two modules is symmetric and will always succeed. > > R?mi > > ----- Mail original ----- > > De: "Alan Bateman" > > > ?: "Russell Gold" > > > Cc: "jigsaw-dev" > > > Envoy?: Mercredi 30 Mars 2016 15:45:03 > > Objet: Re: modulepath and classpath mixture > > > > On 30/03/2016 13:28, Russell Gold wrote: > > > : > > > > > > > > > So if the tests and main code are both in directories, > which they have been > > > up to now in Maven, why would there be a problem? Both > would be in the > > > unnamed module and able to access one another. > > > > > There shouldn't any issue there, it should just work as it > has always done. > > > > The thread here has meandered a bit but I think the scenario > under > > discussion is tests for a module that need to nestmate with > the module > > under test. The tests are in their own test tree. The tests > are compiled > > separately from the module they test and may have additional > dependences > > (such as on TestNG or JUnit for example). When compiling or > running then > > the tests need to access public types in non-exported > packages and maybe > > package private members too. The support for this has been > in jake for a > > long time but involves command line options that many > developers or > > build environments won't immediately grok. In particular the > tests have > > to be compiled "as if" they augment the already compiled > module - that > > is what javac -Xmodule is about. There is no need to > co-locate source > > files or class files of course. When run then the -Xpatch > option is what > > brings the tests and the module classes together. If we get > the tools > > right then most developers won't ever see this of course. > > > > One other thing to say that we've already been through some > of this with > > the JDK tests. The jtreg test harness that we use for the > JDK tests has > > been updated (thanks to Jon Gibbons) with useful support for > modules > > [1]. It's enough for us to write tests that use JDK-internal > APIs or > > write tests that nestmate with types in system modules so > that they get > > access to package private type or public types in > non-exported packages. > > It has rudimentary support for user modules too. Additional > dependences > > are still an issue but our tests don't require additional > dependences > > beyond TestNG. The test harness employs a bit of hackery to > get things > > done, important when starting out, but I expect will go away > in time. > > > > -Alan. > > > > [1] > > > http://hg.openjdk.java.net/code-tools/jtreg/raw-file/tip/src/share/doc/javatest/regtest/tag-spec.html > > > > > > > > > > > -- > > Best Regards, > Ali Ebrahimi > > From jonathan.gibbons at oracle.com Thu Mar 31 01:29:55 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 30 Mar 2016 18:29:55 -0700 Subject: modulepath and classpath mixture In-Reply-To: <583721482.2221663.1459347179231.JavaMail.zimbra@u-pem.fr> References: <56F2B3DA.402@oracle.com> <1228911717.349701.1459160027285.JavaMail.zimbra@u-pem.fr> <0CC4E4A6-4152-4BB0-BB42-B9E284540BB6@oracle.com> <6FB0B05A-6850-42F4-A6A3-42B7486CCDAA@oracle.com> <56FBD85F.6070103@oracle.com> <583721482.2221663.1459347179231.JavaMail.zimbra@u-pem.fr> Message-ID: <56FC7D93.6010802@oracle.com> I have been following this thread, and it strongly reminds me of Joe Darcy's parables of elephants and blind men. [1,2] In this context, the discussion has been about testing, and the underlying presumption that one size fits all. I venture to suggest that one size does /not/ fit all, and that we have to be able to support a wide range of testing paradigms. 1) Some folk will want to do black box testing, with their tests contained in their own first class module, to exercise the code the way that real clients might do 2) Some folk will want to do black box testing, with their test code on the classpath, in the unnamed module, because they don't want to update their test code 3) Some folk will want to do white box testing, using code conventions is widespread use today, where the test code is alongside the code being tested, in the same package. This generates two sub-cases: a) is the test code compiled into the module itself, in a special test-specific build, or b) is the test code dynamically patched into the module 4) Some folk will want to do white box testing, but will be less concerned about the package used to contain the package. That has the same two sub-cases: a) is the test code compiled into the module itself, in a special test-specific build, or b) is the test code dynamically patched into the module Now you take all those scenarios, and cross-product them with issues like, is there a test framework involved, such as JUnit or TestNG, and, where should that framework be placed: can it be an automatic module, or it is sufficient to put the framework on the classpath, in the unnamed module? When you understand all that, then you begin to see the shape of the elephant in the room that is the testing problem. But, to stretch the analogy to breaking point, it's not the only elephant in the room. There's another, different, elephant called "strong encapsulation", and there is a strong conflict between the desire for easy white box testing and the desire for strong encapsulation. While the past 20 years of Java have led to easy simple white box testing, leveraging split packages by adding jars onto the class path, we've also seen the the problems that such techniques can lead to ... hence the desire for Project Jigsaw, and the requirement [3] for strong encapsulation. We have to accept that the better we succeed at strong encapsulation, the harder it will be to use the old ways of white box testing. Conversely, the more we hold to the old ways of working, the less we will succeed at satisfying the goal of strong encapsulation. So, ultimately, the trick is to figure out how to walk the tightrope between the two elephants in the room. Previously, as a community, we've built tools to help manage the task. Now, it is time for the tools and our practices to evolve, to meet the new demands of testing in a modular world. Do we have all the answers today? Almost certainly not. But I will note one of the unheralded success stories of Jigsaw and OpenJDK. Testing has always been important, and we have managed to keep running almost all of the JDK unit and regression tests with little to no change in functionality in almost all of the tests, and we have started supporting new testing scenarios as well. Looking back at the list I gave at the beginning, support for 1 is coming available, but not yet widely used, many JDK tests use case 2, JDK has a number of tests that use 3b and 4b, and we have tests that use JUnit and TestNG. So, command line options like -XaddExports, -Xpatch, -Xmodule, etc, may not be pretty, but they can be composed to cover a wide range of testing scenarios, without giving up too much on the goal of strong encapsulation, and that at least is some degree of success. -- Jon [1] https://blogs.oracle.com/darcy/entry/project_coin_elephants_knapsacks_language [2] http://en.wikipedia.org/wiki/Blind_Men_and_an_Elephant [3] http://openjdk.java.net/projects/jigsaw/spec/reqs/ From john.r.rose at oracle.com Thu Mar 31 06:18:39 2016 From: john.r.rose at oracle.com (John Rose) Date: Wed, 30 Mar 2016 23:18:39 -0700 Subject: RFR: 8152641: Plugin to generate BMH$Species classes ahead-of-time In-Reply-To: <56FC08B7.5010504@oracle.com> References: <56F3EEAB.4090600@oracle.com> <1FE3F7A6-1C7B-4DC6-875C-E3FAEDED08F5@oracle.com> <56F50EC5.6020500@gmail.com> <56F5520D.3080205@oracle.com> <56F676CA.5000803@gmail.com> <56FB09D3.4090000@oracle.com> <56FB82FE.5010209@gmail.com> <56FB8607.8030000@gmail.com> <56FBB014.6050002@oracle.com> <56FBC4D8.8010603@gmail.com> <56FBDF98.4090102@oracle.com> <56FBEE08.7010600@gmail.com> <56FBFC23.5090104@oracle.com> <56FC08B7.5010504@oracle.com> Message-ID: <792F3D3E-FC15-489C-9A8B-F4F34F3BA2FE@oracle.com> I like it too. Reviewed. A couple of comments: The default list of species in the plugin (List.of("LL", "L3", ? "I", "LLILL")) should be commented with information for maintainers to reproduce the procedure you used to generate that list. Otherwise the list is just magic, and unmaintainable. I'm glad to see this pre-generation work happening. Please consider (or file a followup RFE) pre-generating other classes dynamically generated by jli. The lambda form editor produces a large number of stereotyped classes. In the common case where an anonymous class is generated just for one static method, the linker plugin should generate a *single* named class containing *all* of the static methods. Eventually, I think, you will want a jlink option which will control the pre-generation of all sorts of jli classes. Perhaps it would be it would be something like "--generate-jli-classes=", where the argument includes a way to specify all the BMH species you are working with now, but would also provide a way to ask for LFE transforms. What you have now is fine as far as it goes. ? John On Mar 30, 2016, at 10:11 AM, Vladimir Ivanov wrote: > > Nice work, Claes! > > j.l.i part looks fine. > > Best regards, > Vladimir Ivanov > > On 3/30/16 7:17 PM, Claes Redestad wrote: >> Hi Peter, >> >> something like this, then: >> >> http://cr.openjdk.java.net/~redestad/8152641/webrev.05/ >> >> - Added a method only used by the plugin which validates input; added a >> comment about the dependency >> - Invalid types are logged but otherwise ignored now (I bet someone >> might suggest a better way to handle user errors) >> - Some cleanup, introduced constant for class name prefix and removed >> duplicate type string shortening etc >> >> /Claes >> >> On 2016-03-30 17:17, Peter Levart wrote: >>> Hi Claes, >>> >>> webrev.04 looks good now. >>> >>> Maybe just one nit. For production quality, plugin input could be >>> verified that after expansion it is composed of just the following >>> characters: "LIJFD". Otherwise ClassWriter might generate an unusable >>> class without complaining (for example if someone sneaks-in characters >>> 'S' 'Z' 'B' or 'C')... >>> >>> Or, better yet, create another method in BMH that will be the "public" >>> API between the plugin and BMH which does the validation and calls >>> generateConcreteBMHClassBytes(). Internally in BMH the validation is >>> not necessary as the types strings are composed programmatically and >>> are guaranteed to be correct. >>> >>> Regards, Peter >>> >>> On 03/30/2016 04:15 PM, Claes Redestad wrote: >>>> >>>> >>>> On 2016-03-30 14:21, Peter Levart wrote: >>>>> Hi Claes, >>>>> >>>>> On 03/30/2016 12:53 PM, Claes Redestad wrote: >>>>>> Hi, >>>>>> >>>>>> I think Class.forName(Module, String) seemed like a nice >>>>>> efficiency/simplicity compromise, but there is some usage of >>>>>> lambdas/method-refs in the Module lookup code, especially for >>>>>> exploded modules (which get exercised during JDK build). Depending >>>>>> on a lambda from code in java.lang.invoke means we fail to bootstrap. >>>>>> >>>>>> But hey, we're living in an encapsulated world now, and this is in >>>>>> java.base, so why not go directly to the BootLoader: >>>>>> >>>>>> http://cr.openjdk.java.net/~redestad/8152641/webrev.03/ >>>>>> >>>>>> Since this is what's called from Class.forName(Module, String), the >>>>>> overhead should be even smaller than in your classForNameInModule >>>>>> test. >>>>> >>>>> Good idea. >>>>> >>>>>> >>>>>> If I call this final, will you say "Reviewed"? :-) >>>>> >>>>> Sorry, I don't posses the powers. :-) >>>>> >>>>> I could say "rEVIEWED", but... >>>>> >>>>> In the plugin, the input is shortened speciesTypes strings. What >>>>> guarantees that they really are normalized? For example, If one >>>>> specifies "LLL" as input, it will get expanded into "LLL", the >>>>> generated class will have "_L3" as a name suffix, but you will pack >>>>> it in the image with "_LLL.class" filename suffix. >>>>> >>>>> That's another reason why a method in BoundMethodHandle$Factory with >>>>> the following signature: >>>>> >>>>> Map.Entry generateConcreteBMHClassBytes(String types); >>>>> >>>>> ...would be a good idea. It would return class bytes and the name of >>>>> the class which you could use to derive the class filename without >>>>> hardcoding the same logic in plugin and in BMH. >>>>> >>>>> You just move the "LambdaForm.shortenSignature(types)" from >>>>> getConcreteBMHClass and className/sourceFile calculation from >>>>> generateConcreteBMHClass down to generateConcreteBMHClassBytes >>>>> method and change the signatures... >>>> >>>> Yes, it makes sense to keep control over the class name inside the >>>> factory class, and this does allow specifying shortened or expanded >>>> forms (L3 vs LLL) interchangeably as input to the plugin, which >>>> reduces possibility for user errors. >>>> >>>> How about this: http://cr.openjdk.java.net/~redestad/8152641/webrev.04/ >>>> >>>> /Claes >>>> >>>>> >>>>> Regards, Peter >>>>> >>>>>> >>>>>> /Claes >>>>>> >>>>>> PS: The default list of types is generated in a few adhoc tests not >>>>>> part of this patch. I'm considering proposing add support for >>>>>> generating this list at build time. Maybe a JEP called "Build >>>>>> system support for profile-guided optimizations", which could also >>>>>> handle https://bugs.openjdk.java.net/browse/JDK-8150044 >>>>>> >>>>>> On 2016-03-30 09:53, Peter Levart wrote: >>>>>>> Hi Claes, >>>>>>> >>>>>>> Sorry, I found a flaw in the benchmark (the regex pattern to split >>>>>>> comma-separated string into substrings was wrong). What the >>>>>>> benchmark did was compare the overheads of a single lookup of a >>>>>>> longer class name containing commas. Here's the corrected result >>>>>>> of overheads of 5 unsuccessful lookups: >>>>>>> >>>>>>> Benchmark (generate) (lookup) Mode Cnt >>>>>>> Score Error Units >>>>>>> ClassForNameBench.classForName LL,LLL,LLLL,LLLLL,LLLLLL >>>>>>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 29627.141 ? 567.427 ns/op >>>>>>> ClassForNameBench.classForNameInModule LL,LLL,LLLL,LLLLL,LLLLLL >>>>>>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 1073.256 ? 23.794 ns/op >>>>>>> ClassForNameBench.hashSetContains LL,LLL,LLLL,LLLLL,LLLLLL >>>>>>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 33.022 ? 0.066 ns/op >>>>>>> ClassForNameBench.switchStatement LL,LLL,LLLL,LLLLL,LLLLLL >>>>>>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 38.498 ? 5.842 ns/op >>>>>>> >>>>>>> ...overheads are a little bigger (x5 approx.). >>>>>>> >>>>>>> >>>>>>> Here's the corrected benchmark: >>>>>>> >>>>>>> >>>>>>> package jdk.test; >>>>>>> >>>>>>> import org.openjdk.jmh.annotations.*; >>>>>>> import org.openjdk.jmh.infra.Blackhole; >>>>>>> >>>>>>> import java.io.Serializable; >>>>>>> import java.lang.invoke.MethodHandle; >>>>>>> import java.util.Iterator; >>>>>>> import java.util.Set; >>>>>>> import java.util.concurrent.TimeUnit; >>>>>>> import java.util.stream.Collectors; >>>>>>> import java.util.stream.Stream; >>>>>>> >>>>>>> @BenchmarkMode(Mode.AverageTime) >>>>>>> @Fork(value = 1, warmups = 0) >>>>>>> @Warmup(iterations = 10) >>>>>>> @Measurement(iterations = 10) >>>>>>> @OutputTimeUnit(TimeUnit.NANOSECONDS) >>>>>>> @State(Scope.Thread) >>>>>>> public class ClassForNameBench { >>>>>>> >>>>>>> static final String BMH = "java/lang/invoke/BoundMethodHandle"; >>>>>>> static final String SPECIES_PREFIX_NAME = "Species_"; >>>>>>> static final String SPECIES_PREFIX_PATH = BMH + "$" + >>>>>>> SPECIES_PREFIX_NAME; >>>>>>> >>>>>>> @Param({"LL,LLL,LLLL,LLLLL,LLLLLL"}) >>>>>>> public String generate; >>>>>>> >>>>>>> @Param({"LLI,LLLI,LLLLI,LLLLLI,LLLLLLI"}) >>>>>>> public String lookup; >>>>>>> >>>>>>> private String[] generatedTypes; >>>>>>> private String[] lookedUpTypes; >>>>>>> private Set generatedNames; >>>>>>> private String[] lookedUpNames; >>>>>>> >>>>>>> @Setup(Level.Trial) >>>>>>> public void setup() { >>>>>>> generatedTypes = generate.trim().split("\\s*,\\s*"); >>>>>>> lookedUpTypes = lookup.trim().split("\\s*,\\s*"); >>>>>>> generatedNames = Stream.of(generatedTypes) >>>>>>> .map(types -> SPECIES_PREFIX_PATH + >>>>>>> shortenSignature(types)) >>>>>>> .collect(Collectors.toSet()); >>>>>>> lookedUpNames = Stream.of(lookedUpTypes) >>>>>>> .map(types -> SPECIES_PREFIX_PATH + >>>>>>> shortenSignature(types)) >>>>>>> .toArray(String[]::new); >>>>>>> } >>>>>>> >>>>>>> @Benchmark >>>>>>> public void classForName(Blackhole bh) { >>>>>>> for (String name : lookedUpNames) { >>>>>>> try { >>>>>>> bh.consume(Class.forName(name, false, >>>>>>> MethodHandle.class.getClassLoader())); >>>>>>> } catch (ClassNotFoundException e) { >>>>>>> bh.consume(e); >>>>>>> } >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> @Benchmark >>>>>>> public void classForNameInModule(Blackhole bh) { >>>>>>> for (String name : lookedUpNames) { >>>>>>> bh.consume(Class.forName(MethodHandle.class.getModule(), name)); >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> @Benchmark >>>>>>> public void hashSetContains(Blackhole bh) { >>>>>>> for (String name : lookedUpNames) { >>>>>>> bh.consume(generatedNames.contains(name)); >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> @Benchmark >>>>>>> public void switchStatement(Blackhole bh) { >>>>>>> for (String types : lookedUpTypes) { >>>>>>> bh.consume(getBMHSwitch(types)); >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> static Class getBMHSwitch(String types) { >>>>>>> // should be in sync with @Param generate above... >>>>>>> switch (types) { >>>>>>> case "LL": return Object.class; >>>>>>> case "LLL": return Serializable.class; >>>>>>> case "LLLL": return Iterator.class; >>>>>>> case "LLLLL": return Throwable.class; >>>>>>> case "LLLLLL": return String.class; >>>>>>> default: return null; >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> // copied from non-public LambdaForm >>>>>>> static String shortenSignature(String signature) { >>>>>>> // Hack to make signatures more readable when they show up >>>>>>> in method names. >>>>>>> final int NO_CHAR = -1, MIN_RUN = 3; >>>>>>> int c0, c1 = NO_CHAR, c1reps = 0; >>>>>>> StringBuilder buf = null; >>>>>>> int len = signature.length(); >>>>>>> if (len < MIN_RUN) return signature; >>>>>>> for (int i = 0; i <= len; i++) { >>>>>>> // shift in the next char: >>>>>>> c0 = c1; c1 = (i == len ? NO_CHAR : signature.charAt(i)); >>>>>>> if (c1 == c0) { ++c1reps; continue; } >>>>>>> // shift in the next count: >>>>>>> int c0reps = c1reps; c1reps = 1; >>>>>>> // end of a character run >>>>>>> if (c0reps < MIN_RUN) { >>>>>>> if (buf != null) { >>>>>>> while (--c0reps >= 0) >>>>>>> buf.append((char) c0); >>>>>>> } >>>>>>> continue; >>>>>>> } >>>>>>> // found three or more in a row >>>>>>> if (buf == null) >>>>>>> buf = new StringBuilder().append(signature, 0, i - >>>>>>> c0reps); >>>>>>> buf.append((char) c0).append(c0reps); >>>>>>> } >>>>>>> return (buf == null) ? signature : buf.toString(); >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> >>>>>>> Regards, Peter >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 03/30/2016 09:40 AM, Peter Levart wrote: >>>>>>>> Hi Claes, >>>>>>>> >>>>>>>> On 03/30/2016 01:03 AM, Claes Redestad wrote: >>>>>>>>> Hi Peter, Mandy, >>>>>>>>> >>>>>>>>> On 2016-03-26 12:47, Peter Levart wrote: >>>>>>>>>> >>>>>>>>>> Comparing this with proposed code from webrev: >>>>>>>>>> >>>>>>>>>> 493 try { >>>>>>>>>> 494 return (Class>>>>>>>>> BoundMethodHandle>) >>>>>>>>>> 495 >>>>>>>>>> Class.forName("java.lang.invoke.BoundMethodHandle$Species_" + >>>>>>>>>> LambdaForm.shortenSignature(types)); >>>>>>>>>> 496 } catch (ClassNotFoundException >>>>>>>>>> cnf) { >>>>>>>>>> 497 // Not pregenerated, generate >>>>>>>>>> the class >>>>>>>>>> 498 return >>>>>>>>>> generateConcreteBMHClass(types); >>>>>>>>>> 499 } >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ...note that the function passed to CLASS_CACHE.computeIfAbsent >>>>>>>>>> is executed just once per distinct 'types' argument. Even if >>>>>>>>>> you put the generated switch between a call to >>>>>>>>>> getConcreteBMHClass and CLASS_CACHE.computeIfAbsent, >>>>>>>>>> getConcreteBMHClass(String types) is executed just once per >>>>>>>>>> distinct 'types' argument (except in rare occasions when VM can >>>>>>>>>> not initialize the loaded class). >>>>>>>>>> >>>>>>>>>> In this respect a successful Class.forName() is not any worse >>>>>>>>>> than static resolving. It's just that unsuccessful >>>>>>>>>> Class.forName() represents some overhead for classes that are >>>>>>>>>> not pre-generated. So an alternative way to get rid of that >>>>>>>>>> overhead is to have a HashSet of 'types' strings for >>>>>>>>>> pre-generated classes at hand in order to decide whether to >>>>>>>>>> call Class.forName or generateConcreteBMHClass. >>>>>>>>>> >>>>>>>>>> What's easier to support is another question. >>>>>>>>>> >>>>>>>>>> Regards, Peter >>>>>>>>> >>>>>>>>> to have something to compare with I built a version which, like >>>>>>>>> you suggest, >>>>>>>>> generates a HashSet with the set of generated classes here: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~redestad/8152641/webrev.02/ >>>>>>>>> >>>>>>>>> This adds a fair bit of complexity to the plugin and requires we >>>>>>>>> add a nested >>>>>>>>> class in BoundMethodHandle that we can replace. Using the anonymous >>>>>>>>> compute Function for this seems like the best choice for this. >>>>>>>> >>>>>>>> ...what I had in mind as alternative to a pregenerated class with >>>>>>>> a switch was a simple textual resource file, generated by plugin, >>>>>>>> read-in by BMH into a HashSet. No special-purpose class >>>>>>>> generation and much less complexity for the plugin. >>>>>>>> >>>>>>>>> >>>>>>>>> I've not been able to measure any statistical difference in real >>>>>>>>> startup terms, >>>>>>>>> though, and not figured out a smart way to benchmark the >>>>>>>>> overhead of the >>>>>>>>> CNFE in relation to the class generation (my guess it adds a >>>>>>>>> fraction to the >>>>>>>>> total cost) and since this adds ever so little footprint and an >>>>>>>>> extra lookup to the >>>>>>>>> fast path it would seem that this is the wrong trade-off to do >>>>>>>>> here. >>>>>>>> >>>>>>>> Yes, perhaps it would be best to just use Class.forName(module, >>>>>>>> className) instead. I have created a little benchmark to compare >>>>>>>> overheads (just overheads) of unsuccessful lookups for >>>>>>>> pregenerated classes (a situation where a BMH class is requested >>>>>>>> that has not been pregenerated) and here's the result for >>>>>>>> overhead of 5 unsuccessfull lookups: >>>>>>>> >>>>>>>> Benchmark (generate) (lookup) Mode Cnt >>>>>>>> Score Error Units >>>>>>>> ClassForNameBench.classForName LL,LLL,LLLL,LLLLL,LLLLLL >>>>>>>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 6800.878 ? 421.424 ns/op >>>>>>>> ClassForNameBench.classForNameInModule LL,LLL,LLLL,LLLLL,LLLLLL >>>>>>>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 209.574 ? 2.114 ns/op >>>>>>>> ClassForNameBench.hashSetContains LL,LLL,LLLL,LLLLL,LLLLLL >>>>>>>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 6.813 ? 0.317 ns/op >>>>>>>> ClassForNameBench.switchStatement LL,LLL,LLLL,LLLLL,LLLLLL >>>>>>>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 6.601 ? 0.061 ns/op >>>>>>>> >>>>>>>> ...compared to runtime BMH class generation and loading this is >>>>>>>> really a very minor overhead. I would just use >>>>>>>> Class.forName(module, className) and reduce the complexity of the >>>>>>>> plugin. >>>>>>>> >>>>>>>> What do you think? >>>>>>>> >>>>>>>> >>>>>>>> Here's the benchmark: >>>>>>>> >>>>>>>> package jdk.test; >>>>>>>> >>>>>>>> import org.openjdk.jmh.annotations.*; >>>>>>>> import org.openjdk.jmh.infra.Blackhole; >>>>>>>> >>>>>>>> import java.io.Serializable; >>>>>>>> import java.lang.invoke.MethodHandle; >>>>>>>> import java.util.Iterator; >>>>>>>> import java.util.Set; >>>>>>>> import java.util.concurrent.TimeUnit; >>>>>>>> import java.util.stream.Collectors; >>>>>>>> import java.util.stream.Stream; >>>>>>>> >>>>>>>> @BenchmarkMode(Mode.AverageTime) >>>>>>>> @Fork(value = 1, warmups = 0) >>>>>>>> @Warmup(iterations = 10) >>>>>>>> @Measurement(iterations = 10) >>>>>>>> @OutputTimeUnit(TimeUnit.NANOSECONDS) >>>>>>>> @State(Scope.Thread) >>>>>>>> public class ClassForNameBench { >>>>>>>> >>>>>>>> static final String BMH = "java/lang/invoke/BoundMethodHandle"; >>>>>>>> static final String SPECIES_PREFIX_NAME = "Species_"; >>>>>>>> static final String SPECIES_PREFIX_PATH = BMH + "$" + >>>>>>>> SPECIES_PREFIX_NAME; >>>>>>>> >>>>>>>> @Param({"LL,LLL,LLLL,LLLLL,LLLLLL"}) >>>>>>>> public String generate; >>>>>>>> >>>>>>>> @Param({"LLI,LLLI,LLLLI,LLLLLI,LLLLLLI"}) >>>>>>>> public String lookup; >>>>>>>> >>>>>>>> private String[] generatedTypes; >>>>>>>> private String[] lookedUpTypes; >>>>>>>> private Set generatedNames; >>>>>>>> private String[] lookedUpNames; >>>>>>>> >>>>>>>> @Setup(Level.Trial) >>>>>>>> public void setup() { >>>>>>>> generatedTypes = generate.trim().split("\\s+,\\s+"); >>>>>>>> lookedUpTypes = lookup.trim().split("\\s+,\\s+"); >>>>>>>> generatedNames = Stream.of(generatedTypes) >>>>>>>> .map(types -> SPECIES_PREFIX_PATH >>>>>>>> + shortenSignature(types)) >>>>>>>> .collect(Collectors.toSet()); >>>>>>>> lookedUpNames = Stream.of(lookedUpTypes) >>>>>>>> .map(types -> SPECIES_PREFIX_PATH + >>>>>>>> shortenSignature(types)) >>>>>>>> .toArray(String[]::new); >>>>>>>> } >>>>>>>> >>>>>>>> @Benchmark >>>>>>>> public void classForName(Blackhole bh) { >>>>>>>> for (String name : lookedUpNames) { >>>>>>>> try { >>>>>>>> bh.consume(Class.forName(name, false, >>>>>>>> MethodHandle.class.getClassLoader())); >>>>>>>> } catch (ClassNotFoundException e) { >>>>>>>> bh.consume(e); >>>>>>>> } >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> @Benchmark >>>>>>>> public void classForNameInModule(Blackhole bh) { >>>>>>>> for (String name : lookedUpNames) { >>>>>>>> bh.consume(Class.forName(MethodHandle.class.getModule(), name)); >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> @Benchmark >>>>>>>> public void hashSetContains(Blackhole bh) { >>>>>>>> for (String name : lookedUpNames) { >>>>>>>> bh.consume(generatedNames.contains(name)); >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> @Benchmark >>>>>>>> public void switchStatement(Blackhole bh) { >>>>>>>> for (String types : lookedUpTypes) { >>>>>>>> bh.consume(getBMHSwitch(types)); >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> static Class getBMHSwitch(String types) { >>>>>>>> // should be in sync with @Param generate above... >>>>>>>> switch (types) { >>>>>>>> case "LL": return Object.class; >>>>>>>> case "LLL": return Serializable.class; >>>>>>>> case "LLLL": return Iterator.class; >>>>>>>> case "LLLLL": return Throwable.class; >>>>>>>> case "LLLLLL": return String.class; >>>>>>>> default: return null; >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> // copied from non-public LambdaForm >>>>>>>> static String shortenSignature(String signature) { >>>>>>>> // Hack to make signatures more readable when they show >>>>>>>> up in method names. >>>>>>>> final int NO_CHAR = -1, MIN_RUN = 3; >>>>>>>> int c0, c1 = NO_CHAR, c1reps = 0; >>>>>>>> StringBuilder buf = null; >>>>>>>> int len = signature.length(); >>>>>>>> if (len < MIN_RUN) return signature; >>>>>>>> for (int i = 0; i <= len; i++) { >>>>>>>> // shift in the next char: >>>>>>>> c0 = c1; c1 = (i == len ? NO_CHAR : >>>>>>>> signature.charAt(i)); >>>>>>>> if (c1 == c0) { ++c1reps; continue; } >>>>>>>> // shift in the next count: >>>>>>>> int c0reps = c1reps; c1reps = 1; >>>>>>>> // end of a character run >>>>>>>> if (c0reps < MIN_RUN) { >>>>>>>> if (buf != null) { >>>>>>>> while (--c0reps >= 0) >>>>>>>> buf.append((char) c0); >>>>>>>> } >>>>>>>> continue; >>>>>>>> } >>>>>>>> // found three or more in a row >>>>>>>> if (buf == null) >>>>>>>> buf = new StringBuilder().append(signature, 0, i >>>>>>>> - c0reps); >>>>>>>> buf.append((char) c0).append(c0reps); >>>>>>>> } >>>>>>>> return (buf == null) ? signature : buf.toString(); >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Regards, Peter >>>>>>>> >>>>>>>>> >>>>>>>>> All-in-all I lean towards moving forward with the first, simpler >>>>>>>>> revision of this >>>>>>>>> patch[1] and then evaluate if webrev.02 or a >>>>>>>>> String-switch+static resolve >>>>>>>>> as a follow-up. >>>>>>>>> >>>>>>>>> A compromise would be to keep the SpeciesLookup class introduced >>>>>>>>> here >>>>>>>>> to allow removing all overhead in case the plugin is disabled. >>>>>>>>> >>>>>>>>> Mandy: I've not found any test (under jdk/test/tools/jlink or >>>>>>>>> elsewhere) which >>>>>>>>> has to be updated when adding a plugin like this. >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> >>>>>>>>> /Claes >>>>>>>>> >>>>>>>>> [1] http://cr.openjdk.java.net/~redestad/8152641/webrev.01/ >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> From peter.levart at gmail.com Thu Mar 31 06:55:05 2016 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 31 Mar 2016 08:55:05 +0200 Subject: RFR: 8152641: Plugin to generate BMH$Species classes ahead-of-time In-Reply-To: <56FBFC23.5090104@oracle.com> References: <56F3EEAB.4090600@oracle.com> <1FE3F7A6-1C7B-4DC6-875C-E3FAEDED08F5@oracle.com> <56F50EC5.6020500@gmail.com> <56F5520D.3080205@oracle.com> <56F676CA.5000803@gmail.com> <56FB09D3.4090000@oracle.com> <56FB82FE.5010209@gmail.com> <56FB8607.8030000@gmail.com> <56FBB014.6050002@oracle.com> <56FBC4D8.8010603@gmail.com> <56FBDF98.4090102@oracle.com> <56FBEE08.7010600@gmail.com> <56FBFC23.5090104@oracle.com> Message-ID: <56FCC9C9.2080605@gmail.com> Hi Claes, On 03/30/2016 06:17 PM, Claes Redestad wrote: > Hi Peter, > > something like this, then: > > http://cr.openjdk.java.net/~redestad/8152641/webrev.05/ > Perfect. > - Added a method only used by the plugin which validates input; added > a comment about the dependency > - Invalid types are logged but otherwise ignored now (I bet someone > might suggest a better way to handle user errors) What happens if you throw an exception in the plugin? Should jlink fail in case of invalid input? Regards, Peter > - Some cleanup, introduced constant for class name prefix and removed > duplicate type string shortening etc > > /Claes > > On 2016-03-30 17:17, Peter Levart wrote: >> Hi Claes, >> >> webrev.04 looks good now. >> >> Maybe just one nit. For production quality, plugin input could be >> verified that after expansion it is composed of just the following >> characters: "LIJFD". Otherwise ClassWriter might generate an unusable >> class without complaining (for example if someone sneaks-in >> characters 'S' 'Z' 'B' or 'C')... >> >> Or, better yet, create another method in BMH that will be the >> "public" API between the plugin and BMH which does the validation and >> calls generateConcreteBMHClassBytes(). Internally in BMH the >> validation is not necessary as the types strings are composed >> programmatically and are guaranteed to be correct. >> >> Regards, Peter >> >> On 03/30/2016 04:15 PM, Claes Redestad wrote: >>> >>> >>> On 2016-03-30 14:21, Peter Levart wrote: >>>> Hi Claes, >>>> >>>> On 03/30/2016 12:53 PM, Claes Redestad wrote: >>>>> Hi, >>>>> >>>>> I think Class.forName(Module, String) seemed like a nice >>>>> efficiency/simplicity compromise, but there is some usage of >>>>> lambdas/method-refs in the Module lookup code, especially for >>>>> exploded modules (which get exercised during JDK build). Depending >>>>> on a lambda from code in java.lang.invoke means we fail to bootstrap. >>>>> >>>>> But hey, we're living in an encapsulated world now, and this is in >>>>> java.base, so why not go directly to the BootLoader: >>>>> >>>>> http://cr.openjdk.java.net/~redestad/8152641/webrev.03/ >>>>> >>>>> Since this is what's called from Class.forName(Module, String), >>>>> the overhead should be even smaller than in your >>>>> classForNameInModule test. >>>> >>>> Good idea. >>>> >>>>> >>>>> If I call this final, will you say "Reviewed"? :-) >>>> >>>> Sorry, I don't posses the powers. :-) >>>> >>>> I could say "rEVIEWED", but... >>>> >>>> In the plugin, the input is shortened speciesTypes strings. What >>>> guarantees that they really are normalized? For example, If one >>>> specifies "LLL" as input, it will get expanded into "LLL", the >>>> generated class will have "_L3" as a name suffix, but you will pack >>>> it in the image with "_LLL.class" filename suffix. >>>> >>>> That's another reason why a method in BoundMethodHandle$Factory >>>> with the following signature: >>>> >>>> Map.Entry generateConcreteBMHClassBytes(String types); >>>> >>>> ...would be a good idea. It would return class bytes and the name >>>> of the class which you could use to derive the class filename >>>> without hardcoding the same logic in plugin and in BMH. >>>> >>>> You just move the "LambdaForm.shortenSignature(types)" from >>>> getConcreteBMHClass and className/sourceFile calculation from >>>> generateConcreteBMHClass down to generateConcreteBMHClassBytes >>>> method and change the signatures... >>> >>> Yes, it makes sense to keep control over the class name inside the >>> factory class, and this does allow specifying shortened or expanded >>> forms (L3 vs LLL) interchangeably as input to the plugin, which >>> reduces possibility for user errors. >>> >>> How about this: http://cr.openjdk.java.net/~redestad/8152641/webrev.04/ >>> >>> /Claes >>> >>>> >>>> Regards, Peter >>>> >>>>> >>>>> /Claes >>>>> >>>>> PS: The default list of types is generated in a few adhoc tests >>>>> not part of this patch. I'm considering proposing add support for >>>>> generating this list at build time. Maybe a JEP called "Build >>>>> system support for profile-guided optimizations", which could also >>>>> handle https://bugs.openjdk.java.net/browse/JDK-8150044 >>>>> >>>>> On 2016-03-30 09:53, Peter Levart wrote: >>>>>> Hi Claes, >>>>>> >>>>>> Sorry, I found a flaw in the benchmark (the regex pattern to >>>>>> split comma-separated string into substrings was wrong). What the >>>>>> benchmark did was compare the overheads of a single lookup of a >>>>>> longer class name containing commas. Here's the corrected result >>>>>> of overheads of 5 unsuccessful lookups: >>>>>> >>>>>> Benchmark (generate) (lookup) Mode >>>>>> Cnt Score Error Units >>>>>> ClassForNameBench.classForName LL,LLL,LLLL,LLLLL,LLLLLL >>>>>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 29627.141 ? 567.427 ns/op >>>>>> ClassForNameBench.classForNameInModule LL,LLL,LLLL,LLLLL,LLLLLL >>>>>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 1073.256 ? 23.794 ns/op >>>>>> ClassForNameBench.hashSetContains LL,LLL,LLLL,LLLLL,LLLLLL >>>>>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 33.022 ? 0.066 ns/op >>>>>> ClassForNameBench.switchStatement LL,LLL,LLLL,LLLLL,LLLLLL >>>>>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 38.498 ? 5.842 ns/op >>>>>> >>>>>> ...overheads are a little bigger (x5 approx.). >>>>>> >>>>>> >>>>>> Here's the corrected benchmark: >>>>>> >>>>>> >>>>>> package jdk.test; >>>>>> >>>>>> import org.openjdk.jmh.annotations.*; >>>>>> import org.openjdk.jmh.infra.Blackhole; >>>>>> >>>>>> import java.io.Serializable; >>>>>> import java.lang.invoke.MethodHandle; >>>>>> import java.util.Iterator; >>>>>> import java.util.Set; >>>>>> import java.util.concurrent.TimeUnit; >>>>>> import java.util.stream.Collectors; >>>>>> import java.util.stream.Stream; >>>>>> >>>>>> @BenchmarkMode(Mode.AverageTime) >>>>>> @Fork(value = 1, warmups = 0) >>>>>> @Warmup(iterations = 10) >>>>>> @Measurement(iterations = 10) >>>>>> @OutputTimeUnit(TimeUnit.NANOSECONDS) >>>>>> @State(Scope.Thread) >>>>>> public class ClassForNameBench { >>>>>> >>>>>> static final String BMH = "java/lang/invoke/BoundMethodHandle"; >>>>>> static final String SPECIES_PREFIX_NAME = "Species_"; >>>>>> static final String SPECIES_PREFIX_PATH = BMH + "$" + >>>>>> SPECIES_PREFIX_NAME; >>>>>> >>>>>> @Param({"LL,LLL,LLLL,LLLLL,LLLLLL"}) >>>>>> public String generate; >>>>>> >>>>>> @Param({"LLI,LLLI,LLLLI,LLLLLI,LLLLLLI"}) >>>>>> public String lookup; >>>>>> >>>>>> private String[] generatedTypes; >>>>>> private String[] lookedUpTypes; >>>>>> private Set generatedNames; >>>>>> private String[] lookedUpNames; >>>>>> >>>>>> @Setup(Level.Trial) >>>>>> public void setup() { >>>>>> generatedTypes = generate.trim().split("\\s*,\\s*"); >>>>>> lookedUpTypes = lookup.trim().split("\\s*,\\s*"); >>>>>> generatedNames = Stream.of(generatedTypes) >>>>>> .map(types -> SPECIES_PREFIX_PATH >>>>>> + shortenSignature(types)) >>>>>> .collect(Collectors.toSet()); >>>>>> lookedUpNames = Stream.of(lookedUpTypes) >>>>>> .map(types -> SPECIES_PREFIX_PATH + >>>>>> shortenSignature(types)) >>>>>> .toArray(String[]::new); >>>>>> } >>>>>> >>>>>> @Benchmark >>>>>> public void classForName(Blackhole bh) { >>>>>> for (String name : lookedUpNames) { >>>>>> try { >>>>>> bh.consume(Class.forName(name, false, >>>>>> MethodHandle.class.getClassLoader())); >>>>>> } catch (ClassNotFoundException e) { >>>>>> bh.consume(e); >>>>>> } >>>>>> } >>>>>> } >>>>>> >>>>>> @Benchmark >>>>>> public void classForNameInModule(Blackhole bh) { >>>>>> for (String name : lookedUpNames) { >>>>>> bh.consume(Class.forName(MethodHandle.class.getModule(), name)); >>>>>> } >>>>>> } >>>>>> >>>>>> @Benchmark >>>>>> public void hashSetContains(Blackhole bh) { >>>>>> for (String name : lookedUpNames) { >>>>>> bh.consume(generatedNames.contains(name)); >>>>>> } >>>>>> } >>>>>> >>>>>> @Benchmark >>>>>> public void switchStatement(Blackhole bh) { >>>>>> for (String types : lookedUpTypes) { >>>>>> bh.consume(getBMHSwitch(types)); >>>>>> } >>>>>> } >>>>>> >>>>>> static Class getBMHSwitch(String types) { >>>>>> // should be in sync with @Param generate above... >>>>>> switch (types) { >>>>>> case "LL": return Object.class; >>>>>> case "LLL": return Serializable.class; >>>>>> case "LLLL": return Iterator.class; >>>>>> case "LLLLL": return Throwable.class; >>>>>> case "LLLLLL": return String.class; >>>>>> default: return null; >>>>>> } >>>>>> } >>>>>> >>>>>> // copied from non-public LambdaForm >>>>>> static String shortenSignature(String signature) { >>>>>> // Hack to make signatures more readable when they show >>>>>> up in method names. >>>>>> final int NO_CHAR = -1, MIN_RUN = 3; >>>>>> int c0, c1 = NO_CHAR, c1reps = 0; >>>>>> StringBuilder buf = null; >>>>>> int len = signature.length(); >>>>>> if (len < MIN_RUN) return signature; >>>>>> for (int i = 0; i <= len; i++) { >>>>>> // shift in the next char: >>>>>> c0 = c1; c1 = (i == len ? NO_CHAR : signature.charAt(i)); >>>>>> if (c1 == c0) { ++c1reps; continue; } >>>>>> // shift in the next count: >>>>>> int c0reps = c1reps; c1reps = 1; >>>>>> // end of a character run >>>>>> if (c0reps < MIN_RUN) { >>>>>> if (buf != null) { >>>>>> while (--c0reps >= 0) >>>>>> buf.append((char) c0); >>>>>> } >>>>>> continue; >>>>>> } >>>>>> // found three or more in a row >>>>>> if (buf == null) >>>>>> buf = new StringBuilder().append(signature, 0, i >>>>>> - c0reps); >>>>>> buf.append((char) c0).append(c0reps); >>>>>> } >>>>>> return (buf == null) ? signature : buf.toString(); >>>>>> } >>>>>> } >>>>>> >>>>>> >>>>>> Regards, Peter >>>>>> >>>>>> >>>>>> >>>>>> On 03/30/2016 09:40 AM, Peter Levart wrote: >>>>>>> Hi Claes, >>>>>>> >>>>>>> On 03/30/2016 01:03 AM, Claes Redestad wrote: >>>>>>>> Hi Peter, Mandy, >>>>>>>> >>>>>>>> On 2016-03-26 12:47, Peter Levart wrote: >>>>>>>>> >>>>>>>>> Comparing this with proposed code from webrev: >>>>>>>>> >>>>>>>>> 493 try { >>>>>>>>> 494 return (Class>>>>>>>> BoundMethodHandle>) >>>>>>>>> 495 >>>>>>>>> Class.forName("java.lang.invoke.BoundMethodHandle$Species_" + >>>>>>>>> LambdaForm.shortenSignature(types)); >>>>>>>>> 496 } catch (ClassNotFoundException >>>>>>>>> cnf) { >>>>>>>>> 497 // Not pregenerated, generate >>>>>>>>> the class >>>>>>>>> 498 return >>>>>>>>> generateConcreteBMHClass(types); >>>>>>>>> 499 } >>>>>>>>> >>>>>>>>> >>>>>>>>> ...note that the function passed to >>>>>>>>> CLASS_CACHE.computeIfAbsent is executed just once per distinct >>>>>>>>> 'types' argument. Even if you put the generated switch between >>>>>>>>> a call to getConcreteBMHClass and CLASS_CACHE.computeIfAbsent, >>>>>>>>> getConcreteBMHClass(String types) is executed just once per >>>>>>>>> distinct 'types' argument (except in rare occasions when VM >>>>>>>>> can not initialize the loaded class). >>>>>>>>> >>>>>>>>> In this respect a successful Class.forName() is not any worse >>>>>>>>> than static resolving. It's just that unsuccessful >>>>>>>>> Class.forName() represents some overhead for classes that are >>>>>>>>> not pre-generated. So an alternative way to get rid of that >>>>>>>>> overhead is to have a HashSet of 'types' strings for >>>>>>>>> pre-generated classes at hand in order to decide whether to >>>>>>>>> call Class.forName or generateConcreteBMHClass. >>>>>>>>> >>>>>>>>> What's easier to support is another question. >>>>>>>>> >>>>>>>>> Regards, Peter >>>>>>>> >>>>>>>> to have something to compare with I built a version which, like >>>>>>>> you suggest, >>>>>>>> generates a HashSet with the set of generated classes here: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~redestad/8152641/webrev.02/ >>>>>>>> >>>>>>>> This adds a fair bit of complexity to the plugin and requires >>>>>>>> we add a nested >>>>>>>> class in BoundMethodHandle that we can replace. Using the >>>>>>>> anonymous >>>>>>>> compute Function for this seems like the best choice for this. >>>>>>> >>>>>>> ...what I had in mind as alternative to a pregenerated class >>>>>>> with a switch was a simple textual resource file, generated by >>>>>>> plugin, read-in by BMH into a HashSet. No special-purpose class >>>>>>> generation and much less complexity for the plugin. >>>>>>> >>>>>>>> >>>>>>>> I've not been able to measure any statistical difference in >>>>>>>> real startup terms, >>>>>>>> though, and not figured out a smart way to benchmark the >>>>>>>> overhead of the >>>>>>>> CNFE in relation to the class generation (my guess it adds a >>>>>>>> fraction to the >>>>>>>> total cost) and since this adds ever so little footprint and an >>>>>>>> extra lookup to the >>>>>>>> fast path it would seem that this is the wrong trade-off to do >>>>>>>> here. >>>>>>> >>>>>>> Yes, perhaps it would be best to just use Class.forName(module, >>>>>>> className) instead. I have created a little benchmark to compare >>>>>>> overheads (just overheads) of unsuccessful lookups for >>>>>>> pregenerated classes (a situation where a BMH class is requested >>>>>>> that has not been pregenerated) and here's the result for >>>>>>> overhead of 5 unsuccessfull lookups: >>>>>>> >>>>>>> Benchmark (generate) (lookup) Mode >>>>>>> Cnt Score Error Units >>>>>>> ClassForNameBench.classForName LL,LLL,LLLL,LLLLL,LLLLLL >>>>>>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 6800.878 ? 421.424 ns/op >>>>>>> ClassForNameBench.classForNameInModule LL,LLL,LLLL,LLLLL,LLLLLL >>>>>>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 209.574 ? 2.114 ns/op >>>>>>> ClassForNameBench.hashSetContains LL,LLL,LLLL,LLLLL,LLLLLL >>>>>>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 6.813 ? 0.317 ns/op >>>>>>> ClassForNameBench.switchStatement LL,LLL,LLLL,LLLLL,LLLLLL >>>>>>> LLI,LLLI,LLLLI,LLLLLI,LLLLLLI avgt 10 6.601 ? 0.061 ns/op >>>>>>> >>>>>>> ...compared to runtime BMH class generation and loading this is >>>>>>> really a very minor overhead. I would just use >>>>>>> Class.forName(module, className) and reduce the complexity of >>>>>>> the plugin. >>>>>>> >>>>>>> What do you think? >>>>>>> >>>>>>> >>>>>>> Here's the benchmark: >>>>>>> >>>>>>> package jdk.test; >>>>>>> >>>>>>> import org.openjdk.jmh.annotations.*; >>>>>>> import org.openjdk.jmh.infra.Blackhole; >>>>>>> >>>>>>> import java.io.Serializable; >>>>>>> import java.lang.invoke.MethodHandle; >>>>>>> import java.util.Iterator; >>>>>>> import java.util.Set; >>>>>>> import java.util.concurrent.TimeUnit; >>>>>>> import java.util.stream.Collectors; >>>>>>> import java.util.stream.Stream; >>>>>>> >>>>>>> @BenchmarkMode(Mode.AverageTime) >>>>>>> @Fork(value = 1, warmups = 0) >>>>>>> @Warmup(iterations = 10) >>>>>>> @Measurement(iterations = 10) >>>>>>> @OutputTimeUnit(TimeUnit.NANOSECONDS) >>>>>>> @State(Scope.Thread) >>>>>>> public class ClassForNameBench { >>>>>>> >>>>>>> static final String BMH = "java/lang/invoke/BoundMethodHandle"; >>>>>>> static final String SPECIES_PREFIX_NAME = "Species_"; >>>>>>> static final String SPECIES_PREFIX_PATH = BMH + "$" + >>>>>>> SPECIES_PREFIX_NAME; >>>>>>> >>>>>>> @Param({"LL,LLL,LLLL,LLLLL,LLLLLL"}) >>>>>>> public String generate; >>>>>>> >>>>>>> @Param({"LLI,LLLI,LLLLI,LLLLLI,LLLLLLI"}) >>>>>>> public String lookup; >>>>>>> >>>>>>> private String[] generatedTypes; >>>>>>> private String[] lookedUpTypes; >>>>>>> private Set generatedNames; >>>>>>> private String[] lookedUpNames; >>>>>>> >>>>>>> @Setup(Level.Trial) >>>>>>> public void setup() { >>>>>>> generatedTypes = generate.trim().split("\\s+,\\s+"); >>>>>>> lookedUpTypes = lookup.trim().split("\\s+,\\s+"); >>>>>>> generatedNames = Stream.of(generatedTypes) >>>>>>> .map(types -> SPECIES_PREFIX_PATH >>>>>>> + shortenSignature(types)) >>>>>>> .collect(Collectors.toSet()); >>>>>>> lookedUpNames = Stream.of(lookedUpTypes) >>>>>>> .map(types -> SPECIES_PREFIX_PATH >>>>>>> + shortenSignature(types)) >>>>>>> .toArray(String[]::new); >>>>>>> } >>>>>>> >>>>>>> @Benchmark >>>>>>> public void classForName(Blackhole bh) { >>>>>>> for (String name : lookedUpNames) { >>>>>>> try { >>>>>>> bh.consume(Class.forName(name, false, >>>>>>> MethodHandle.class.getClassLoader())); >>>>>>> } catch (ClassNotFoundException e) { >>>>>>> bh.consume(e); >>>>>>> } >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> @Benchmark >>>>>>> public void classForNameInModule(Blackhole bh) { >>>>>>> for (String name : lookedUpNames) { >>>>>>> bh.consume(Class.forName(MethodHandle.class.getModule(), name)); >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> @Benchmark >>>>>>> public void hashSetContains(Blackhole bh) { >>>>>>> for (String name : lookedUpNames) { >>>>>>> bh.consume(generatedNames.contains(name)); >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> @Benchmark >>>>>>> public void switchStatement(Blackhole bh) { >>>>>>> for (String types : lookedUpTypes) { >>>>>>> bh.consume(getBMHSwitch(types)); >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> static Class getBMHSwitch(String types) { >>>>>>> // should be in sync with @Param generate above... >>>>>>> switch (types) { >>>>>>> case "LL": return Object.class; >>>>>>> case "LLL": return Serializable.class; >>>>>>> case "LLLL": return Iterator.class; >>>>>>> case "LLLLL": return Throwable.class; >>>>>>> case "LLLLLL": return String.class; >>>>>>> default: return null; >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> // copied from non-public LambdaForm >>>>>>> static String shortenSignature(String signature) { >>>>>>> // Hack to make signatures more readable when they show >>>>>>> up in method names. >>>>>>> final int NO_CHAR = -1, MIN_RUN = 3; >>>>>>> int c0, c1 = NO_CHAR, c1reps = 0; >>>>>>> StringBuilder buf = null; >>>>>>> int len = signature.length(); >>>>>>> if (len < MIN_RUN) return signature; >>>>>>> for (int i = 0; i <= len; i++) { >>>>>>> // shift in the next char: >>>>>>> c0 = c1; c1 = (i == len ? NO_CHAR : >>>>>>> signature.charAt(i)); >>>>>>> if (c1 == c0) { ++c1reps; continue; } >>>>>>> // shift in the next count: >>>>>>> int c0reps = c1reps; c1reps = 1; >>>>>>> // end of a character run >>>>>>> if (c0reps < MIN_RUN) { >>>>>>> if (buf != null) { >>>>>>> while (--c0reps >= 0) >>>>>>> buf.append((char) c0); >>>>>>> } >>>>>>> continue; >>>>>>> } >>>>>>> // found three or more in a row >>>>>>> if (buf == null) >>>>>>> buf = new StringBuilder().append(signature, 0, i >>>>>>> - c0reps); >>>>>>> buf.append((char) c0).append(c0reps); >>>>>>> } >>>>>>> return (buf == null) ? signature : buf.toString(); >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regards, Peter >>>>>>> >>>>>>>> >>>>>>>> All-in-all I lean towards moving forward with the first, >>>>>>>> simpler revision of this >>>>>>>> patch[1] and then evaluate if webrev.02 or a >>>>>>>> String-switch+static resolve >>>>>>>> as a follow-up. >>>>>>>> >>>>>>>> A compromise would be to keep the SpeciesLookup class >>>>>>>> introduced here >>>>>>>> to allow removing all overhead in case the plugin is disabled. >>>>>>>> >>>>>>>> Mandy: I've not found any test (under jdk/test/tools/jlink or >>>>>>>> elsewhere) which >>>>>>>> has to be updated when adding a plugin like this. >>>>>>>> >>>>>>>> Thanks! >>>>>>>> >>>>>>>> /Claes >>>>>>>> >>>>>>>> [1] http://cr.openjdk.java.net/~redestad/8152641/webrev.01/ >>>>>>> >>>>>> >>>>> >>>> >>> >> > From frank.yuan at oracle.com Thu Mar 31 09:54:53 2016 From: frank.yuan at oracle.com (Frank Yuan) Date: Thu, 31 Mar 2016 17:54:53 +0800 Subject: RFR: 8078820: Test deploying a XML parser as a module In-Reply-To: <56F782FB.3040004@oracle.com> References: <047201d185a8$0cb937c0$262ba740$@oracle.com> <56F3B3B5.9060804@oracle.com> <055601d185b2$ce366800$6aa33800$@oracle.com> <56F70839.3040707@oracle.com> <56F782FB.3040004@oracle.com> Message-ID: <028401d18b33$61521fa0$23f65ee0$@oracle.com> Hi Alan, Joe, and All I have produced a new webrev http://cr.openjdk.java.net/~fyuan/8078820/webrev.01/ based on your comments, there are 2 tests: 1. BasicModularXMLParserTest.java, which is same as the previous one, tests the customized xml provider modules in boot layer 2. LayerModularXMLParserTest.java, which is suggested by Alan, it tests the different combinations of providers, application and layers. Would you like to review it again? Thank you! Best Regards Frank From: Alan Bateman [mailto:Alan.Bateman at oracle.com] Sent: Sunday, March 27, 2016 2:52 PM To: huizhe wang ; Frank Yuan Subject: Re: RFR: 8078820: Test deploying a XML parser as a module On 26/03/2016 22:07, huizhe wang wrote: On 3/24/2016 2:51 AM, Frank Yuan wrote: To Joe Need I wait for org.xml.sax.helpers.XMLReaderFactory? or leave it till later? Up to you. I don't know how urgent this task is.? The XMLReaderFactory might take a while to get fixed. We may go ahead with our own plan to update it since I haven't heard from the SAX project yet. Even so, it still might take weeks. But once it's in place, it will be exactly the same as other factories with regard to the way it works in modules. We can always come back to the test once we have a solution for the SAX API. So I suggest go ahead and work with Frank to get this test in. I think it should co-locate with the existing unit tests. -Alan. From sgrinove at redhat.com Thu Mar 31 10:20:15 2016 From: sgrinove at redhat.com (Sanne Grinovero) Date: Thu, 31 Mar 2016 11:20:15 +0100 Subject: Unexpected ClassnotFoundException on reflective Class#getMethod In-Reply-To: <56FC4E1C.3030301@oracle.com> References: <56FC4E1C.3030301@oracle.com> Message-ID: Thanks Alex, that clarifies a lot, I was just about to try with a different dependency. So this is not a reflection bug, but I'm just realising now that has quite significant impact on JavaEE: the Synchronization type is defined as public API of the specification [1]. Changing the JavaEE API isn't going to be very popular, so I guess the expectation is for containers to regularly override the modules? This won't affect just the regular EE application servers, as these APIs are often used also in standalone JavaSE applications, as many components of the JavaEE spec can be run in "standalone" or "embedded" modes. For example Hibernate will now have to require the application launcher to apply customizations to the JVM boot parameters, and probably so any other JPA implementation. 1 - http://docs.oracle.com/javaee/7/api/javax/transaction/Synchronization.html Thanks, Sanne On Wed, Mar 30, 2016 at 11:07 PM, Alex Buckley wrote: > The JDK 9b111 runtime image includes the java.transaction module which > exports the javax.transaction package. The application class loader will try > to load javax.transaction.* types from there, not from a JAR on the > classpath. As you probably guess, the JDK's java.transaction module does not > contain the javax.transaction.Synchronization type. > > You can either supply an alternate java.transaction module to override the > one in the JDK (-upgrademodulepath), or you can inject your additional > classes directly into the module in the JDK (-Xpatch). Please see JEP 261. > > Alex > > > On 3/30/2016 2:39 PM, Sanne Grinovero wrote: >> >> Hello all, >> looks like I've found an issue on invoking Class#getMethod. >> >> This method is used by Maven when scanning the project's classpath to >> identify JUnit tests - which it does by default on any Maven project - >> so I'm afraid the impact could be quite large. >> >> I've been able to narrow it down to this small test which doesn't need >> neither Maven nor JUnit, however to reproduce the issue the project >> must have a dependency to some third party jar. >> In this reproducer I'm using javax.transaction.Synchronization, a copy >> can be obtained from: >> - >> https://repository.jboss.org/nexus/service/local/repositories/central/content/org/jboss/spec/javax/transaction/jboss-transaction-api_1.2_spec/1.0.0.Final/jboss-transaction-api_1.2_spec-1.0.0.Final.jar >> >> >> ==== Main.java ==== >> public class Main { >> >> public static void main(String[] args) { >> Class clazz = SecondClass.class; >> try { >> clazz.getMethod("notexisting", new Class[0]); >> } catch (NoSuchMethodException e) { >> e.printStackTrace(); >> } >> System.out.println("All good"); >> } >> >> } >> ==== SecondClass.java ==== >> import javax.transaction.Synchronization; >> >> public class SecondClass { >> >> public void registerSynchronization(Synchronization synchronization) { >> } >> >> } >> ==== EOF ==== >> >> >> On Java8 or Java9 build 9-ea+110 the output is, as expected: >> >>> java.lang.NoSuchMethodException: SecondClass.notexisting() >>> at java.lang.Class.getMethod(Class.java:1786) >>> at Main.main(Main.java:6) >>> All good >> >> >> >> On Java9 build 9-ea+111 though I'll have this: >> >>> Exception in thread "main" java.lang.NoClassDefFoundError: >>> javax/transaction/Synchronization >>> at java.lang.Class.getDeclaredMethods0(java.base at 9-ea/Native Method) >>> at >>> java.lang.Class.privateGetDeclaredMethods(java.base at 9-ea/Class.java:2937) >>> at >>> java.lang.Class.privateGetMethodRecursive(java.base at 9-ea/Class.java:3282) >>> at java.lang.Class.getMethod0(java.base at 9-ea/Class.java:3252) >>> at java.lang.Class.getMethod(java.base at 9-ea/Class.java:1961) >>> at Main.main(Main.java:6) >>> Caused by: java.lang.ClassNotFoundException: >>> javax.transaction.Synchronization >>> at >>> jdk.internal.loader.BuiltinClassLoader.loadClass(java.base at 9-ea/BuiltinClassLoader.java:368) >>> at >>> jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(java.base at 9-ea/ClassLoaders.java:185) >>> at java.lang.ClassLoader.loadClass(java.base at 9-ea/ClassLoader.java:419) >>> ... 6 more >> >> >> I hope I have sent this to the right mailing list. >> I've reported the same issue on bugreport.java.com, but the only ID I >> have about that report is the "Review ID": JI-9033943 >> The reproducer in this email is much better than in the other report, >> I can't check what I sent but I believe I might have sent an outdated >> version; apologies for any confusion. >> >> Thanks, >> Sanne Grinovero >> > From Alan.Bateman at oracle.com Thu Mar 31 11:09:50 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 31 Mar 2016 12:09:50 +0100 Subject: Unexpected ClassnotFoundException on reflective Class#getMethod In-Reply-To: References: <56FC4E1C.3030301@oracle.com> Message-ID: <56FD057E.8060602@oracle.com> On 31/03/2016 11:20, Sanne Grinovero wrote: > Thanks Alex, > that clarifies a lot, I was just about to try with a different dependency. > > So this is not a reflection bug, but I'm just realising now that has > quite significant impact on JavaEE: > the Synchronization type is defined as public API of the specification [1]. > > Changing the JavaEE API isn't going to be very popular, so I guess the > expectation is for > containers to regularly override the modules? > This won't affect just the regular EE application servers, as these > APIs are often used also > in standalone JavaSE applications, as many components of the JavaEE spec can > be run in "standalone" or "embedded" modes. > > For example Hibernate will now have to require the application launcher to apply > customizations to the JVM boot parameters, and probably so any other JPA > implementation. > > 1 - http://docs.oracle.com/javaee/7/api/javax/transaction/Synchronization.html > Java EE implementations have always upgraded/replaced a number of APIs that are "shared" with Java SE. The JSR-250 defined "Common Annotations" is another example where Java SE defines a subset of the API and Java EE implementations need the deploy with the full API. So there isn't anything forcing anyone to change APIs, this is really just about how to compile or run with the Java EE versions of these components. With JDK 8 and older then the only supported way of upgrading these components was the Endorsed Standards Override Mechanism. It turns out that this wasn't widely used and instead app servers and others have been putting JAR files on the class path with these components. Incredibly this worked even though it wasn't actually overriding the classes in the Java SE defined subset. Moving to modules means that EE servers will need to deploy with the EE versions of these modules. Adding the class path isn't going to work because the module system will prohibit splitting packages between modules and the class path. The way to do this is, as Alex mentioned, is the upgrade module path. Patching will work too, at least to get something going. In this case you can patch the java.transaction module with: -Xpatch:java.transaction=transaction-api_1.2.jar There aren't any additional packages exported in the EE version so -XaddExports isn't neded. The equivalent with the Common Annotations would need -XaddExports because the EE version has APIs in packages that Java SE does not define. One final thing to mention is that there is a proposal in the works to not resolve the EE modules when compiling code in the unnamed module or running code where the initial class is on the class path. For existing deployments then it would looking like that the JDK doesn't have the EE modules. This isn't fully implemented in the current builds but it is a proposal that will make migration to JDK 9 much easier for many. For those using the EE components outside the context of an app server then it would mean using `-addmods java.se.ee` so that all of the EE modules are resolved. I'm sure there will be more on this topic soon. -Alan From russell.gold at oracle.com Thu Mar 31 14:00:10 2016 From: russell.gold at oracle.com (Russell Gold) Date: Thu, 31 Mar 2016 10:00:10 -0400 Subject: modulepath and classpath mixture In-Reply-To: References: <56CC57A1.2050109@oracle.com> <56F2440A.7010505@oracle.com> <56F2914C.3030706@oracle.com> <56F2B3DA.402@oracle.com> <1228911717.349701.1459160027285.JavaMail.zimbra@u-pem.fr> <0CC4E4A6-4152-4BB0-BB42-B9E284540BB6@oracle.com> <6FB0B05A-6850-42F4-A6A3-42B7486CCDAA@oracle.com> Message-ID: <3C03FCA8-01DB-4146-8528-E27096453476@oracle.com> Hi Paul, No, it does not make sense, if you are writing unit tests. Unit tests often access classes and methods that general uses of the module should not. On the other hand, it could make perfect sense to run the code as a module in a functional test. Functional/integration/acceptance tests should only access what users of the module can access, and don?t need to be in the same packages as the code, since the users of that code aren?t. Regards, Russ > On Mar 30, 2016, at 3:13 PM, Paul Benedict wrote: > > Russell, you ask a good question. If an artifact is meant to be a module, wouldn't it make sense for it to run as a module during testing too? Those boundaries should be activated like they are in production to get good confidence in the code. Those are my two cents. I'd like to hear opposing opinions though why the boundaries shouldn't be there. > > Cheers, > Paul > > On Wed, Mar 30, 2016 at 2:07 PM, Russell Gold > wrote: > Hi Paul, > > Why would you put your main code on the module path during a unit test? It seems to me that unit tests are explicitly about making sure that the code works, not the packaging. So you put both main and test code on the classpath, and there is no problem. The unit test can be done before the main code is packaged into a module. > > - Russ > >> On Mar 30, 2016, at 10:47 AM, Paul Benedict > wrote: >> >> Russell, if you have a module with package X and a classpath jar with package X, the module can't see package X from the classpath. >> >> In the last several posts, there's been discussion on putting tests on the classpath; keeping the "main" code in the module. So given what I stated above, that's what I've been referring to. >> >> Cheers, >> Paul >> >> On Wed, Mar 30, 2016 at 7:28 AM, Russell Gold > wrote: >> Hi Paul, >> >> Could you explain? What kind of code do you mean cannot access it? And what do you mean by ?a split package situation?? >> >> From a conversation I had with Alan, earlier in this thread: >> >> >>> On Mar 23, 2016, at 11:42 AM, Alan Bateman > wrote: >>> >>> On 23/03/2016 14:15, Russell Gold wrote: >>>> Here are my assumptions, which you can correct. >>>> >>>> 1. A jar or classes directory placed on a class path are treated as part of the unnamed module >>> Yes >> >> >> So if the tests and main code are both in directories, which they have been up to now in Maven, why would there be a problem? Both would be in the unnamed module and able to access one another. >> >> - Russ >> >>> On Mar 29, 2016, at 10:47 PM, Paul Benedict > wrote: >>> >>> Russell, when you drop a jar on the classpath, module code will not be able to access it in a split package situation. That's the big barrier here. Maven test projects are typically written with the same package shared with the "main" code. >>> >>> Cheers, >>> Paul >>> >>> On Tue, Mar 29, 2016 at 11:33 AM, Russell Gold > wrote: >>> Hi Stephen, >>> >>> Why do you need any kind of friend access? >>> >>> It seems to me that this is making things harder than they need to be. The tests can simply run with the production code on the class path, and then there are no module issues at all. >>> >>> I think a larger problem is that you can do what I just said with the jars, even a jar which has been designated as a module by virtue of having a module-info.class in it. That means that, when users are up taking jars, they are not prevented from accessing module internals. They can put the jars on the module path, of course, but they can still use them on the class path! >>> >>> - Russ >>> >>> > >>> > On 28 March 2016 at 11:13, Remi Forax > wrote: >>> >> Hi Stephen, Hi all, >>> >> I think that delivering tests as a separated module is a bad idea. >>> >> >>> >> I see that from the point of a developer, seeing the code and the test as different modules can be attractive because everything seems to be put at the right place but there is a big drawback. Because modules are reified at runtime, it means that the runtime environment of the tests will be different from the production environment. >>> > >>> > This last sentence doesn't make sense to me - tests are not run in a >>> > production environment. >>> > >>> > Tests have all the qualities of modules - code, dependencies, >>> > compilation phase, deployment. The only special part is the need for >>> > special "friend-like" access, which Jigsaw already has for other cases >>> > (the export...to clause). >>> > >>> > Put simply, I consider that module = >>> > deployment-artifact-with-dependencies. With that mental model, putting >>> > tests inside the module is just not acceptable, because tests should >>> > not be deployed with the main application and they have different >>> > dependencies. If we disagree that module = >>> > deployment-artifact-with-dependencies, then perhaps we have bigger >>> > problems to solve here. >>> > >>> > Stephen >>> > (And to Paul Benedict, the classpath is going to die over time, so any >>> > solution that uses that is flawed IMO). >>> > >>> > >>> >> So as Alan said, from the jigsaw point of view at runtime, the tests and the code should be in the same module. >>> >> >>> >> So the building tools have to come with a way to support to have 2 different module-info.java in two different folders and package them as one module, >>> >> maybe javac should help by providing a way to merge 2 module-info at compile time. >>> >> >>> >> R?mi >>> >> >>> >> ----- Mail original ----- >>> >>> De: "Alan Bateman" > >>> >>> ?: "Stephen Colebourne" >, "jigsaw-dev" > >>> >>> Envoy?: Mercredi 23 Mars 2016 16:18:50 >>> >>> Objet: Re: modulepath and classpath mixture >>> >>> >>> >>> >>> >>> On 23/03/2016 14:42, Stephen Colebourne wrote: >>> >>>> : >>> >>>> >>> >>>> I don't particularly care what the mechanism is for this, but at the >>> >>>> requirements level: >>> >>>> - there are two modules - main and test >>> >>>> - each has its own source tree >>> >>>> - each has its own dependencies >>> >>>> - each is released separately >>> >>>> - each could be hosted on a central repo >>> >>>> - the test module needs to be able to contain the same packages as the >>> >>>> main module >>> >>>> - the test module needs to be able to invoke package-scoped code in >>> >>>> the same package in the main module >>> >>>> >>> >>>> To clarify further consider 4 modules, A, B, A-test and B-test where B >>> >>>> depends on A. Module A-test may have a method foo() that uses package >>> >>>> scope to access something in A. Module B-test will depend on A-test >>> >>>> and rely on foo() to get access to that internal object. >>> >>> To your list, I would add the ability to make use of testing frameworks >>> >>> like TestNG and JUnit. >>> >>> >>> >>> In any case, and as things currently stand, you've got most of the >>> >>> above. One differences is that the tests are not a separate module, they >>> >>> are instead compiled and run in a way that patches the main module. The >>> >>> second difference is that they don't have their own module declaration, >>> >>> instead the compilation or run augments the dependences with any >>> >>> additional dependences that the tests have. As I said, if they tools >>> >>> makes it easy then I don't think it's too bad. >>> >>> >>> >>>> >>> >>>> (Note that I view the thread discussion of >>> >>>> references to test classes on the classpath as another hack. >>> >>>> >>> >>> Packages can't be split between modules and classpath so there is no >>> >>> support for that. >>> >>> >>> >>> -Alan >>> >>> From alan.bateman at oracle.com Thu Mar 31 14:16:20 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 31 Mar 2016 14:16:20 +0000 Subject: hg: jigsaw/jake: 18 new changesets Message-ID: <201603311416.u2VEGKqk003856@aojmv0008.oracle.com> Changeset: 5d868c42d888 Author: erikj Date: 2016-03-14 12:00 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/5d868c42d888 8151619: genSocketOptionRegistry.exe always relinked on Windows Reviewed-by: tbell ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh ! make/common/NativeCompilation.gmk Changeset: 231e382d724e Author: erikj Date: 2016-03-15 11:08 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/231e382d724e 8151726: Introduce a JPRT testset buildinfra Reviewed-by: tbell, dholmes ! common/conf/jib-profiles.js ! make/jprt.properties Changeset: 0c4c33965d4c Author: lana Date: 2016-03-15 14:48 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/0c4c33965d4c Merge Changeset: d28be9fe5ab8 Author: erikj Date: 2016-03-16 13:36 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/d28be9fe5ab8 8151800: Jib profile for open linux should produce compact profiles images by default Reviewed-by: dholmes ! common/conf/jib-profiles.js Changeset: 9d77f922d694 Author: andrew Date: 2016-03-19 01:28 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/9d77f922d694 8151841: Build needs additional flags to compile with GCC 6 Summary: C++ standard needs to be explicitly set and some optimisations turned off to build on GCC 6 Reviewed-by: erikj, dholmes, kbarrett ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/hotspot-spec.gmk.in ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 Changeset: ad7fd6bb92e0 Author: simonis Date: 2016-03-03 16:20 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/ad7fd6bb92e0 8150646: Add support for blocking compiles though whitebox API Reviewed-by: kvn, ppunegov, simonis, neliasso Contributed-by: nils.eliasson at oracle.com, volker.simonis at gmail.com ! test/lib/sun/hotspot/WhiteBox.java Changeset: fa307bc0ed5a Author: zmajo Date: 2016-03-14 17:51 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/fa307bc0ed5a Merge Changeset: 55b962a5631b Author: amurillo Date: 2016-03-17 11:25 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/55b962a5631b Merge Changeset: 15d061ef8591 Author: amurillo Date: 2016-03-21 20:19 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/15d061ef8591 Merge Changeset: 905405fcc3b4 Author: erikj Date: 2016-03-22 10:46 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/905405fcc3b4 8149545: Add zlib devel package to devkit sysroot on Linux Reviewed-by: alanb ! make/devkit/Tools.gmk Changeset: 00ff6af007c0 Author: chegar Date: 2016-03-22 10:44 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/00ff6af007c0 Merge ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 ! common/conf/jib-profiles.js - make/CheckModules.gmk - make/GenerateModuleDeps.gmk ! make/common/NativeCompilation.gmk - modules.xml Changeset: f7b181bd0dc2 Author: chegar Date: 2016-03-22 17:02 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/f7b181bd0dc2 Merge ! test/lib/sun/hotspot/WhiteBox.java Changeset: e850a15d3ac6 Author: mchung Date: 2016-03-23 09:20 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/e850a15d3ac6 8152197: Single place to specify module-specific information for images build Reviewed-by: alanb, erikj ! make/Images.gmk ! make/common/Modules.gmk Changeset: 6da9e0c79eac Author: lana Date: 2016-03-23 21:44 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/6da9e0c79eac Merge Changeset: b23dfa43c0c3 Author: mchung Date: 2016-03-24 13:45 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/b23dfa43c0c3 8152697: JVMCI tests fail with UnsatisfiedLinkError as jdk.vm.ci not defined by boot loader Reviewed-by: alanb ! make/common/Modules.gmk Changeset: 03543a758cd5 Author: sherman Date: 2016-03-25 10:55 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/03543a758cd5 8031767: Support system or alternative implementations of zlib Reviewed-by: alanb, erikj ! common/autoconf/generated-configure.sh ! common/autoconf/lib-bundled.m4 ! common/conf/jib-profiles.js Changeset: 6c5a63c5e7a4 Author: lana Date: 2016-03-31 01:13 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/6c5a63c5e7a4 Added tag jdk-9+112 for changeset 03543a758cd5 ! .hgtags Changeset: 6921d7a584ae Author: alanb Date: 2016-03-31 13:55 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/6921d7a584ae Merge ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 ! common/conf/jib-profiles.js ! make/Images.gmk ! make/common/Modules.gmk ! make/common/NativeCompilation.gmk ! make/jprt.properties ! test/lib/sun/hotspot/WhiteBox.java From alan.bateman at oracle.com Thu Mar 31 14:16:18 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 31 Mar 2016 14:16:18 +0000 Subject: hg: jigsaw/jake/corba: 2 new changesets Message-ID: <201603311416.u2VEGI8a003776@aojmv0008.oracle.com> Changeset: cc30faa2da49 Author: lana Date: 2016-03-31 01:13 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/cc30faa2da49 Added tag jdk-9+112 for changeset 780d0620add3 ! .hgtags Changeset: de3dfa940914 Author: alanb Date: 2016-03-31 13:44 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/de3dfa940914 Merge From alan.bateman at oracle.com Thu Mar 31 14:16:19 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 31 Mar 2016 14:16:19 +0000 Subject: hg: jigsaw/jake/jaxp: 3 new changesets Message-ID: <201603311416.u2VEGJwM003838@aojmv0008.oracle.com> Changeset: 36326537f929 Author: joehw Date: 2016-03-24 15:34 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/36326537f929 8151154: IllegalArgumentException not thrown when wrong syntax value is set for javax.xml.catalog.files Reviewed-by: lancea ! src/java.xml/share/classes/javax/xml/catalog/BaseEntry.java ! src/java.xml/share/classes/javax/xml/catalog/CatalogFeatures.java ! src/java.xml/share/classes/javax/xml/catalog/CatalogImpl.java ! src/java.xml/share/classes/javax/xml/catalog/Util.java ! test/javax/xml/jaxp/unittest/catalog/CatalogTest.java Changeset: 29f414d284e5 Author: lana Date: 2016-03-31 01:13 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/29f414d284e5 Added tag jdk-9+112 for changeset 36326537f929 ! .hgtags Changeset: a7ada8afc4ba Author: alanb Date: 2016-03-31 13:43 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/a7ada8afc4ba Merge From alan.bateman at oracle.com Thu Mar 31 14:16:20 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 31 Mar 2016 14:16:20 +0000 Subject: hg: jigsaw/jake/jaxws: 2 new changesets Message-ID: <201603311416.u2VEGKf9003883@aojmv0008.oracle.com> Changeset: e980062475c1 Author: lana Date: 2016-03-31 01:13 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/e980062475c1 Added tag jdk-9+112 for changeset 21274e7937ba ! .hgtags Changeset: 2e61d618c68c Author: alanb Date: 2016-03-31 13:43 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/2e61d618c68c Merge From alan.bateman at oracle.com Thu Mar 31 14:16:24 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 31 Mar 2016 14:16:24 +0000 Subject: hg: jigsaw/jake/langtools: 16 new changesets Message-ID: <201603311416.u2VEGO8h004017@aojmv0008.oracle.com> Changeset: 4e6a73cb55da Author: ksrini Date: 2016-03-14 15:04 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/4e6a73cb55da 8071982: Update tests for revamped Doclet API 8071984: Update test cases for repeating and type annotations output in javadoc Reviewed-by: ksrini, bpatel Contributed-by: oleg.barbashov at oracle.com ! test/jdk/javadoc/doclet/testAnnotationTypes/TestAnnotationTypes.java ! test/jdk/javadoc/doclet/testClassCrossReferences/C.java ! test/jdk/javadoc/doclet/testClassCrossReferences/TestClassCrossReferences.java ! test/jdk/javadoc/doclet/testClassCrossReferences/package-list + test/jdk/javadoc/doclet/testClassDocCatalog/TestClassDocCatalog.java + test/jdk/javadoc/doclet/testClassDocCatalog/pkg1/EmptyAnnotation.java + test/jdk/javadoc/doclet/testClassDocCatalog/pkg1/EmptyClass.java + test/jdk/javadoc/doclet/testClassDocCatalog/pkg1/EmptyEnum.java + test/jdk/javadoc/doclet/testClassDocCatalog/pkg1/EmptyError.java + test/jdk/javadoc/doclet/testClassDocCatalog/pkg1/EmptyException.java + test/jdk/javadoc/doclet/testClassDocCatalog/pkg1/EmptyInterface.java + test/jdk/javadoc/doclet/testClassDocCatalog/pkg2/EmptyAnnotation.java + test/jdk/javadoc/doclet/testClassDocCatalog/pkg2/EmptyClass.java + test/jdk/javadoc/doclet/testClassDocCatalog/pkg2/EmptyEnum.java + test/jdk/javadoc/doclet/testClassDocCatalog/pkg2/EmptyError.java + test/jdk/javadoc/doclet/testClassDocCatalog/pkg2/EmptyException.java + test/jdk/javadoc/doclet/testClassDocCatalog/pkg2/EmptyInterface.java ! test/jdk/javadoc/doclet/testDeprecatedDocs/TestDeprecatedDocs.java ! test/jdk/javadoc/doclet/testDeprecatedDocs/pkg/TestAnnotationType.java + test/jdk/javadoc/doclet/testGroupOption/C.java ! test/jdk/javadoc/doclet/testGroupOption/TestGroupOption.java + test/jdk/javadoc/doclet/testGroupOption/abc1/C.java + test/jdk/javadoc/doclet/testGroupOption/abc2/C.java + test/jdk/javadoc/doclet/testGroupOption/abc3/C.java + test/jdk/javadoc/doclet/testGroupOption/other/C.java ! test/jdk/javadoc/doclet/testHelpOption/TestHelpOption.java ! test/jdk/javadoc/doclet/testIndex/TestIndex.java ! test/jdk/javadoc/doclet/testIndex/pkg/Coin.java ! test/jdk/javadoc/doclet/testLinkTaglet/TestLinkTaglet.java ! test/jdk/javadoc/doclet/testLinkTaglet/checkPkg/B.java ! test/jdk/javadoc/doclet/testLinkTaglet/pkg/C.java ! test/jdk/javadoc/doclet/testNavigation/TestNavigation.java + test/jdk/javadoc/doclet/testNavigation/overview.html ! test/jdk/javadoc/doclet/testOptions/TestOptions.java + test/jdk/javadoc/doclet/testOptions/custom-stylesheet.css + test/jdk/javadoc/doclet/testOptions/deprecated/Foo.java + test/jdk/javadoc/doclet/testOptions/help.html + test/jdk/javadoc/doclet/testOptions/linksource/AnnotationTypeField.java + test/jdk/javadoc/doclet/testOptions/linksource/Properties.java + test/jdk/javadoc/doclet/testOptions/linksource/SomeClass.java + test/jdk/javadoc/doclet/testOptions/linksource/SomeEnum.java ! test/jdk/javadoc/doclet/testSearch/TestSearch.java ! test/jdk/javadoc/doclet/testSearch/pkg/AnotherClass.java ! test/jdk/javadoc/doclet/testSearch/pkg/package-info.java ! test/jdk/javadoc/doclet/testSearch/pkgfx/C.java + test/jdk/javadoc/doclet/testSerializedForm/ExternalizedForm.java + test/jdk/javadoc/doclet/testSerializedForm/SerializedForm.java ! test/jdk/javadoc/doclet/testSerializedForm/TestSerializedForm.java ! test/jdk/javadoc/doclet/testSimpleTag/C.java ! test/jdk/javadoc/doclet/testSimpleTag/TestSimpleTag.java ! test/jdk/javadoc/doclet/testTypeAnnotations/TestTypeAnnotations.java + test/jdk/javadoc/doclet/testTypeAnnotations/typeannos/RepeatedAnnotations.java ! test/jdk/javadoc/doclet/testUseOption/TestUseOption.java ! test/jdk/javadoc/doclet/testUseOption/pkg1/C1.java ! test/jdk/javadoc/doclet/testUseOption/pkg1/C9.java + test/jdk/javadoc/doclet/testUseOption/pkg1/SubInterface.java + test/jdk/javadoc/doclet/testUseOption/pkg1/UsedThrowable.java + test/jdk/javadoc/doclet/testUseOption/pkg3/C.java ! test/jdk/javadoc/tool/VerifyLocale.java Changeset: 9f2ab5bb1942 Author: lana Date: 2016-03-15 14:50 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/9f2ab5bb1942 Merge Changeset: 5bacae82131e Author: jjg Date: 2016-03-17 12:40 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/5bacae82131e 8152048: change langtools tests to use ProblemList instead of @ignore Reviewed-by: darcy ! test/ProblemList.txt Changeset: facb06a2e3d8 Author: alundblad Date: 2016-03-22 11:48 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/facb06a2e3d8 8151379: Sjavac should not print connection attempts on info logging level Summary: Changed logging level on some sjavac messages. Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/JavacState.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/client/SjavacClient.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/SjavacServer.java Changeset: d52219fa3026 Author: chegar Date: 2016-03-22 10:43 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/d52219fa3026 Merge - src/jdk.compiler/share/classes/com/sun/tools/javac/sym/CreateSymbols.java - src/jdk.compiler/share/classes/com/sun/tools/javac/sym/Profiles.java - src/jdk.compiler/share/classes/com/sun/tools/javac/util/ServiceLoader.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/AbstractProfileIndexWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfileIndexFrameWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageFrameWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageIndexFrameWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageWriterImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfileWriterImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/ProfilePackageSummaryWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/ProfileSummaryWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ProfilePackageSummaryBuilder.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ProfileSummaryBuilder.java - src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModulesXmlReader.java - src/jdk.jdeps/share/classes/com/sun/tools/jdeps/PlatformClassPath.java ! test/ProblemList.txt - test/com/sun/javadoc/testLinkOption/java/lang/StringBuilderChild.java - test/com/sun/javadoc/testLinkOption/package-list - test/com/sun/javadoc/testProfiles/TestProfiles.java - test/com/sun/javadoc/testProfiles/TestProfilesConfiguration.java - test/com/sun/javadoc/testProfiles/pkg1/Class1Pkg1.java - test/com/sun/javadoc/testProfiles/pkg1/Class2Pkg1.java - test/com/sun/javadoc/testProfiles/pkg1/Class3Pkg1.java - test/com/sun/javadoc/testProfiles/pkg1/Interface1Pkg1.java - test/com/sun/javadoc/testProfiles/pkg2/Anno1Pkg2.java - test/com/sun/javadoc/testProfiles/pkg2/Anno2Pkg2.java - test/com/sun/javadoc/testProfiles/pkg2/Class1Pkg2.java - test/com/sun/javadoc/testProfiles/pkg2/ClassError.java - test/com/sun/javadoc/testProfiles/pkg2/ClassException.java - test/com/sun/javadoc/testProfiles/pkg3/Class1Pkg3.java - test/com/sun/javadoc/testProfiles/pkg3/Class2Pkg3.java - test/com/sun/javadoc/testProfiles/pkg3/Interface1Pkg3.java - test/com/sun/javadoc/testProfiles/pkg4/Anno1Pkg4.java - test/com/sun/javadoc/testProfiles/pkg4/Class1Pkg4.java - test/com/sun/javadoc/testProfiles/pkg5/Class1Pkg5.java - test/com/sun/javadoc/testProfiles/pkg5/Interface1Pkg5.java - test/com/sun/javadoc/testProfiles/pkgDeprecated/Class1PkgDeprecated.java - test/com/sun/javadoc/testProfiles/pkgDeprecated/package-info.java - test/com/sun/javadoc/testProfiles/profile-rtjar-includes-nopkgs.txt - test/com/sun/javadoc/testProfiles/profile-rtjar-includes.txt ! test/jdk/javadoc/doclet/testAnnotationTypes/TestAnnotationTypes.java ! test/jdk/javadoc/doclet/testClassCrossReferences/TestClassCrossReferences.java ! test/jdk/javadoc/doclet/testClassDocCatalog/TestClassDocCatalog.java ! test/jdk/javadoc/doclet/testDeprecatedDocs/TestDeprecatedDocs.java ! test/jdk/javadoc/doclet/testGroupOption/TestGroupOption.java ! test/jdk/javadoc/doclet/testHelpOption/TestHelpOption.java ! test/jdk/javadoc/doclet/testIndex/TestIndex.java - test/jdk/javadoc/doclet/testLinkOption/java/lang/StringBuilderChild.java - test/jdk/javadoc/doclet/testLinkOption/package-list ! test/jdk/javadoc/doclet/testLinkTaglet/TestLinkTaglet.java ! test/jdk/javadoc/doclet/testNavigation/TestNavigation.java ! test/jdk/javadoc/doclet/testOptions/TestOptions.java ! test/jdk/javadoc/doclet/testSearch/TestSearch.java ! test/jdk/javadoc/doclet/testSerializedForm/TestSerializedForm.java ! test/jdk/javadoc/doclet/testSimpleTag/TestSimpleTag.java ! test/jdk/javadoc/doclet/testTypeAnnotations/TestTypeAnnotations.java ! test/jdk/javadoc/doclet/testUseOption/TestUseOption.java ! test/jdk/javadoc/tool/VerifyLocale.java - test/tools/javac/Object1.java - test/tools/javac/Object1.out - test/tools/javac/Object2.java - test/tools/javac/Object2.out - test/tools/javac/profiles/ProfileTest.java - test/tools/javac/proprietary/WarnClass.java - test/tools/javac/proprietary/WarnClass.out - test/tools/javac/proprietary/WarnImport.java - test/tools/javac/proprietary/WarnImport.out - test/tools/javac/proprietary/WarnMethod.java - test/tools/javac/proprietary/WarnMethod.out - test/tools/javac/proprietary/WarnStaticImport.java - test/tools/javac/proprietary/WarnStaticImport.out - test/tools/javac/proprietary/WarnVariable.java - test/tools/javac/proprietary/WarnVariable.out - test/tools/javac/proprietary/WarnWildcard.java - test/tools/javac/proprietary/WarnWildcard.out - test/tools/javac/synthesize/Boolean.java - test/tools/javac/synthesize/Byte.java - test/tools/javac/synthesize/Character.java - test/tools/javac/synthesize/Cloneable.java - test/tools/javac/synthesize/Double.java - test/tools/javac/synthesize/Float.java - test/tools/javac/synthesize/Integer.java - test/tools/javac/synthesize/Long.java - test/tools/javac/synthesize/Number.java - test/tools/javac/synthesize/Object.java - test/tools/javac/synthesize/Serializable.java - test/tools/javac/synthesize/Short.java - test/tools/javac/synthesize/Test.java - test/tools/javac/synthesize/Void.java - test/tools/jdeps/VerboseFormat/use/indirect/DontUseUnsafe2.java - test/tools/jdeps/VerboseFormat/use/indirect/UseUnsafeIndirectly.java - test/tools/jdeps/VerboseFormat/use/indirect2/DontUseUnsafe3.java - test/tools/jdeps/VerboseFormat/use/indirect2/UseUnsafeIndirectly2.java - test/tools/jdeps/VerboseFormat/use/unsafe/DontUseUnsafe.java - test/tools/jdeps/VerboseFormat/use/unsafe/UseClassWithUnsafe.java - test/tools/jdeps/VerboseFormat/use/unsafe/UseUnsafeClass.java - test/tools/jdeps/VerboseFormat/use/unsafe/UseUnsafeClass2.java - test/tools/jdeps/javax/activity/NotCompactProfile.java Changeset: bb24cb2c98fe Author: chegar Date: 2016-03-22 15:26 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/bb24cb2c98fe Merge Changeset: 241e893e89e0 Author: mchung Date: 2016-03-22 19:34 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/241e893e89e0 8152504: Problem list tools/jdeps/modules/GenModuleInfo.java until JDK-8152502 is resolved Reviewed-by: darcy ! test/ProblemList.txt Changeset: 7b2109432f9f Author: mchung Date: 2016-03-22 19:34 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/7b2109432f9f 8152503: tools/javac/completionDeps/DepsAndAnno.java fails after jigsaw m3 Reviewed-by: darcy ! test/tools/javac/completionDeps/DepsAndAnno.java Changeset: b40b4ce0daab Author: alundblad Date: 2016-03-23 13:39 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/b40b4ce0daab 8027999: Poorly worded error message when attempting to assign to this Summary: Changed the error message when trying to assign to this. Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/CantAssignToThis.java Changeset: c42875d558d4 Author: alundblad Date: 2016-03-23 13:44 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/c42875d558d4 8152465: Sjavac should not prefix server generated log messages with [server] Summary: Dropped the [server] prefix unless debug output is enabled. Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/client/SjavacClient.java Changeset: d77a6b663858 Author: jlahoda Date: 2016-03-23 13:40 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/d77a6b663858 8152296: langtools/test/jdk/jshell/ToolReloadTest.java failing if there is not persisted history Summary: Create a custom Terminal for use in tests; avoid use of global Preferences in tests. Reviewed-by: rfield ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java ! test/jdk/jshell/ReplToolTesting.java ! test/jdk/jshell/StartOptionTest.java Changeset: a6b25b9c0195 Author: mcimadamore Date: 2016-03-23 16:59 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/a6b25b9c0195 8152411: Regression: inference fails to reject incompatible upper bounds Summary: Wrong undet variable comparison in propagation optimization Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/InferenceContext.java + test/tools/javac/generics/inference/8152411/T8152411.java + test/tools/javac/generics/inference/8152411/T8152411.out Changeset: b5af83c995f9 Author: lana Date: 2016-03-23 21:44 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/b5af83c995f9 Merge Changeset: 3d4117c36559 Author: rfield Date: 2016-03-25 18:36 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/3d4117c36559 8151755: jshell tool: properly cover resolution issues in output configuration 8152246: jshell tool: history overflow Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/Feedback.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java + src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties ! test/jdk/jshell/ReplToolTesting.java ! test/jdk/jshell/ToolBasicTest.java ! test/jdk/jshell/ToolFormatTest.java ! test/jdk/jshell/ToolReloadTest.java Changeset: e25cb1b340e1 Author: lana Date: 2016-03-31 01:13 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/e25cb1b340e1 Added tag jdk-9+112 for changeset 3d4117c36559 ! .hgtags Changeset: 4229f59d6d89 Author: alanb Date: 2016-03-31 13:54 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/4229f59d6d89 Merge ! .hgtags ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/ProblemList.txt ! test/jdk/javadoc/doclet/testAnnotationTypes/TestAnnotationTypes.java ! test/jdk/javadoc/doclet/testNavigation/TestNavigation.java ! test/jdk/javadoc/doclet/testTypeAnnotations/TestTypeAnnotations.java ! test/jdk/jshell/ToolFormatTest.java From alan.bateman at oracle.com Thu Mar 31 14:16:25 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 31 Mar 2016 14:16:25 +0000 Subject: hg: jigsaw/jake/nashorn: 14 new changesets Message-ID: <201603311416.u2VEGPKr004024@aojmv0008.oracle.com> Changeset: 15d52fdd9168 Author: attila Date: 2016-03-15 16:02 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/15d52fdd9168 8150218: Autoconversion SAM adapters sometimes don't get privileges Reviewed-by: mhaupt, sundar ! src/jdk.dynalink/share/classes/jdk/dynalink/CallSiteDescriptor.java ! src/jdk.dynalink/share/classes/jdk/dynalink/LinkerServicesImpl.java + src/jdk.dynalink/share/classes/jdk/dynalink/SecureLookupSupplier.java ! src/jdk.dynalink/share/classes/jdk/dynalink/beans/CallerSensitiveDynamicMethod.java ! src/jdk.dynalink/share/classes/jdk/dynalink/beans/ClassLinker.java ! src/jdk.dynalink/share/classes/jdk/dynalink/beans/LinkerServicesWithMissingMemberHandlerFactory.java ! src/jdk.dynalink/share/classes/jdk/dynalink/beans/OverloadedDynamicMethod.java ! src/jdk.dynalink/share/classes/jdk/dynalink/beans/OverloadedMethod.java ! src/jdk.dynalink/share/classes/jdk/dynalink/beans/SingleDynamicMethod.java - src/jdk.dynalink/share/classes/jdk/dynalink/beans/messages.properties ! src/jdk.dynalink/share/classes/jdk/dynalink/linker/GuardingTypeConverterFactory.java ! src/jdk.dynalink/share/classes/jdk/dynalink/linker/LinkerServices.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/scripting/ScriptUtils.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/Global.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/JSType.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornBeansLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornLinker.java + test/script/basic/JDK-8150218.js + test/src/jdk/dynalink/test/ArrayRunnableTest.java Changeset: b9bf01ca3ef3 Author: lana Date: 2016-03-15 14:50 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/b9bf01ca3ef3 Merge - src/jdk.dynalink/share/classes/jdk/dynalink/beans/messages.properties Changeset: 5f06791d7682 Author: hannesw Date: 2016-03-21 11:50 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/5f06791d7682 8151809: ES6 Map/Set insertion with existing keys changes iteration order Reviewed-by: lagergren, mhaupt ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/LinkedMap.java + test/script/basic/es6/JDK-8151809.js Changeset: 25b13597ea73 Author: sdama Date: 2016-03-21 12:38 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/25b13597ea73 8147613: enable jjs tests on Windows Reviewed-by: lagergren, mhaupt ! make/build.xml ! test/script/nosecurity/JDK-8144221.js ! test/script/nosecurity/JDK-8151291.js + test/script/nosecurity/JDK-util.js ! test/script/nosecurity/jjs-common.js ! test/script/nosecurity/jjs-option-cp.js ! test/script/nosecurity/jjs-option-define.js ! test/script/nosecurity/jjs-option-doe.js ! test/script/nosecurity/jjs-option-fv.js ! test/script/nosecurity/jjs-option-fx.js ! test/script/nosecurity/jjs-option-lang.js ! test/script/nosecurity/jjs-option-ot.js ! test/script/nosecurity/jjs-option-scripting.js ! test/script/nosecurity/jjs-option-strict.js ! test/script/nosecurity/jjs-option-version.js Changeset: 50be58e74a21 Author: hannesw Date: 2016-03-22 14:23 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/50be58e74a21 8151810: for-in iteration does not provide per-iteration scope Reviewed-by: attila, lagergren ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/FieldObjectCreator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/Lower.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/Block.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/ForNode.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Parser.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/SetMethodCreator.java + test/script/basic/es6/JDK-8151810.js Changeset: 1421c56b3947 Author: hannesw Date: 2016-03-22 14:26 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/1421c56b3947 8151811: Const declarations do not work in for..in loops Reviewed-by: attila, lagergren ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Parser.java + test/script/basic/es6/JDK-8151811.js Changeset: 703729e9c5dd Author: chegar Date: 2016-03-22 10:43 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/703729e9c5dd Merge ! src/jdk.dynalink/share/classes/jdk/dynalink/beans/CallerSensitiveDynamicMethod.java - src/jdk.scripting.nashorn/share/classes/META-INF/MANIFEST.MF - src/jdk.scripting.nashorn/share/classes/META-INF/services/javax.script.ScriptEngineFactory Changeset: e2e19327d66a Author: chegar Date: 2016-03-22 10:52 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/e2e19327d66a Merge ! make/build.xml Changeset: 975eff39b182 Author: chegar Date: 2016-03-22 15:26 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/975eff39b182 Merge Changeset: cdacfe806770 Author: lana Date: 2016-03-23 21:45 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/cdacfe806770 Merge - src/jdk.dynalink/share/classes/jdk/dynalink/beans/messages.properties Changeset: 3ac5d360070e Author: hannesw Date: 2016-03-24 11:43 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/3ac5d360070e 8151700: Add support for ES6 for-of Reviewed-by: attila, sundar ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/AssignSymbols.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/LocalVariableTypesCalculator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/Lower.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/OptimisticTypesCalculator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/ForNode.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/AbstractIterator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Parser.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/Messages.properties ! test/script/basic/es6.js + test/script/basic/es6/for-of.js Changeset: c261f8440c55 Author: sundar Date: 2016-03-24 17:36 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/c261f8440c55 8152646: disable ant octane target to avoid hudson build failure notifications Reviewed-by: jlaskey ! make/build-benchmark.xml Changeset: f54433fcebb1 Author: lana Date: 2016-03-31 01:13 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/f54433fcebb1 Added tag jdk-9+112 for changeset c261f8440c55 ! .hgtags Changeset: cefe63e9601d Author: alanb Date: 2016-03-31 13:44 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/cefe63e9601d Merge ! .hgtags ! make/build.xml ! src/jdk.dynalink/share/classes/jdk/dynalink/beans/CallerSensitiveDynamicMethod.java - src/jdk.dynalink/share/classes/jdk/dynalink/beans/messages.properties From alan.bateman at oracle.com Thu Mar 31 14:16:36 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 31 Mar 2016 14:16:36 +0000 Subject: hg: jigsaw/jake/hotspot: 73 new changesets Message-ID: <201603311416.u2VEGbB3004080@aojmv0008.oracle.com> Changeset: 4d4f3f5b215a Author: erikj Date: 2016-03-14 12:03 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4d4f3f5b215a 8151619: genSocketOptionRegistry.exe always relinked on Windows Reviewed-by: tbell ! make/lib/Lib-jdk.hotspot.agent.gmk Changeset: 2eca85c32025 Author: ppunegov Date: 2016-03-01 20:17 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2eca85c32025 8148563: compiler/compilercontrol/jcmd/StressAddMultiThreadedTest.java timesout Summary: decrease amount of directives and threads Reviewed-by: neliasso ! test/compiler/compilercontrol/jcmd/StressAddJcmdBase.java ! test/compiler/compilercontrol/jcmd/StressAddMultiThreadedTest.java - test/compiler/compilercontrol/jcmd/StressAddSequentiallyTest.java Changeset: f9a45b25d9c9 Author: ppunegov Date: 2016-03-03 16:54 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f9a45b25d9c9 Merge Changeset: 6ff38c89f1f2 Author: mikael Date: 2016-03-03 09:33 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6ff38c89f1f2 8149159: Clean up Unsafe Reviewed-by: jrose, kvn, stsmirno, chegar, aph, psandoz, redestad, twisti ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/prims/unsafe.cpp + src/share/vm/prims/unsafe.hpp ! src/share/vm/runtime/interfaceSupport.hpp ! src/share/vm/shark/sharkBuilder.cpp ! test/compiler/intrinsics/IntrinsicDisabledTest.java Changeset: d15b795cdf21 Author: shade Date: 2016-03-03 22:17 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d15b795cdf21 8150669: C1 intrinsic for Class.isPrimitive Reviewed-by: twisti, vlivanov, redestad ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_Compiler.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp + test/compiler/intrinsics/class/TestClassIsPrimitive.java Changeset: 6c9cc4c0b514 Author: shade Date: 2016-03-03 23:57 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6c9cc4c0b514 8150465: Unsafe methods to produce uninitialized arrays Reviewed-by: jrose, kvn, psandoz, aph, twisti, flar ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/library_call.cpp + test/compiler/intrinsics/unsafe/AllocateUninitializedArray.java Changeset: a66bdd827fcb Author: shade Date: 2016-03-04 01:30 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a66bdd827fcb 8146801: Allocating short arrays of non-constant size is slow Reviewed-by: kvn, twisti, vlivanov ! src/cpu/aarch64/vm/aarch64.ad ! src/cpu/aarch64/vm/globals_aarch64.hpp ! src/cpu/ppc/vm/globals_ppc.hpp ! src/cpu/ppc/vm/ppc.ad ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/runtime/commandLineFlagConstraintsCompiler.cpp ! src/share/vm/runtime/commandLineFlagConstraintsCompiler.hpp ! src/share/vm/runtime/globals.hpp Changeset: 59829cb7ae2e Author: vdeshpande Date: 2016-03-03 22:02 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/59829cb7ae2e 8150767: Enables SHA Extensions on x86 Summary: Add x86 intrinsics for SHA-1 and SHA-256. Reviewed-by: kvn, twisti Contributed-by: vivek.r.deshpande at intel.com, shravya.rukmannagari at intel.com ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.hpp + src/cpu/x86/vm/macroAssembler_x86_sha.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86.cpp ! src/cpu/x86/vm/stubRoutines_x86.hpp ! src/cpu/x86/vm/vmStructs_x86.hpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/jdk.vm.ci/share/classes/jdk.vm.ci.amd64/src/jdk/vm/ci/amd64/AMD64.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot.amd64/src/jdk/vm/ci/hotspot/amd64/AMD64HotSpotJVMCIBackendFactory.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java ! src/share/vm/jvmci/vmStructs_jvmci.cpp ! src/share/vm/runtime/globals.hpp Changeset: 0adf6c8c7223 Author: zmajo Date: 2016-03-04 08:53 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0adf6c8c7223 8150839: Adjust the number of compiler threads for 32-bit platforms Summary: Set the number of compiler threads to 3 on 32-bit platforms. Reviewed-by: iveresov ! src/share/vm/runtime/advancedThresholdPolicy.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/simpleThresholdPolicy.cpp Changeset: 4838927d2c74 Author: rraghavan Date: 2016-03-04 01:18 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4838927d2c74 8140721: ProfilerNumberOf*Methods flags should be diagnostic. Summary: Converted four ProfilerNumberOf*Methods flags from develop to diagnostic. Reviewed-by: twisti ! src/share/vm/runtime/globals.hpp Changeset: 323d6d9aeb1e Author: thartmann Date: 2016-03-04 13:16 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/323d6d9aeb1e Merge ! src/share/vm/runtime/globals.hpp - test/compiler/compilercontrol/jcmd/StressAddSequentiallyTest.java Changeset: bff625f165fa Author: zmajo Date: 2016-03-07 09:34 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/bff625f165fa Merge - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/development/Server16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/development/Server24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/About16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/About24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Delete16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Delete24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Find16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Help16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Help24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/History16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/History24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Information16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Information24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/New16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/New24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Open16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Open24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Save24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/SaveAs16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/SaveAs24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/Zoom16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/ZoomIn16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/general/ZoomIn24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/navigation/Down16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/navigation/Up16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/text/AlignCenter16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/text/AlignCenter24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/text/AlignLeft16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/text/AlignLeft24.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/text/AlignRight16.gif - src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics/text/AlignRight24.gif ! src/share/vm/c1/c1_Compiler.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp - test/serviceability/dcmd/jvmti/LoadJavaAgentDcmdTest.java Changeset: 687c4d83a4cc Author: kvn Date: 2016-03-07 10:03 -0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/687c4d83a4cc 8150353: PPC64LE: Support RTM on linux Reviewed-by: mdoerr, kvn Contributed-by: gromero at linux.vnet.ibm.com ! src/cpu/ppc/vm/globalDefinitions_ppc.hpp ! src/cpu/ppc/vm/vm_version_ppc.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp ! src/share/vm/opto/compile.hpp Changeset: 0edd74a48586 Author: mikael Date: 2016-03-07 15:03 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0edd74a48586 8151002: Make Assembler methods vextract and vinsert match actual instructions Reviewed-by: kvn, vlivanov, mcberg ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/x86.ad Changeset: 87e72c51ec69 Author: enevill Date: 2016-03-08 14:39 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/87e72c51ec69 8150394: aarch64: add support for 8.1 LSE CAS instructions Reviewed-by: aph Contributed-by: ananth.jasty at caviumnetworks.com, edward.nevill at linaro.org ! src/cpu/aarch64/vm/aarch64.ad ! src/cpu/aarch64/vm/assembler_aarch64.hpp ! src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp ! src/cpu/aarch64/vm/globals_aarch64.hpp ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/aarch64/vm/macroAssembler_aarch64.hpp ! src/cpu/aarch64/vm/register_aarch64.hpp ! src/cpu/aarch64/vm/vm_version_aarch64.cpp Changeset: 9e7c906e3208 Author: enevill Date: 2016-02-20 15:11 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9e7c906e3208 8150082: aarch64: optimise small array copy Reviewed-by: aph ! src/cpu/aarch64/vm/stubGenerator_aarch64.cpp Changeset: dae92a905ef8 Author: enevill Date: 2016-02-20 15:15 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/dae92a905ef8 8150313: aarch64: optimise array copy using SIMD instructions Reviewed-by: aph ! src/cpu/aarch64/vm/globals_aarch64.hpp ! src/cpu/aarch64/vm/stubGenerator_aarch64.cpp Changeset: 9e9281592247 Author: fyang Date: 2016-03-05 22:22 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9e9281592247 8151340: aarch64: prefetch the destination word for write prior to ldxr/stxr loops. Summary: aarch64: add prefetch for write prior to ldxr/stxr loops. Reviewed-by: aph Contributed-by: felix.yang at linaro.org ! src/cpu/aarch64/vm/aarch64.ad ! src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/aarch64/vm/templateInterpreterGenerator_aarch64.cpp Changeset: 3a1f495e37b3 Author: twisti Date: 2016-03-08 15:10 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3a1f495e37b3 8151266: HotSpotResolvedJavaFieldImpl::isStable() does not work as expected Reviewed-by: never, twisti ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMetaAccessProvider.java Changeset: 07536fb80fad Author: amurillo Date: 2016-03-10 16:08 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/07536fb80fad Merge - test/compiler/compilercontrol/jcmd/StressAddSequentiallyTest.java Changeset: 96638b8bfdfa Author: amurillo Date: 2016-03-14 14:28 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/96638b8bfdfa Merge - test/compiler/compilercontrol/jcmd/StressAddSequentiallyTest.java Changeset: d890ed97a19c Author: lana Date: 2016-03-15 14:48 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d890ed97a19c Merge - test/compiler/compilercontrol/jcmd/StressAddSequentiallyTest.java Changeset: 3a8da1230500 Author: goetz Date: 2016-03-06 15:50 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3a8da1230500 8149557: Resource mark breaks printing to string stream Reviewed-by: stuefe, dholmes ! src/share/vm/oops/symbol.cpp ! src/share/vm/utilities/ostream.cpp Changeset: 57175b61dac3 Author: stuefe Date: 2016-03-06 19:07 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/57175b61dac3 8150843: [windows] os::getTimesSecs() returns negative values for kernel, user times Reviewed-by: dholmes ! src/os/windows/vm/os_windows.cpp Changeset: f96580a236c0 Author: ddmitriev Date: 2016-03-07 10:36 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f96580a236c0 8149973: Optimize object alignment check in debug builds. Reviewed-by: coleenp, tschatzl ! src/share/vm/gc/g1/g1OopClosures.inline.hpp ! src/share/vm/gc/g1/g1RemSet.inline.hpp ! src/share/vm/oops/oop.inline.hpp Changeset: 1bff1b586886 Author: rehn Date: 2016-02-26 10:51 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1bff1b586886 8150026: Add the ability to log with variable log level Reviewed-by: brutisso, mlarsson ! src/share/vm/logging/log.hpp Changeset: 143691dafa25 Author: sangheki Date: 2016-03-07 01:20 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/143691dafa25 8145204: JVM can hang when ParGCArrayScanChunk=4294967296 and ParallelGC is used Summary: Changed the max value of ParGCArrayScanChunk to max_jint/3 Reviewed-by: jwilhelm, drwhite ! src/share/vm/runtime/commandLineFlagRangeList.cpp ! src/share/vm/runtime/globals.hpp ! test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java Changeset: 001616491946 Author: sangheki Date: 2016-03-07 10:01 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/001616491946 Merge Changeset: a6ba2cec1af1 Author: drwhite Date: 2016-03-01 12:10 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a6ba2cec1af1 8078673: Update TEST.groups for recent GC tests Summary: Updates the needs_g1gc list in TEST.groups and adds appropriate "@requires vm.gc" annotations to a few GC tests. Reviewed-by: tschatzl, dfazunen ! test/TEST.groups ! test/gc/TestCardTablePageCommits.java ! test/gc/arguments/TestCMSHeapSizeFlags.java ! test/gc/arguments/TestG1ConcRefinementThreads.java ! test/gc/arguments/TestG1HeapSizeFlags.java ! test/gc/arguments/TestG1PercentageOptions.java ! test/gc/arguments/TestParallelHeapSizeFlags.java ! test/gc/logging/TestGCId.java Changeset: d367f98eeadc Author: tschatzl Date: 2016-03-07 10:56 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d367f98eeadc 8142484: Let IHOP follow the current capacity, not the maximum capacity Summary: Instead of following the current heap capacity, let all IHOP calculations follow the maximum capacity. Reviewed-by: brutisso, jmasa ! src/share/vm/gc/g1/g1CollectorPolicy.cpp ! src/share/vm/gc/g1/g1IHOPControl.cpp ! src/share/vm/gc/g1/g1IHOPControl.hpp Changeset: bfaeb7b78742 Author: tschatzl Date: 2016-03-07 12:49 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/bfaeb7b78742 Merge Changeset: 7a1bb5c3ff95 Author: sjohanss Date: 2016-03-07 15:07 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7a1bb5c3ff95 8149642: gc/g1/TestShrinkAuxiliaryData* tests fail with "GC triggered before VM initialization completed" Reviewed-by: brutisso, dfazunen ! test/gc/g1/TestShrinkAuxiliaryData00.java ! test/gc/g1/TestShrinkAuxiliaryData05.java ! test/gc/g1/TestShrinkAuxiliaryData10.java ! test/gc/g1/TestShrinkAuxiliaryData15.java ! test/gc/g1/TestShrinkAuxiliaryData20.java ! test/gc/g1/TestShrinkAuxiliaryData25.java ! test/gc/g1/TestShrinkAuxiliaryData30.java Changeset: 3f5a29b58493 Author: jmasa Date: 2016-03-03 11:36 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3f5a29b58493 8151101: Improve UseParallelGC parallelization of object array processing Reviewed-by: tschatzl, shade Contributed-by: richard.reingruber at sap.com ! src/share/vm/gc/parallel/psCompactionManager.inline.hpp Changeset: 91b99f0a2ec8 Author: jwilhelm Date: 2016-02-29 15:47 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/91b99f0a2ec8 6787054: Par compact - remove code that clears source_region Reviewed-by: mgerdin, tschatzl ! src/share/vm/gc/parallel/psParallelCompact.cpp ! src/share/vm/gc/parallel/psParallelCompact.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 8feda14c460c Author: jwilhelm Date: 2016-03-07 19:17 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/8feda14c460c Merge Changeset: 741520968fec Author: gziemski Date: 2016-03-07 10:39 -0600 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/741520968fec 8146850: Remove TraceHandleAllocation rather than converting to UL 8149850: Remove HandleAllocationLimit and TotalHandleAllocationLimit when removing TraceHandleAllocation Summary: Removed TraceHandleAllocation, HandleAllocationLimit and TotalHandleAllocationLimit flags Reviewed-by: coleenp, dholmes ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/handles.cpp Changeset: faba55e07315 Author: gziemski Date: 2016-03-07 19:29 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/faba55e07315 Merge Changeset: 7fbe91178ff9 Author: dsamersoff Date: 2016-03-07 20:58 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7fbe91178ff9 8147456: Parsing of argument for -agentpath can write outside of allocated memory Reviewed-by: sspitsyn, dholmes Contributed-by: sharath.ballal at oracle.com ! src/os/posix/vm/os_posix.cpp Changeset: df3a86fcf1c5 Author: dsamersoff Date: 2016-03-07 18:05 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/df3a86fcf1c5 Merge Changeset: 53322af1a349 Author: dsamersoff Date: 2016-03-07 20:33 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/53322af1a349 Merge Changeset: b9719c517370 Author: sangheki Date: 2016-03-07 02:11 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b9719c517370 8149834: gc/shared/gcTimer.cpp:88 assert(_is_concurrent_phase_active) failed: A concurrent phase is not active Summary: Compare-and-exchange for concurrent gc timer related flag at G1CollectedHeap Reviewed-by: jmasa, drwhite ! src/share/vm/gc/g1/g1CollectedHeap.cpp ! src/share/vm/gc/g1/g1ConcurrentMark.cpp ! src/share/vm/gc/g1/g1ConcurrentMark.hpp Changeset: 6e078dfe1d5b Author: sangheki Date: 2016-03-07 18:56 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6e078dfe1d5b Merge Changeset: a140334040d2 Author: sangheki Date: 2016-03-07 21:40 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a140334040d2 Merge Changeset: c4597dc5ff71 Author: cvarming Date: 2016-03-07 14:41 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c4597dc5ff71 8150013: ParNew: Prune nmethods scavengable list. Summary: Speed up ParNew collections by pruning the list of scavengable nmethods. Reviewed-by: jmasa, tonyp, twisti ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/gc/parallel/psScavenge.cpp ! src/share/vm/gc/shared/genCollectedHeap.cpp ! src/share/vm/gc/shared/genCollectedHeap.hpp ! src/share/vm/memory/iterator.hpp Changeset: eb055098b5ab Author: jmasa Date: 2016-03-07 23:06 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/eb055098b5ab Merge Changeset: 16356f8940ac Author: jwilhelm Date: 2016-03-16 14:31 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/16356f8940ac Merge ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/runtime/globals.hpp ! test/TEST.groups Changeset: 74522870dbde Author: twisti Date: 2016-03-10 13:04 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/74522870dbde 8151470: [JVMCI] remove up-call to HotSpotJVMCICompilerConfig.selectCompiler Reviewed-by: dnsimon, vlivanov ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJVMCICompilerConfig.java ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJVMCIRuntime.java ! src/share/vm/jvmci/jvmciRuntime.cpp ! src/share/vm/jvmci/jvmciRuntime.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/thread.cpp Changeset: cdc9ef77a4da Author: enevill Date: 2016-03-10 14:53 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/cdc9ef77a4da 8151502: optimize pd_disjoint_words and pd_conjoint_words Summary: optimize copy routines using inline assembler Reviewed-by: aph ! src/cpu/aarch64/vm/stubGenerator_aarch64.cpp ! src/os_cpu/linux_aarch64/vm/copy_linux_aarch64.inline.hpp + src/os_cpu/linux_aarch64/vm/copy_linux_aarch64.s Changeset: 1b8cc1264b20 Author: dnsimon Date: 2016-03-10 14:06 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1b8cc1264b20 8151664: [JVMCI] add missing test in 8151266 integration Reviewed-by: never, twisti + test/compiler/jvmci/meta/StableFieldTest.java Changeset: 91371caabd4c Author: simonis Date: 2016-03-03 16:21 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/91371caabd4c 8150646: Add support for blocking compiles though whitebox API Reviewed-by: kvn, ppunegov, simonis, neliasso Contributed-by: nils.eliasson at oracle.com, volker.simonis at gmail.com ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/compiler/compilerDirectives.cpp ! src/share/vm/compiler/compilerDirectives.hpp ! src/share/vm/compiler/directivesParser.cpp ! src/share/vm/compiler/directivesParser.hpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/advancedThresholdPolicy.cpp ! src/share/vm/services/diagnosticCommand.cpp + test/compiler/whitebox/BlockingCompilation.java Changeset: fc4808355352 Author: neliasso Date: 2016-03-09 21:19 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/fc4808355352 8073793: serviceability/dcmd/compiler/CodelistTest.java fails with ClassNotFoundException trying to load VM anonymous class Summary: Make test less fragile using whitebox API Reviewed-by: kvn ! test/serviceability/dcmd/compiler/CodelistTest.java Changeset: ca0cd486254f Author: neliasso Date: 2016-03-09 21:20 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ca0cd486254f 8066770: EnqueueMethodForCompilationTest.java fails to compile method Summary: Make compiles blocking and always check queue Reviewed-by: kvn ! test/compiler/whitebox/ClearMethodStateTest.java ! test/compiler/whitebox/CompilerWhiteBoxTest.java ! test/compiler/whitebox/EnqueueMethodForCompilationTest.java ! test/compiler/whitebox/LockCompilationTest.java ! test/compiler/whitebox/MakeMethodNotCompilableTest.java Changeset: af3712e4a548 Author: neliasso Date: 2016-03-11 21:02 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/af3712e4a548 Merge Changeset: 9c7684975803 Author: vlivanov Date: 2016-03-14 12:35 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9c7684975803 8139247: Improper locking of MethodData::_extra_data_lock Reviewed-by: dholmes, roland, dcubed ! src/share/vm/ci/ciMethodData.cpp Changeset: 6c8277ce87d6 Author: vlivanov Date: 2016-03-14 12:35 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6c8277ce87d6 8150320: C1: Illegal bci in debug info for MH::linkTo* methods Reviewed-by: kvn, dlong ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/code/debugInfoRec.cpp Changeset: 3497071a8c93 Author: vlivanov Date: 2016-03-14 12:35 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3497071a8c93 8141420: Compiler runtime entries don't hold Klass* from being GCed Reviewed-by: kvn, coleenp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/jvmci/jvmciRuntime.cpp ! src/share/vm/opto/runtime.cpp Changeset: dc073ee24dc6 Author: vlivanov Date: 2016-03-14 12:35 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/dc073ee24dc6 8143407: C1: @Stable array support Reviewed-by: twisti ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_ValueType.hpp ! test/compiler/stable/StableConfiguration.java ! test/compiler/stable/TestStableBoolean.java ! test/compiler/stable/TestStableByte.java ! test/compiler/stable/TestStableChar.java ! test/compiler/stable/TestStableDouble.java ! test/compiler/stable/TestStableFloat.java ! test/compiler/stable/TestStableInt.java ! test/compiler/stable/TestStableLong.java ! test/compiler/stable/TestStableObject.java ! test/compiler/stable/TestStableShort.java Changeset: c479d5653ab6 Author: zmajo Date: 2016-03-14 17:51 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c479d5653ab6 Merge Changeset: da024e29b678 Author: kshefov Date: 2016-03-15 13:00 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/da024e29b678 8150850: [JVMCI] NPE when executing HotSpotConstantReflectionProvider.readStableFieldValue Reviewed-by: twisti, dnsimon ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotConstantReflectionProvider.java Changeset: bb71f0783bb7 Author: neliasso Date: 2016-03-15 11:17 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/bb71f0783bb7 8151795: compiler/compilercontrol/parser/DirectiveParserTest.java fails with "assert failed: 0 != 0" Summary: Treat zero added directives as fail Reviewed-by: twisti, kvn ! src/share/vm/compiler/directivesParser.cpp Changeset: 4bdeac967dce Author: neliasso Date: 2016-03-15 11:17 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4bdeac967dce 8151796: compiler/whitebox/BlockingCompilation.java fails due to method not compiled Summary: Make test more robust Reviewed-by: simonis ! test/compiler/whitebox/BlockingCompilation.java Changeset: bea0cfad5afa Author: neliasso Date: 2016-03-15 12:34 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/bea0cfad5afa Merge Changeset: 97c1a4ad293c Author: ppunegov Date: 2016-03-15 16:23 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/97c1a4ad293c 8150955: RandomValidCommandsTest.java fails with UnsatisfiedLinkError: sun.hotspot.WhiteBox.registerNatives Summary: Replace invalid command with a valid one Reviewed-by: kvn ! test/compiler/compilercontrol/share/MultiCommand.java Changeset: 6daf6d082fd0 Author: thartmann Date: 2016-03-15 17:42 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6daf6d082fd0 8150804: C2 Compilation fails with assert(_base >= OopPtr && _base <= AryPtr) failed: Not a Java pointer Summary: Wait with removing casts from inputs in PhiNode::ideal() until after parsing for the type information to propagate. Reviewed-by: kvn ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/cfgnode.cpp + test/compiler/types/TestPhiElimination.java Changeset: a67e578d4015 Author: never Date: 2016-03-15 14:19 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a67e578d4015 8151871: [JVMCI] missing HAS_PENDING_EXCEPTION check Reviewed-by: kvn ! src/share/vm/jvmci/jvmciCompiler.cpp Changeset: b64b01f6cf4f Author: zmajo Date: 2016-03-17 13:48 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b64b01f6cf4f Merge Changeset: c2c3ba4ed1ac Author: amurillo Date: 2016-03-17 11:25 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c2c3ba4ed1ac Merge Changeset: ffee6483b81b Author: chegar Date: 2016-03-22 10:43 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ffee6483b81b Merge - src/jdk.vm.ci/share/classes/META-INF/services/jdk.vm.ci.hotspot.HotSpotJVMCIBackendFactory ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/runtime/arguments.cpp - test/compiler/jsr292/NonInlinedCall/NonInlinedReinvoker.java - test/compiler/jvmci/common/CompilerToVMHelper.java - test/compiler/jvmci/common/PublicMetaspaceWrapperObject.java - test/compiler/jvmci/events/MetaAccessWrapper.java - test/runtime/BadObjectClass/Object.java - test/testlibrary/jdk/test/lib/PerfCounter.java - test/testlibrary/jdk/test/lib/PerfCounters.java Changeset: 8e0924cea35b Author: chegar Date: 2016-03-22 17:04 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/8e0924cea35b Merge ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/utilities/ostream.cpp + test/compiler/jvmci/meta/StableFieldTest.java ! test/compiler/stable/StableConfiguration.java ! test/compiler/stable/TestStableBoolean.java ! test/compiler/stable/TestStableByte.java ! test/compiler/stable/TestStableChar.java ! test/compiler/stable/TestStableDouble.java ! test/compiler/stable/TestStableFloat.java ! test/compiler/stable/TestStableInt.java ! test/compiler/stable/TestStableLong.java ! test/compiler/stable/TestStableObject.java ! test/compiler/stable/TestStableShort.java ! test/gc/g1/plab/TestPLABPromotion.java ! test/gc/g1/plab/TestPLABResize.java ! test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java Changeset: 958cf9910c0f Author: amurillo Date: 2016-03-22 18:41 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/958cf9910c0f 8152483: Fix a couple of tests that are being incorrectly run on C1 after jigsaw M3 Reviewed-by: ctornqvi, kvn ! test/compiler/unsafe/UnsafeGetConstantField.java ! test/compiler/unsafe/UnsafeGetStableArrayElement.java Changeset: 76582e8dc9e6 Author: lana Date: 2016-03-23 21:44 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/76582e8dc9e6 Merge - test/compiler/compilercontrol/jcmd/StressAddSequentiallyTest.java Changeset: c569f8d89269 Author: lana Date: 2016-03-31 01:13 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c569f8d89269 Added tag jdk-9+112 for changeset 76582e8dc9e6 ! .hgtags Changeset: 84e46a50a084 Author: alanb Date: 2016-03-31 13:54 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/84e46a50a084 Merge ! .hgtags ! make/lib/Lib-jdk.hotspot.agent.gmk ! src/os/linux/vm/os_linux.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/utilities/ostream.cpp - test/compiler/compilercontrol/jcmd/StressAddSequentiallyTest.java ! test/compiler/stable/StableConfiguration.java ! test/compiler/stable/TestStableBoolean.java ! test/compiler/stable/TestStableByte.java ! test/compiler/stable/TestStableChar.java ! test/compiler/stable/TestStableDouble.java ! test/compiler/stable/TestStableFloat.java ! test/compiler/stable/TestStableInt.java ! test/compiler/stable/TestStableLong.java ! test/compiler/stable/TestStableObject.java ! test/compiler/stable/TestStableShort.java ! test/compiler/unsafe/UnsafeGetConstantField.java ! test/gc/g1/TestShrinkAuxiliaryData00.java ! test/gc/g1/TestShrinkAuxiliaryData05.java ! test/gc/g1/TestShrinkAuxiliaryData10.java ! test/gc/g1/TestShrinkAuxiliaryData15.java ! test/gc/g1/TestShrinkAuxiliaryData20.java ! test/gc/g1/TestShrinkAuxiliaryData25.java ! test/gc/g1/TestShrinkAuxiliaryData30.java ! test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java ! test/serviceability/dcmd/compiler/CodelistTest.java From alan.bateman at oracle.com Thu Mar 31 14:16:35 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 31 Mar 2016 14:16:35 +0000 Subject: hg: jigsaw/jake/jdk: 63 new changesets Message-ID: <201603311416.u2VEGcbe004128@aojmv0008.oracle.com> Changeset: 005df9abb92e Author: darcy Date: 2016-03-11 15:30 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/005df9abb92e 8151750: Mark ChangingInterests.java as intermittently failing Reviewed-by: lancea ! test/java/nio/channels/Selector/ChangingInterests.java Changeset: fe5de5d885bb Author: asmotrak Date: 2016-03-11 17:07 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fe5de5d885bb 8151734: Mark Unreachable.java and MaxRetries.java as intermittently failing Reviewed-by: weijun ! test/sun/security/krb5/auto/MaxRetries.java ! test/sun/security/krb5/auto/Unreachable.java Changeset: 25e8c082d7ef Author: mhaupt Date: 2016-03-13 20:26 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/25e8c082d7ef 8150782: findClass / accessClass throw unexpected exceptions Reviewed-by: sundar ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java + test/java/lang/invoke/t8150782/TestAccessClass.java + test/java/lang/invoke/t8150782/TestCls.java + test/java/lang/invoke/t8150782/TestFindClass.java + test/java/lang/invoke/t8150782/TestLookup.java Changeset: d14f551f4d52 Author: mhaupt Date: 2016-03-14 08:10 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d14f551f4d52 8151778: TestLookup.java fails after push of JDK-8150782 Reviewed-by: darcy ! test/java/lang/invoke/t8150782/TestLookup.java Changeset: 2f1011811248 Author: amlu Date: 2016-03-14 19:46 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2f1011811248 8151798: Mark java/util/TimeZone/Bug6772689.java as intermittently failing and demote to tier2 Reviewed-by: lancea ! test/TEST.groups ! test/java/util/TimeZone/Bug6772689.java Changeset: b0b9d09d7640 Author: rriggs Date: 2016-03-12 00:58 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b0b9d09d7640 8151062: Unclosed parenthesis in java.util.EnumMap.clone() Javadoc Reviewed-by: rriggs Contributed-by: Abhijit Roy ! src/java.base/share/classes/java/util/EnumMap.java Changeset: 927f20de2cc1 Author: darcy Date: 2016-03-14 10:48 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/927f20de2cc1 8151835: Mark SmallPrimeExponentP.java as intermittently failing Reviewed-by: vinnie ! test/sun/security/mscapi/SmallPrimeExponentP.java Changeset: 05a1166a8201 Author: mikael Date: 2016-03-03 09:12 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/05a1166a8201 8149159: Clean up Unsafe Reviewed-by: jrose, kvn, stsmirno, chegar, aph, psandoz, redestad, twisti ! src/java.base/share/classes/jdk/internal/misc/Unsafe.java ! src/java.base/share/classes/sun/misc/Unsafe.java + test/jdk/internal/misc/Unsafe/CopyMemory.java ! test/jdk/internal/misc/Unsafe/CopySwap.java Changeset: dfd2c514773c Author: shade Date: 2016-03-03 23:57 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/dfd2c514773c 8150465: Unsafe methods to produce uninitialized arrays Reviewed-by: jrose, kvn, psandoz, aph, twisti, flar ! src/java.base/share/classes/jdk/internal/misc/Unsafe.java Changeset: 6c484053b208 Author: zmajo Date: 2016-03-07 09:34 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6c484053b208 Merge - make/mapfiles/libjfr/mapfile-vers - src/java.base/share/classes/sun/misc/Version.java.template - src/java.base/share/native/libjava/Version.c - test/java/lang/invoke/T8139885.java - test/sun/misc/Version/Version.java Changeset: 5365a0b7e83f Author: amurillo Date: 2016-03-10 16:08 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5365a0b7e83f Merge Changeset: 1640de0263f7 Author: amurillo Date: 2016-03-14 14:28 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1640de0263f7 Merge Changeset: dadd5fa365d5 Author: jjg Date: 2016-03-14 16:13 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/dadd5fa365d5 8151847: rmic should support v53 classfiles Reviewed-by: alanb ! src/jdk.rmic/share/classes/sun/tools/java/RuntimeConstants.java Changeset: dc4a7fcdd13d Author: amlu Date: 2016-03-15 12:38 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/dc4a7fcdd13d 8151785: Doc typo in src/../java/util/stream/PipelineHelper.java Summary: Change from "intoWrapped" to "copyInto". Reviewed-by: rriggs Contributed-by: Hamlin Li ! src/java.base/share/classes/java/util/stream/PipelineHelper.java Changeset: 668137d6d741 Author: ksrini Date: 2016-03-01 12:33 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/668137d6d741 8147755: ASM should create correct constant tag for invokestatic on handle point to interface static method Summary: updates asm to v5.1 Reviewed-by: forax ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassWriter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/Frame.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/Handle.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/Label.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/MethodVisitor.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/MethodWriter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/Type.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/TypePath.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/TypeReference.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/AdviceAdapter.java + src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/AnnotationRemapper.java + src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/ClassRemapper.java + src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/FieldRemapper.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/InstructionAdapter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/LocalVariablesSorter.java + src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/MethodRemapper.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/Remapper.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingAnnotationAdapter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingClassAdapter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingFieldAdapter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingMethodAdapter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingSignatureAdapter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/SerialVersionUIDAdder.java + src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/SignatureRemapper.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/SimpleRemapper.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/signature/SignatureVisitor.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/signature/SignatureWriter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/InsnList.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/ASMifier.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/CheckMethodAdapter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/Printer.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/TraceClassVisitor.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/TraceSignatureVisitor.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/version.txt Changeset: ba91b765b5a5 Author: ksrini Date: 2016-03-15 06:53 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ba91b765b5a5 8151858: update ASM 5.1 to accept V53.0 classfiles Reviewed-by: forax, sundar ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/Opcodes.java Changeset: daf1b0562793 Author: lana Date: 2016-03-15 14:49 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/daf1b0562793 Merge Changeset: 28df1af8e872 Author: rriggs Date: 2016-03-16 13:16 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/28df1af8e872 8085887: java.time.format.FormatStyle.LONG or FULL causes unchecked exception 8076528: LocalTime.format() throws exception when FormatStyle is LONG or FULL Reviewed-by: sherman, scolebourne ! src/java.base/share/classes/java/time/format/DateTimeFormatter.java ! src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java ! src/java.base/share/classes/java/time/format/DateTimePrintContext.java ! src/java.base/share/classes/java/time/temporal/TemporalQueries.java ! test/java/time/test/java/time/format/TestDateTimeFormatter.java Changeset: b0001f7f8765 Author: mikael Date: 2016-03-16 14:04 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b0001f7f8765 8151233: Unify CopySwap and CopyMemory tests Reviewed-by: dholmes + test/jdk/internal/misc/Unsafe/CopyCommon.java ! test/jdk/internal/misc/Unsafe/CopyMemory.java ! test/jdk/internal/misc/Unsafe/CopySwap.java Changeset: 90751bfb53cd Author: bpb Date: 2016-03-17 08:47 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/90751bfb53cd 8152043: (fs) Remove dynamic loopup of Win32 API functions in WindowsNativeDispatcher needed to support Windows XP and Server 2003 Summary: Remove dynamic lookup of Win32 functions which was required to support Windows XP and Windows Server 2003. Reviewed-by: alanb ! src/java.base/windows/native/libnio/fs/WindowsNativeDispatcher.c Changeset: d6a0479363ed Author: clanger Date: 2016-03-18 13:14 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d6a0479363ed 8149169: SSLSocketInputRecord.decodeInputRecord buffer overflow Reviewed-by: xuelei ! src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java + test/sun/security/ssl/SSLSocketImpl/LargePacketAfterHandshakeTest.java Changeset: a025c940d090 Author: xuelei Date: 2016-03-20 00:03 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a025c940d090 8152221: Use try-with-resource in test templates Reviewed-by: weijun ! test/javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java ! test/javax/net/ssl/templates/SSLSocketTemplate.java Changeset: 88577677aec9 Author: alanb Date: 2016-03-20 07:35 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/88577677aec9 8151582: (ch) test java/nio/channels/AsyncCloseAndInterrupt.java failing due to "Connection succeeded" Reviewed-by: bpb, rriggs, alanb Contributed-by: huaming.li at oracle.com ! test/java/nio/channels/AsyncCloseAndInterrupt.java Changeset: cc97013c9cca Author: jlahoda Date: 2016-03-21 10:27 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/cc97013c9cca 8131913: jdk/internal/jline/console/StripAnsiTest.java can't run in the background Summary: Avoid using a real terminal in tests. Reviewed-by: rfield ! test/jdk/internal/jline/console/StripAnsiTest.java Changeset: dd2ab8b2b9f2 Author: naoto Date: 2016-03-21 08:48 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/dd2ab8b2b9f2 8060097: sun/net/idn/TestStringPrep.java failed. Reviewed-by: michaelm ! test/sun/net/idn/TestStringPrep.java Changeset: 8414d01b81db Author: ntv Date: 2016-03-21 14:24 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8414d01b81db 8032051: "ZonedDateTime" class "parse" method fails with short time zone offset ("+01") Reviewed-by: rriggs, scolebourne ! src/java.base/share/classes/java/time/format/DateTimeFormatter.java ! src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java ! test/java/time/tck/java/time/TCKZonedDateTime.java ! test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java ! test/java/time/tck/java/time/format/TCKOffsetPrinterParser.java Changeset: 2008d4fbe4d9 Author: ssahoo Date: 2016-03-21 11:54 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2008d4fbe4d9 8150512: Update test for jdk.security.provider.preferred security property. Reviewed-by: ascarpino ! test/sun/security/jca/PreferredProviderNegativeTest.java ! test/sun/security/jca/PreferredProviderTest.java Changeset: de1f0e168eeb Author: aefimov Date: 2016-03-21 21:58 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/de1f0e168eeb 8145039: JAXB marshaller fails with ClassCastException on classes generated by xjc Reviewed-by: lancea ! test/TEST.groups + test/javax/xml/bind/xjc/8145039/JaxbMarshallTest.java + test/javax/xml/bind/xjc/8145039/testSchema.xsd Changeset: f89fab6f60ad Author: sherman Date: 2016-03-21 15:59 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f89fab6f60ad 8152352: Compiling warnings in zip_util.c blocks devkit to build with --with-zlib=system Reviewed-by: naoto ! src/java.base/share/native/libzip/zip_util.c Changeset: b58e7a5634e8 Author: dsamersoff Date: 2016-03-07 20:59 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b58e7a5634e8 8147456: Parsing of argument for -agentpath can write outside of allocated memory Reviewed-by: sspitsyn, dholmes Contributed-by: sharath.ballal at oracle.com + test/com/sun/jdi/BadAgentPath.java Changeset: 7f21751d0b5b Author: jwilhelm Date: 2016-03-16 14:31 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7f21751d0b5b Merge Changeset: 22692ff458df Author: amurillo Date: 2016-03-17 11:25 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/22692ff458df Merge Changeset: 3ad0ed497418 Author: amurillo Date: 2016-03-21 20:19 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3ad0ed497418 Merge Changeset: 28db8a64363b Author: tvaleev Date: 2016-03-22 16:28 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/28db8a64363b 8151123: Collectors.summingDouble/averagingDouble unnecessarily call mapper twice Reviewed-by: psandoz ! src/java.base/share/classes/java/util/stream/Collectors.java Changeset: 45281ceba474 Author: tvaleev Date: 2016-03-22 16:28 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/45281ceba474 8148748: ArrayList.subList().spliterator() is not late-binding Reviewed-by: psandoz ! src/java.base/share/classes/java/util/ArrayList.java ! test/java/util/Spliterator/SpliteratorLateBindingFailFastTest.java Changeset: fbe70dc61f3b Author: chegar Date: 2016-03-22 10:42 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fbe70dc61f3b Merge - make/gendata/Gendata-jdk.jdeps.gmk - make/gensrc/Gensrc-jdk.dev.gmk - make/gensrc/Gensrc-jdk.jvmstat.gmk - make/launcher/Launcher-jdk.dev.gmk - make/scripts/localelist.sh - make/src/classes/build/tools/module/GenJdepsModulesXml.java - make/src/classes/build/tools/module/GenModulesList.java - make/src/classes/build/tools/module/ImageBuilder.java - make/src/classes/build/tools/module/ModuleArchive.java - make/src/classes/build/tools/module/boot.modules - make/src/classes/build/tools/module/ext.modules ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java - src/java.base/share/classes/jdk/internal/jimage/Archive.java - src/java.base/share/classes/jdk/internal/jimage/BasicImageWriter.java - src/java.base/share/classes/jdk/internal/jimage/ExternalFilesWriter.java - src/java.base/share/classes/jdk/internal/jimage/ImageFileCreator.java - src/java.base/share/classes/jdk/internal/jimage/ImageJavaSubstrate.java - src/java.base/share/classes/jdk/internal/jimage/ImageLocationBase.java - src/java.base/share/classes/jdk/internal/jimage/ImageLocationWriter.java - src/java.base/share/classes/jdk/internal/jimage/ImageModuleData.java - src/java.base/share/classes/jdk/internal/jimage/ImageModuleDataWriter.java - src/java.base/share/classes/jdk/internal/jimage/ImageNativeSubstrate.java - src/java.base/share/classes/jdk/internal/jimage/ImageResourcesTree.java - src/java.base/share/classes/jdk/internal/jimage/ImageStringsWriter.java - src/java.base/share/classes/jdk/internal/jimage/ImageSubstrate.java - src/java.base/share/classes/jdk/internal/jimage/PerfectHashBuilder.java - src/java.base/share/classes/jdk/internal/jimage/ResourcePool.java - src/java.base/share/classes/jdk/internal/jimage/ResourcePoolImpl.java - src/java.base/share/classes/jdk/internal/jimage/StringTable.java - src/java.base/share/classes/jdk/internal/jimage/UTF8String.java - src/java.base/share/classes/sun/misc/Launcher.java - src/java.base/share/classes/sun/util/CoreResourceBundleControl-XLocales.java.template - src/java.base/share/native/libjava/Package.c - src/java.base/share/native/libjava/Proxy.c - src/java.base/share/native/libjimage/ImageNativeSubstrate.cpp - src/java.desktop/share/classes/META-INF/services/java.net.ContentHandlerFactory - src/java.desktop/share/classes/META-INF/services/javax.print.PrintServiceLookup - src/java.desktop/share/classes/META-INF/services/javax.print.StreamPrintServiceFactory - src/java.desktop/share/classes/META-INF/services/javax.sound.midi.spi.MidiDeviceProvider - src/java.desktop/share/classes/META-INF/services/javax.sound.midi.spi.MidiFileReader - src/java.desktop/share/classes/META-INF/services/javax.sound.midi.spi.MidiFileWriter - src/java.desktop/share/classes/META-INF/services/javax.sound.midi.spi.SoundbankReader - src/java.desktop/share/classes/META-INF/services/javax.sound.sampled.spi.AudioFileReader - src/java.desktop/share/classes/META-INF/services/javax.sound.sampled.spi.AudioFileWriter - src/java.desktop/share/classes/META-INF/services/javax.sound.sampled.spi.FormatConversionProvider - src/java.desktop/share/classes/META-INF/services/javax.sound.sampled.spi.MixerProvider - src/java.desktop/share/classes/META-INF/services/sun.datatransfer.DesktopDatatransferService - src/java.logging/share/classes/META-INF/services/jdk.internal.logger.DefaultLoggerFinder - src/java.security.jgss/share/classes/META-INF/services/sun.security.ssl.ClientKeyExchangeService - src/jdk.accessibility/windows/classes/META-INF/services/javax.accessibility.AccessibilityProvider - src/jdk.attach/share/classes/META-INF/services/com.sun.tools.attach.spi.AttachProvider - src/jdk.charsets/share/classes/META-INF/services/java.nio.charset.spi.CharsetProvider - src/jdk.dev/share/classes/jdk/tools/jimage/ExtractedImage.java - src/jdk.dev/share/classes/jdk/tools/jimage/JImageTask.java - src/jdk.dev/share/classes/jdk/tools/jimage/Main.java - src/jdk.dev/share/classes/jdk/tools/jimage/TaskHelper.java - src/jdk.dev/share/classes/jdk/tools/jimage/resources/jimage.properties - src/jdk.jdi/share/classes/META-INF/services/com.sun.jdi.connect.Connector - src/jdk.jdi/share/classes/META-INF/services/com.sun.jdi.connect.spi.TransportService - src/jdk.jvmstat.rmi/share/classes/META-INF/services/sun.jvmstat.monitor.MonitoredHostService - src/jdk.jvmstat/share/classes/META-INF/services/sun.jvmstat.monitor.MonitoredHostService - src/jdk.localedata/share/classes/META-INF/services/sun.util.locale.provider.LocaleDataMetaInfo - src/jdk.management/share/classes/META-INF/services/sun.management.spi.PlatformMBeanProvider - src/jdk.naming.dns/share/classes/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - src/jdk.zipfs/share/classes/META-INF/services/java.nio.file.spi.FileSystemProvider ! test/TEST.groups ! test/java/lang/invoke/t8150782/TestLookup.java + test/java/lang/reflect/AccessibleObject/ModuleSetAccessibleTest.java - test/java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.sh - test/java/net/DatagramSocket/SetDatagramSocketImplFactory/java/net/MyDatagramSocketImplFactory.java - test/java/net/httpclient/whitebox/TEST.properties - test/java/net/httpclient/whitebox/java/net/http/SelectorTest.java - test/java/util/stream/bootlib/TEST.properties - test/jdk/internal/jimage/ExecutableTest.java - test/jdk/internal/jimage/JImageTest.java - test/jdk/internal/jimage/VerifyJimage.java - test/sun/security/krb5/config/NamingManager.java - test/sun/security/krb5/config/dns.sh - test/sun/security/mscapi/IsSunMSCAPIAvailable.sh - test/sun/security/ssl/StatusStapling/BogusStatusRequest.java - test/sun/security/ssl/StatusStapling/CertStatusReqExtensionTests.java - test/sun/security/ssl/StatusStapling/CertStatusReqItemV2Tests.java - test/sun/security/ssl/StatusStapling/CertStatusReqListV2ExtensionTests.java - test/sun/security/ssl/StatusStapling/OCSPStatusRequestTests.java - test/sun/security/ssl/StatusStapling/StatusResponseManagerTests.java - test/sun/security/ssl/StatusStapling/TestCase.java - test/sun/security/ssl/StatusStapling/TestUtils.java Changeset: 5f134507e92b Author: chegar Date: 2016-03-22 16:02 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5f134507e92b Merge ! test/TEST.groups ! test/sun/net/idn/TestStringPrep.java Changeset: 8ca730a3db4c Author: chegar Date: 2016-03-22 16:02 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8ca730a3db4c Merge Changeset: e592cd50bb63 Author: bpb Date: 2016-03-22 15:37 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e592cd50bb63 8151957: ObjectInputStream - Use new convenience method for immutable Map creation during static initialization Summary: Initialize primClasses primitive type name-to-class mapping using a new Map.of() conveience method. Reviewed-by: lancea, redestad, smarks ! src/java.base/share/classes/java/io/ObjectInputStream.java Changeset: 5db7d0e5d12a Author: sundar Date: 2016-03-23 14:54 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5db7d0e5d12a 8152268: jjs tool makefile should use --addmods ALL-SYSTEM Reviewed-by: alanb, hannesw ! make/launcher/Launcher-jdk.scripting.nashorn.shell.gmk Changeset: 3e254419b9fa Author: xuelei Date: 2016-03-23 12:25 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3e254419b9fa 8149017: Delayed provider selection broken in RSA client key exchange Reviewed-by: coffeys ! src/java.base/share/classes/sun/security/ssl/RSAClientKeyExchange.java Changeset: 403329bd6983 Author: rriggs Date: 2016-03-23 19:57 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/403329bd6983 8151868: Typo in java.time.Instant until(Temporal endExclusive, TemporalUnit unit) Reviewed-by: rriggs, lancea, scolebourne Contributed-by: Abhijit Roy ! src/java.base/share/classes/java/time/Instant.java Changeset: 6d9aebccd145 Author: mchung Date: 2016-03-23 09:21 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6d9aebccd145 8152197: Single place to specify module-specific information for images build Reviewed-by: alanb, erikj ! make/gensrc/GensrcModuleLoaderMap.gmk Changeset: 8a37a0ec0728 Author: mchung Date: 2016-03-23 09:23 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8a37a0ec0728 8152227: Remove jdk.deploy.osx module descriptor Reviewed-by: alanb, redestad - src/jdk.deploy.osx/macosx/classes/module-info.java Changeset: 9ea9fb3c0c88 Author: dfuchs Date: 2016-03-23 18:24 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9ea9fb3c0c88 8151281: Module java.httpclient could use System.Logger instead of PlatformLogger Reviewed-by: mchung, michaelm ! src/java.httpclient/share/classes/java/net/http/Log.java Changeset: 775df952df90 Author: naoto Date: 2016-03-23 17:05 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/775df952df90 8152143: jlink --include-locales should gracefully detect certain user error Reviewed-by: mchung ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/IncludeLocalesPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties ! test/tools/jlink/plugins/IncludeLocalesPluginTest.java Changeset: 1f84e73abee1 Author: lana Date: 2016-03-23 21:45 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1f84e73abee1 Merge - src/jdk.deploy.osx/macosx/classes/module-info.java Changeset: 3ac7178352fc Author: shade Date: 2016-03-24 12:52 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3ac7178352fc 8150463: StringConcat MH_INLINE_SIZED_EXACT should skip storage initialization Reviewed-by: plevart, chegar ! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java Changeset: 8bdb63271ed2 Author: chegar Date: 2016-03-24 11:56 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8bdb63271ed2 8152642: Remove sun.misc.Unsafe dependency from java.lang.reflect.Proxy Reviewed-by: alanb, shade ! src/java.base/share/classes/java/lang/reflect/Proxy.java Changeset: ed1ac70edb86 Author: chegar Date: 2016-03-24 11:59 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ed1ac70edb86 8152277: Move URLClassPath.pathToURLs(String) to RegistryImpl Reviewed-by: alanb ! src/java.base/share/classes/sun/misc/URLClassPath.java ! src/java.rmi/share/classes/sun/rmi/registry/RegistryImpl.java Changeset: a18dbcbe2e1a Author: xuelei Date: 2016-03-24 12:41 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a18dbcbe2e1a 8152237: Support BigInteger.TWO Reviewed-by: jnimeh, bpb, weijun ! src/java.base/share/classes/java/math/BigDecimal.java ! src/java.base/share/classes/java/math/BigInteger.java Changeset: e2e318304252 Author: erikj Date: 2016-03-24 14:23 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e2e318304252 8152545: Use preprocessor instead of compiling a program to generate native nio constants Reviewed-by: alanb ! make/gensrc/GensrcMisc.gmk - make/src/native/genconstants/ch/genSocketOptionRegistry.c - make/src/native/genconstants/fs/genSolarisConstants.c - make/src/native/genconstants/fs/genUnixConstants.c + src/java.base/share/classes/sun/nio/ch/SocketOptionRegistry.java.template + src/java.base/solaris/classes/sun/nio/fs/SolarisConstants.java.template + src/java.base/unix/classes/sun/nio/fs/UnixConstants.java.template Changeset: c1288b724e43 Author: dfuchs Date: 2016-03-24 14:45 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c1288b724e43 8152606: java.base no longer needs to export sun.util.logging to java.httpclient Summary: Now that JDK-8151281 is fixed, java.base module-info.java can be cleaned up to no longer export sun.util.logging to java.httpclient. Reviewed-by: chegar, alanb ! src/java.base/share/classes/module-info.java Changeset: ecd6e985e8b2 Author: chegar Date: 2016-03-24 15:32 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ecd6e985e8b2 8149122: Move sun.misc.URLClassPath and Resouce to an internal package Reviewed-by: alanb, rriggs ! src/java.base/share/classes/java/net/URLClassLoader.java ! src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java ! src/java.base/share/classes/jdk/internal/loader/ClassLoaders.java + src/java.base/share/classes/jdk/internal/loader/Resource.java ! src/java.base/share/classes/jdk/internal/loader/URLClassPath.java < src/java.base/share/classes/sun/misc/URLClassPath.java ! src/java.base/share/classes/jdk/internal/misc/JavaNetAccess.java ! src/java.base/share/classes/jdk/internal/module/ModulePatcher.java - src/java.base/share/classes/sun/misc/Resource.java ! src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java + src/java.base/unix/classes/jdk/internal/loader/FileURLMapper.java - src/java.base/unix/classes/sun/misc/FileURLMapper.java + src/java.base/windows/classes/jdk/internal/loader/FileURLMapper.java - src/java.base/windows/classes/sun/misc/FileURLMapper.java Changeset: 87b999055721 Author: chegar Date: 2016-03-24 15:34 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/87b999055721 Merge - make/src/native/genconstants/ch/genSocketOptionRegistry.c - make/src/native/genconstants/fs/genSolarisConstants.c - make/src/native/genconstants/fs/genUnixConstants.c Changeset: 4e79181befb9 Author: mchung Date: 2016-03-24 11:20 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4e79181befb9 8152715: Problem list tools/pack200/Pack200Props.java Reviewed-by: alanb, lancea ! test/ProblemList.txt Changeset: 3abd25870915 Author: mchung Date: 2016-03-24 13:09 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3abd25870915 8152508: tools/jlink/SecurityTest.java failed intermittently Reviewed-by: alanb ! test/tools/jlink/SecurityTest.java Changeset: aac56691c2c4 Author: amlu Date: 2016-03-25 19:46 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/aac56691c2c4 8152749: Mark AdaptorCloseAndInterrupt.java as intermittently failing 8152755: Problem list java/nio/file/WatchService/MayFlies.java Reviewed-by: alanb ! test/ProblemList.txt ! test/java/nio/channels/etc/AdaptorCloseAndInterrupt.java Changeset: eeea9b77edec Author: dfuchs Date: 2016-03-25 17:12 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/eeea9b77edec 8150840: Add an internal system property to control the default level of System.Logger when java.logging is not present. Reviewed-by: mchung, rriggs ! src/java.base/share/classes/jdk/internal/logger/BootstrapLogger.java ! src/java.base/share/classes/jdk/internal/logger/SimpleConsoleLogger.java + src/java.base/share/classes/jdk/internal/logger/SurrogateLogger.java ! src/java.logging/share/classes/java/util/logging/LogRecord.java ! src/java.logging/share/classes/java/util/logging/SimpleFormatter.java ! test/java/lang/System/LoggerFinder/internal/LoggerFinderLoaderTest/LoggerFinderLoaderTest.java + test/java/lang/System/LoggerFinder/internal/SimpleConsoleLoggerTest/SimpleConsoleLoggerTest.java Changeset: 00d704eff42f Author: mchung Date: 2016-03-25 12:30 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/00d704eff42f 8151571: InnocuousThread cannot be created during early startup Reviewed-by: alanb, plevart, chegar ! src/java.base/share/classes/jdk/internal/logger/BootstrapLogger.java ! src/java.base/share/classes/jdk/internal/misc/InnocuousThread.java ! src/java.base/share/classes/jdk/internal/ref/CleanerFactory.java ! src/java.base/share/classes/jdk/internal/ref/CleanerImpl.java ! src/java.base/share/classes/sun/net/www/http/KeepAliveCache.java ! src/java.base/share/classes/sun/net/www/http/KeepAliveStream.java ! src/java.base/share/classes/sun/nio/ch/ThreadPool.java ! src/java.base/share/classes/sun/nio/fs/NativeBuffer.java Changeset: 1565a0efe6f0 Author: asmotrak Date: 2016-03-25 16:50 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1565a0efe6f0 8152798: Mark WeakCipherSuite.java as intermittently failing Reviewed-by: xuelei ! test/javax/net/ssl/DTLS/WeakCipherSuite.java Changeset: 0c17d24c43b6 Author: lana Date: 2016-03-31 01:13 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0c17d24c43b6 Added tag jdk-9+112 for changeset 1565a0efe6f0 ! .hgtags Changeset: cfd3ffca04f3 Author: alanb Date: 2016-03-31 13:55 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/cfd3ffca04f3 Merge ! .hgtags ! make/gensrc/GensrcMisc.gmk ! make/gensrc/GensrcModuleLoaderMap.gmk ! make/launcher/Launcher-jdk.scripting.nashorn.shell.gmk - make/src/native/genconstants/ch/genSocketOptionRegistry.c - make/src/native/genconstants/fs/genSolarisConstants.c - make/src/native/genconstants/fs/genUnixConstants.c ! src/java.base/share/classes/java/io/ObjectInputStream.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java ! src/java.base/share/classes/java/lang/reflect/Proxy.java ! src/java.base/share/classes/java/net/URLClassLoader.java ! src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java ! src/java.base/share/classes/jdk/internal/loader/ClassLoaders.java + src/java.base/share/classes/jdk/internal/loader/URLClassPath.java ! src/java.base/share/classes/jdk/internal/module/ModulePatcher.java ! src/java.base/share/classes/module-info.java - src/java.base/share/classes/sun/misc/Resource.java - src/java.base/share/classes/sun/misc/URLClassPath.java ! src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java ! src/java.base/share/native/libzip/zip_util.c - src/java.base/unix/classes/sun/misc/FileURLMapper.java - src/java.base/windows/classes/sun/misc/FileURLMapper.java - src/jdk.deploy.osx/macosx/classes/module-info.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties ! test/ProblemList.txt ! test/TEST.groups ! test/java/lang/reflect/AccessibleObject/ModuleSetAccessibleTest.java ! test/javax/net/ssl/DTLS/WeakCipherSuite.java ! test/sun/net/idn/TestStringPrep.java ! test/tools/jlink/SecurityTest.java ! test/tools/jlink/plugins/IncludeLocalesPluginTest.java From jonathan.gibbons at oracle.com Thu Mar 31 15:10:21 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 31 Mar 2016 08:10:21 -0700 Subject: javac accepts enums, annotations and final classes being referenced by 'uses' statement In-Reply-To: <56FBB606.7030000@oracle.com> References: <56FBB606.7030000@oracle.com> Message-ID: <56FD3DDD.8050001@oracle.com> Georgiy, Please file this as an issue against javac, and we'll take it from there. The case of the final class has previously been considered and considered "silly but not wrong", but the other two have not been explicitly considered. Alex has previously said in this forum that 'uses' and 'provides' are just a convenient front-end for the ServiceLoader API, so I would expect that to be taken into account when considering what should be accepted as legal here. -- Jon On 03/30/2016 04:18 AM, Georgiy Rakov wrote: > Hello, > > currently JDK9b111 javac successfully compiles following code: > > a/module-info.java: > module a { > uses pkg.FinalClassST; > uses pkg.EnumST; > uses pkg.AnnotationST; > } > > a/pkg/AnnotationST.java: > package pkg; > public @interface AnnotationST{} > > a/pkg/EnumST.java: > package pkg; > public enum EnumST {A,B} > > a/pkg/FinalClassST.java: > package pkg; > public final class FinalClassST{} > > > Could you please tell if this is javac, spec or both issue that type > being referenced by 'uses' statement is not checked at compile-time > for ability to be a service interface. > > The minimized testcase is attached; in order to run it please: > 1. unzip attached archive on Windows machine; > 2. rename test9\test_bat to test9\test.bat; > 3. modify test.bat by changing JDK_HOME variable to point to your JDK > installation; > 4. run test.bat. > > BTW: provided the type name references non existing type javac does > produce compile error. > > Thanks, > Georgiy. From mandy.chung at oracle.com Thu Mar 31 16:56:02 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 31 Mar 2016 09:56:02 -0700 Subject: Review request 8153211: Convert build tool to use the new -XaddExports syntax in bootcycle build Message-ID: A few build tools are using the old -XaddExports syntax that should switch to the new syntax: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8153211/webrev.00/ Mandy From Alan.Bateman at oracle.com Thu Mar 31 17:06:13 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 31 Mar 2016 18:06:13 +0100 Subject: Review request 8153211: Convert build tool to use the new -XaddExports syntax in bootcycle build In-Reply-To: References: Message-ID: <56FD5905.3080308@oracle.com> On 31/03/2016 17:56, Mandy Chung wrote: > A few build tools are using the old -XaddExports syntax that should switch to the new syntax: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8153211/webrev.00/ > > Mandy This looks okay, are you planning to push these to jake or jdk9/dev? -Alan From mandy.chung at oracle.com Thu Mar 31 17:08:29 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 31 Mar 2016 10:08:29 -0700 Subject: Review request 8153211: Convert build tool to use the new -XaddExports syntax in bootcycle build In-Reply-To: <56FD5905.3080308@oracle.com> References: <56FD5905.3080308@oracle.com> Message-ID: > On Mar 31, 2016, at 10:06 AM, Alan Bateman wrote: > > > On 31/03/2016 17:56, Mandy Chung wrote: >> A few build tools are using the old -XaddExports syntax that should switch to the new syntax: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8153211/webrev.00/ >> >> Mandy > This looks okay, are you planning to push these to jake or jdk9/dev? jdk9/dev and then import to jigsaw/jake. bootcycle build is broken in jigsaw/jake. Mandy From sundararajan.athijegannathan at oracle.com Thu Mar 31 17:38:18 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 31 Mar 2016 23:08:18 +0530 Subject: RFR 8136645: jlink tool should create windows os compatible launcher Message-ID: <56FD608A.60901@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8136645/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8136645 Thanks, -Sundar From sundararajan.athijegannathan at oracle.com Thu Mar 31 18:31:47 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 1 Apr 2016 00:01:47 +0530 Subject: RFR 8136645: jlink tool should create windows os compatible launcher In-Reply-To: <56FD608A.60901@oracle.com> References: <56FD608A.60901@oracle.com> Message-ID: <56FD6D13.30103@oracle.com> Please review updated webrev @ http://cr.openjdk.java.net/~sundar/8136645/webrev.01/ PS. Fixed "/" with "\" in "java" path. The generated batch file worked in either case - but changing for consistency. Thanks, -Sundar On 3/31/2016 11:08 PM, Sundararajan Athijegannathan wrote: > Please review http://cr.openjdk.java.net/~sundar/8136645/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8136645 > > Thanks, > -Sundar From Alan.Bateman at oracle.com Thu Mar 31 19:09:44 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 31 Mar 2016 20:09:44 +0100 Subject: RFR 8136645: jlink tool should create windows os compatible launcher In-Reply-To: <56FD6D13.30103@oracle.com> References: <56FD608A.60901@oracle.com> <56FD6D13.30103@oracle.com> Message-ID: <56FD75F8.1040400@oracle.com> On 31/03/2016 19:31, Sundararajan Athijegannathan wrote: > Please review updated webrev @ > http://cr.openjdk.java.net/~sundar/8136645/webrev.01/ > > PS. Fixed "/" with "\" in "java" path. The generated batch file worked > in either case - but changing for consistency. > Does this generate the .bat on all platforms? -Alan From dmitry.samersoff at oracle.com Thu Mar 31 21:33:57 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 1 Apr 2016 00:33:57 +0300 Subject: RFR 8136645: jlink tool should create windows os compatible launcher In-Reply-To: <56FD608A.60901@oracle.com> References: <56FD608A.60901@oracle.com> Message-ID: <56FD97C5.3080700@oracle.com> Sundararajan, Occasionally put my nose in. Just $0.2 ... 1. Do we really need separate .append("\n")? Also Windows convention is "\r\n" 2. Is it possible to name a module using other languages (e.g. Russian or Japanese). Is StandardCharsets.ISO_8859_1 appropriate in this case? 3. Is PosixFileAttributeView.class appropriate here? If yes - please add a comment, because name is misleading. -Dmitry On 2016-03-31 20:38, Sundararajan Athijegannathan wrote: > Please review http://cr.openjdk.java.net/~sundar/8136645/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8136645 > > Thanks, > -Sundar > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From mandy.chung at oracle.com Thu Mar 31 22:05:07 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 31 Mar 2016 15:05:07 -0700 Subject: RFR: 8152641: Plugin to generate BMH$Species classes ahead-of-time In-Reply-To: <56FB09D3.4090000@oracle.com> References: <56F3EEAB.4090600@oracle.com> <1FE3F7A6-1C7B-4DC6-875C-E3FAEDED08F5@oracle.com> <56F50EC5.6020500@gmail.com> <56F5520D.3080205@oracle.com> <56F676CA.5000803@gmail.com> <56FB09D3.4090000@oracle.com> Message-ID: <92644FFF-D97D-4F12-AF10-F1393A0E103A@oracle.com> > On Mar 29, 2016, at 4:03 PM, Claes Redestad wrote: > > Mandy: I've not found any test (under jdk/test/tools/jlink or elsewhere) which > has to be updated when adding a plugin like this. jdk/test/tools/jlink/JLinkTest.java This is the one I recalled. This is in the core_tools or tier2 test group. The jlink tests are not run in the default test group. Mandy From mandy.chung at oracle.com Thu Mar 31 23:10:26 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 31 Mar 2016 16:10:26 -0700 Subject: RFR: 8152641: Plugin to generate BMH$Species classes ahead-of-time In-Reply-To: <56FBFC23.5090104@oracle.com> References: <56F3EEAB.4090600@oracle.com> <1FE3F7A6-1C7B-4DC6-875C-E3FAEDED08F5@oracle.com> <56F50EC5.6020500@gmail.com> <56F5520D.3080205@oracle.com> <56F676CA.5000803@gmail.com> <56FB09D3.4090000@oracle.com> <56FB82FE.5010209@gmail.com> <56FB8607.8030000@gmail.com> <56FBB014.6050002@oracle.com> <56FBC4D8.8010603@gmail.com> <56FBDF98.4090102@oracle.com> <56FBEE08.7010600@gmail.com> <56FBFC23.5090104@oracle.com> Message-ID: > On Mar 30, 2016, at 9:17 AM, Claes Redestad wrote: > > Hi Peter, > > something like this, then: > > http://cr.openjdk.java.net/~redestad/8152641/webrev.05/ > BoundMethodHandle::generateConcreteBMHClassBytes It only allows ?LIJFD? characters. But the default species types include digit e.g. L3, L4, etc. Do you see the warnings generated from GenerateBMHClassesPlugin? Nit: the method parameters are wrapped in the next line with 8-space indentation. It?d be better to follow the convention this source file uses. GenerateBMHClassesPlugin::configure The plugin should validate of the input argument and throw an exception if it?s invalid. The plugin API is still being revised and JDK-8152800 is related to the exception case. The existing plugins throw PluginException. GenerateBMHClassesPlugin can do the same. Perhaps the expanded signatures should be stored after validation. GenerateBMHClassesPlugin::generateConcreteClass It issues a warning if any exception thrown. If the user specifies the types in the command line, they should specify the valid values (I would expect). I prefer it to be an error and throw PluginException. It may be time to rename this plugin to ?-generate-jli-classes plugin, as John suggests. A jlink plugin can define its sub options e.g. ?-generate-jli-classes=bmh[:species=LL,LLL]. Can you add a test to sanity test if the classes are generated (both the default species types as well as specified in the input argument)? Mandy From mandy.chung at oracle.com Thu Mar 31 23:48:12 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 31 Mar 2016 16:48:12 -0700 Subject: RFR: 8152641: Plugin to generate BMH$Species classes ahead-of-time In-Reply-To: References: <56F3EEAB.4090600@oracle.com> <1FE3F7A6-1C7B-4DC6-875C-E3FAEDED08F5@oracle.com> <56F50EC5.6020500@gmail.com> <56F5520D.3080205@oracle.com> <56F676CA.5000803@gmail.com> <56FB09D3.4090000@oracle.com> <56FB82FE.5010209@gmail.com> <56FB8607.8030000@gmail.com> <56FBB014.6050002@oracle.com> <56FBC4D8.8010603@gmail.com> <56FBDF98.4090102@oracle.com> <56FBEE08.7010600@gmail.com> <56FBFC23.5090104@oracle.com> Message-ID: <1662F7C4-9395-4706-A3E4-AC6D937BBD77@oracle.com> > On Mar 31, 2016, at 4:10 PM, Mandy Chung wrote: > > >> On Mar 30, 2016, at 9:17 AM, Claes Redestad wrote: >> >> Hi Peter, >> >> something like this, then: >> >> http://cr.openjdk.java.net/~redestad/8152641/webrev.05/ >> > > BoundMethodHandle::generateConcreteBMHClassBytes > It only allows ?LIJFD? characters. But the default species types include digit e.g. L3, L4, etc. Do you see the warnings generated from GenerateBMHClassesPlugin? Ignore this comment - I meant to take it out but forgot. Mandy