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