From sundararajan.athijegannathan at oracle.com Wed Feb 1 05:06:42 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 01 Feb 2017 10:36:42 +0530 Subject: RFR 8173717: jlink --help fails with missing "plugin.opt.plugin-module-path" key in resource bundle Message-ID: <58916CE2.7000208@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8173717/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8173717 Thanks, -Sundar From mandy.chung at oracle.com Wed Feb 1 05:12:28 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 31 Jan 2017 21:12:28 -0800 Subject: RFR 8173717: jlink --help fails with missing "plugin.opt.plugin-module-path" key in resource bundle In-Reply-To: <58916CE2.7000208@oracle.com> References: <58916CE2.7000208@oracle.com> Message-ID: <419D1D9D-9F40-411C-A7AB-0BF4CE30FAB3@oracle.com> > On Jan 31, 2017, at 9:06 PM, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8173717/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8173717 +1 Thanks for fixing this quickly. Mandy From Alan.Bateman at oracle.com Wed Feb 1 08:10:35 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 1 Feb 2017 08:10:35 +0000 Subject: RFR 8173717: jlink --help fails with missing "plugin.opt.plugin-module-path" key in resource bundle In-Reply-To: <58916CE2.7000208@oracle.com> References: <58916CE2.7000208@oracle.com> Message-ID: <91322223-6fb5-f540-753f-17dbe79d696a@oracle.com> On 01/02/2017 05:06, Sundararajan Athijegannathan wrote: > Please review http://cr.openjdk.java.net/~sundar/8173717/webrev.00/ > for https://bugs.openjdk.java.net/browse/JDK-8173717 Looks good. From Alan.Bateman at oracle.com Wed Feb 1 08:22:28 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 1 Feb 2017 08:22:28 +0000 Subject: The module implementation uses the wrong values for ACC_TRANSITIVE and ACC_STATIC_PHASE In-Reply-To: <620245731.599373.1485814531347.JavaMail.zimbra@u-pem.fr> References: <620245731.599373.1485814531347.JavaMail.zimbra@u-pem.fr> Message-ID: <6b4d5057-32c2-de06-215c-c99333cebf06@oracle.com> On 30/01/2017 22:15, Remi Forax wrote: > Hi all, > chasing a bug on ASM, i've found that the module implementation in the JDK uses the wrong values for ACC_TRANSITIVE and ACC_STATIC_PHASE, > in the spec [1], > 0x0020 (ACC_TRANSITIVE) > 0x0040 (ACC_STATIC_PHASE) > but in the implementation [2], > public static final int ACC_TRANSITIVE = 0x0010; > public static final int ACC_STATIC_PHASE = 0x0020; > Sigh, we do have a mismatch, I think a consequence of the churn last year on the design proposals. Note that javac and the run time are in sync so this doesn't impact anyone except when they start using the updated ASM to read/write module-info.class. I would like to get the spec updates that we are accumulating in jake into JDK 9 before JDK 9 his ZBB and and right time to sort out the requires_flags too. -Alan From forax at univ-mlv.fr Wed Feb 1 11:58:01 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 01 Feb 2017 11:58:01 +0000 Subject: The module implementation uses the wrong values for ACC_TRANSITIVE and ACC_STATIC_PHASE In-Reply-To: <6b4d5057-32c2-de06-215c-c99333cebf06@oracle.com> References: <620245731.599373.1485814531347.JavaMail.zimbra@u-pem.fr> <6b4d5057-32c2-de06-215c-c99333cebf06@oracle.com> Message-ID: <084DB662-B519-4E9C-BE49-1EE080067F98@univ-mlv.fr> If the spec is updated, i really want to get ride of ACC_STATIC_PHASE and uses ACC_STATIC instead. Renaming public to transitive was the right move but I think we go a little over the top with static. In the module-info, the Java syntax already uses static, i do not see a lot of value to use a different flag. As a example, we did not introduce a new flag for static methods in an interface even if they do not have the same behavior as static methods in a class. Remi On February 1, 2017 9:22:28 AM GMT+01:00, Alan Bateman wrote: >On 30/01/2017 22:15, Remi Forax wrote: > >> Hi all, >> chasing a bug on ASM, i've found that the module implementation in >the JDK uses the wrong values for ACC_TRANSITIVE and ACC_STATIC_PHASE, >> in the spec [1], >> 0x0020 (ACC_TRANSITIVE) >> 0x0040 (ACC_STATIC_PHASE) >> but in the implementation [2], >> public static final int ACC_TRANSITIVE = 0x0010; >> public static final int ACC_STATIC_PHASE = 0x0020; >> >Sigh, we do have a mismatch, I think a consequence of the churn last >year on the design proposals. Note that javac and the run time are in >sync so this doesn't impact anyone except when they start using the >updated ASM to read/write module-info.class. I would like to get the >spec updates that we are accumulating in jake into JDK 9 before JDK 9 >his ZBB and and right time to sort out the requires_flags too. > >-Alan -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From nipa at codefx.org Wed Feb 1 14:27:48 2017 From: nipa at codefx.org (Nicolai Parlog) Date: Wed, 1 Feb 2017 15:27:48 +0100 Subject: -Xlog and the module system Message-ID: <7c4c1751-17b9-6c4c-df62-162056fc0688@codefx.org> Hi! When playing with `-Xlog:modules*` (down to trace) I hoped for a little more output that I could use to analyze a configuration. Things that are missing and would be helpful: * Which JARs end up in the unnamed module? (Although I'm not sure whether that is even known at the time.) * Which JARs become automatic modules? * For each module that is created, why does that happen? Is it required by another module? Is module creation triggered by a qualified export? (The latter was the only explanation I had for modules like jdk.scripting.nashorn being initialized at all). * When a module is missing, following what path from one of the root modules was it required? * What happens with services? (They do not seem to be mentioned at all.) * What exception lead to the aborted launch? (Or is it policy not to log error messages?) * When --limit-modules is used, the log is just magically smaller as if deriving the universe of observable modules did not happen at all. In principle, it would be great to have enough information to trouble-shoot problematic configurations from looking at the log. As it stands a lot of external information (launch command, directories, error messages, even JAR content) has to be included for remote debugging to be possible. That being said, I generally find the error messages themselves pretty informative. Good job! :) so long ... Nicolai -- PGP Key: http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509 Web: http://codefx.org a blog about software development https://www.sitepoint.com/java high-quality Java/JVM content http://do-foss.de Free and Open Source Software for the City of Dortmund Twitter: https://twitter.com/nipafx From Alan.Bateman at oracle.com Wed Feb 1 17:20:52 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 1 Feb 2017 17:20:52 +0000 Subject: -Xlog and the module system In-Reply-To: <7c4c1751-17b9-6c4c-df62-162056fc0688@codefx.org> References: <7c4c1751-17b9-6c4c-df62-162056fc0688@codefx.org> Message-ID: On 01/02/2017 14:27, Nicolai Parlog wrote: > Hi! > > When playing with `-Xlog:modules*` (down to trace) I hoped for a > little more output that I could use to analyze a configuration. -Xlog:modules is VM oriented and mostly traces the primitives used to construct the module graph in the VM. -Xdiag:resolver is probably closer to what you are looking for. We will probably re-visit this output at some point but there are other issues to clear away first. -Alan. From alan.bateman at oracle.com Wed Feb 1 18:47:37 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 01 Feb 2017 18:47:37 +0000 Subject: hg: jigsaw/jake/jdk: AccessibleObject javadoc improvements Message-ID: <201702011847.v11IlbJ3016787@aojmv0008.oracle.com> Changeset: 18fb55eee74b Author: alanb Date: 2017-02-01 18:47 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/18fb55eee74b AccessibleObject javadoc improvements Contributed-by: alex.buckley at oracle.com ! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java From sean.mullan at oracle.com Wed Feb 1 19:54:43 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 1 Feb 2017 14:54:43 -0500 Subject: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied In-Reply-To: <44576DF7-9F0F-4AEA-BF9B-89A429E0AE00@oracle.com> References: <9E737664-1D12-4E3B-B1D6-BED53E581067@oracle.com> <83F83107-EDB1-4C0A-BA6C-493A700A0AFC@oracle.com> <5C71A420-B6F0-43E1-B2F4-6BB230464B35@oracle.com> <503ACAF4-A166-4950-9EF9-38B7093EE6BB@oracle.com> <0B66D3A8-A571-4881-8CDB-81193030FD01@oracle.com> <1ecd3a3e-d7ce-627e-ddb1-48a740a7edc2@oracle.com> <2891BDE5-2009-4A6E-8012-5DAFF9D8DCA0@oracle.com> <5BB17CBF-E3F2-424D-B140-053A0D0E518F@oracle.com> <0125272C-6FAD-45D7-8E2B-C413C38FCF89@oracle.com> <333E985C-F868-41F9-8B19-A89CE06A59DF@oracle.com> <52949887-B5EB-4131-B3A1-5E7693334302@oracle.com> <44576DF7-9F0F-4AEA-BF9B-89A429E0AE00@oracle.com> Message-ID: Couple of comments: - jdk.vm.ci is already loaded by the boot loader so it is implicitly granted AllPermission and does not need an entry in default.policy. - all internal APIs in the jdk.vm.compiler module will now be restricted by default by SecurityManager::checkPackageAccess(), so if you have any code or tests running with a SecurityManager that are accessing internal APIs in the jdk.vm.compiler module, you will need to grant them an appropriate "accessClassInPackage" RuntimePermission in addition to any --add-exports option you are using to break through encapsulation. --Sean On 2/1/17 6:07 AM, Doug Simon wrote: > I?ve reworked the webrev as requested to make jdk.vm.compiler a non-upgradeable platform module, this allowing it to be mentioned in default.policy: > > http://cr.openjdk.java.net/~dnsimon/8145337/ > > -Doug > >> On 30 Jan 2017, at 22:53, Mandy Chung wrote: >> >>> >>> On Jan 30, 2017, at 1:36 PM, Doug Simon wrote: >>> >>> >>>> On 30 Jan 2017, at 21:55, Mandy Chung wrote: >>>> >>>> >>>>> On Jan 30, 2017, at 10:38 AM, Doug Simon wrote: >>>>> >>>>> I?ve extended the webrev with that change - please re-review: >>>>> >>>>> http://cr.openjdk.java.net/~dnsimon/8145337_make/webrev >>>>> >>>> >>>> +1 >>> >>> Thanks. Is that a ?Reviewed?? >>> >> >> Sorry. I only noticed now that you added this to UPGRADEABLE_MODULE. Please add it only to PLATFORM_MODULES list instead. >> >> Making it an upgradeable module is a separate issue. I suggest you reopen JDK-8171448. Specifically, since upgradeable modules are not tied with java.base, our goal for JDK 9 is to eliminate qualified exports from JDK modules to upgradeable modules, e.g. JDK-8170116, JDK-8166745, JDK-8161549. >> >>> I think I should get at least one sign-off from the security team. >>> >> >> Hope Sean will review this one. Please send an updated webrev. >> >>> Also, since this is effectively making jdk.vm.compiler an upgradeable module, >> >> No it does not. >> >>> what?s the implication for it being a hash-checked module? >> >> When a module M is recorded in the ModuleHashes attribute of java.base, the runtime will check if module M resolved in the graph matches the one tied with java.base when created at build time; if not, it will fail. If an upgradeable module >> >>> It seems like these changes effectively achieve what I was requesting with https://bugs.openjdk.java.net/browse/JDK-8171448. >> >> JDK-8145337 is about the security permission. It?s better to separate this review from JDK-8171448. >> >> Mandy >> >>> >>> -Doug >>> >>>> >>>>> Strangely, there was no existing declaration of jdk.vm.compiler in Modules.gmk. >>>>> >>>> >>>> Default is to be defined by the application class loader. The build will find all modules from the source. There is no need to list all modules. >>>> >>>>> BTW, I never answered your question: >>>>> >>>>> "How does JVMCI call out to jdk.vm.compiler? does it load classes using Class::forName with the system class loader?? >>>>> >>>>> It uses JVMCIServiceLocator[1] which is a mechanism built on the standard ServiceLoader. >>>> >>>> Thanks for the pointer. That confirms my understanding that loads the service providers using the system class loader. >>>> >>>> Mandy > From nipa at codefx.org Wed Feb 1 21:49:52 2017 From: nipa at codefx.org (Nicolai Parlog) Date: Wed, 1 Feb 2017 22:49:52 +0100 Subject: -Xlog and the module system In-Reply-To: References: <7c4c1751-17b9-6c4c-df62-162056fc0688@codefx.org> Message-ID: <03fac1c7-cc49-23f5-49ab-1bfac418e1ec@codefx.org> Hi Alan, `-Xdiag:resolver` is awesome! :) I think these messages are great candidates for info-level messages with the "modules" tag via unified logging. Something else I noticed, neither Xlog nor Xdiag help with problematic configurations - both only start logging after everything checked out, so with missing modules (for example), they do not provide additional information. > We will probably re-visit this output at some point but there are > other issues to clear away first. I can understand that logging might not be the most pressing feature this close to the release. :) so long ... Nicolai On 01.02.2017 18:20, Alan Bateman wrote: > On 01/02/2017 14:27, Nicolai Parlog wrote: > >> Hi! >> >> When playing with `-Xlog:modules*` (down to trace) I hoped for a >> little more output that I could use to analyze a configuration. > -Xlog:modules is VM oriented and mostly traces the primitives used to > construct the module graph in the VM. > > -Xdiag:resolver is probably closer to what you are looking for. We will > probably re-visit this output at some point but there are other issues > to clear away first. > > -Alan. > -- PGP Key: http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509 Web: http://codefx.org a blog about software development https://www.sitepoint.com/java high-quality Java/JVM content http://do-foss.de Free and Open Source Software for the City of Dortmund Twitter: https://twitter.com/nipafx From jonathan.gibbons at oracle.com Wed Feb 1 22:16:55 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 01 Feb 2017 14:16:55 -0800 Subject: -Xlog and the module system In-Reply-To: <03fac1c7-cc49-23f5-49ab-1bfac418e1ec@codefx.org> References: <7c4c1751-17b9-6c4c-df62-162056fc0688@codefx.org> <03fac1c7-cc49-23f5-49ab-1bfac418e1ec@codefx.org> Message-ID: <58925E57.2040201@oracle.com> FWIW, I think javac also deserves some amount of similar work. -- Jon On 02/01/2017 01:49 PM, Nicolai Parlog wrote: > Hi Alan, > > `-Xdiag:resolver` is awesome! :) I think these messages are great > candidates for info-level messages with the "modules" tag via unified > logging. > > Something else I noticed, neither Xlog nor Xdiag help with problematic > configurations - both only start logging after everything checked out, > so with missing modules (for example), they do not provide additional > information. > >> We will probably re-visit this output at some point but there are >> other issues to clear away first. > I can understand that logging might not be the most pressing feature > this close to the release. :) > > so long ... Nicolai > > > > On 01.02.2017 18:20, Alan Bateman wrote: >> On 01/02/2017 14:27, Nicolai Parlog wrote: >> >>> Hi! >>> >>> When playing with `-Xlog:modules*` (down to trace) I hoped for a >>> little more output that I could use to analyze a configuration. >> -Xlog:modules is VM oriented and mostly traces the primitives used to >> construct the module graph in the VM. >> >> -Xdiag:resolver is probably closer to what you are looking for. We will >> probably re-visit this output at some point but there are other issues >> to clear away first. >> >> -Alan. >> From sean.mullan at oracle.com Wed Feb 1 22:17:07 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 1 Feb 2017 17:17:07 -0500 Subject: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied In-Reply-To: References: <9E737664-1D12-4E3B-B1D6-BED53E581067@oracle.com> <0B66D3A8-A571-4881-8CDB-81193030FD01@oracle.com> <1ecd3a3e-d7ce-627e-ddb1-48a740a7edc2@oracle.com> <2891BDE5-2009-4A6E-8012-5DAFF9D8DCA0@oracle.com> <5BB17CBF-E3F2-424D-B140-053A0D0E518F@oracle.com> <0125272C-6FAD-45D7-8E2B-C413C38FCF89@oracle.com> <333E985C-F868-41F9-8B19-A89CE06A59DF@oracle.com> <52949887-B5EB-4131-B3A1-5E7693334302@oracle.com> <44576DF7-9F0F-4AEA-BF9B-89A429E0AE00@oracle.com> <3BC2EC38-D0B3-49EC-8BD0-FD72138C9369@oracle.com> <0FEF3A7E-DD48-4427-A3F2-3DFB985CF83F@oracle.com> Message-ID: <317ffefa-5535-0a0c-0ad7-7e61260b26d0@oracle.com> On 2/1/17 4:27 PM, Doug Simon wrote: > Can I now consider this change reviewed and integrate it? Yes. --Sean From david.holmes at oracle.com Thu Feb 2 01:25:28 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 2 Feb 2017 11:25:28 +1000 Subject: -Xlog and the module system In-Reply-To: <03fac1c7-cc49-23f5-49ab-1bfac418e1ec@codefx.org> References: <7c4c1751-17b9-6c4c-df62-162056fc0688@codefx.org> <03fac1c7-cc49-23f5-49ab-1bfac418e1ec@codefx.org> Message-ID: <7cb63117-4d27-52c0-f7bf-786902bdd841@oracle.com> On 2/02/2017 7:49 AM, Nicolai Parlog wrote: > Hi Alan, > > `-Xdiag:resolver` is awesome! :) I think these messages are great > candidates for info-level messages with the "modules" tag via unified > logging. You are dealing with two completely separate pieces of the platform. -Xdiag is a launcher option which sets Java properties for use by the Java code. -Xlog is a VM option and only deals with VM support for subsystems. The two are complementary. The "unified" in "unified logging" refers to the VM, not to the platform. David ----- > Something else I noticed, neither Xlog nor Xdiag help with problematic > configurations - both only start logging after everything checked out, > so with missing modules (for example), they do not provide additional > information. > >> We will probably re-visit this output at some point but there are >> other issues to clear away first. > > I can understand that logging might not be the most pressing feature > this close to the release. :) > > so long ... Nicolai > > > > On 01.02.2017 18:20, Alan Bateman wrote: >> On 01/02/2017 14:27, Nicolai Parlog wrote: >> >>> Hi! >>> >>> When playing with `-Xlog:modules*` (down to trace) I hoped for a >>> little more output that I could use to analyze a configuration. >> -Xlog:modules is VM oriented and mostly traces the primitives used to >> construct the module graph in the VM. >> >> -Xdiag:resolver is probably closer to what you are looking for. We will >> probably re-visit this output at some point but there are other issues >> to clear away first. >> >> -Alan. >> > From mandy.chung at oracle.com Thu Feb 2 02:12:26 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 1 Feb 2017 18:12:26 -0800 Subject: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied In-Reply-To: <44576DF7-9F0F-4AEA-BF9B-89A429E0AE00@oracle.com> References: <9E737664-1D12-4E3B-B1D6-BED53E581067@oracle.com> <589793F7-0BD0-4B05-AF70-5253EF2907DC@oracle.com> <83F83107-EDB1-4C0A-BA6C-493A700A0AFC@oracle.com> <5C71A420-B6F0-43E1-B2F4-6BB230464B35@oracle.com> <503ACAF4-A166-4950-9EF9-38B7093EE6BB@oracle.com> <0B66D3A8-A571-4881-8CDB-81193030FD01@oracle.com> <1ecd3a3e-d7ce-627e-ddb1-48a740a7edc2@oracle.com> <2891BDE5-2009-4A6E-8012-5DAFF9D8DCA0@oracle.com> <5BB17CBF-E3F2-424D-B140-053A0D0E518F@oracle.com> <0125272C-6FAD-45D7-8E2B-C413C38FCF89@oracle.com> <333E985C-F868-41F9-8B19-A89CE06A59DF@oracle.com> <52949887-B5EB-4131-B3A1-5E7693334302@oracle.com> <44576DF7-9F0F-4AEA-BF9B-89! A429E0AE00@oracle.com> Message-ID: <970E0BAE-2DFA-4B30-8B4B-A730391308D5@oracle.com> > On Feb 1, 2017, at 3:07 AM, Doug Simon wrote: > > I?ve reworked the webrev as requested to make jdk.vm.compiler a non-upgradeable platform module, this allowing it to be mentioned in default.policy: > > http://cr.openjdk.java.net/~dnsimon/8145337/ Looks good. Mandy From Alan.Bateman at oracle.com Thu Feb 2 08:07:36 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 2 Feb 2017 08:07:36 +0000 Subject: -Xlog and the module system In-Reply-To: <03fac1c7-cc49-23f5-49ab-1bfac418e1ec@codefx.org> References: <7c4c1751-17b9-6c4c-df62-162056fc0688@codefx.org> <03fac1c7-cc49-23f5-49ab-1bfac418e1ec@codefx.org> Message-ID: On 01/02/2017 21:49, Nicolai Parlog wrote: > Hi Alan, > > `-Xdiag:resolver` is awesome! :) I think these messages are great > candidates for info-level messages with the "modules" tag via unified > logging. I agree it should be transparent to developers using the JDK as to whether the implementation is in libjvm or else where, something that will likely more of an issue going forward when more of the run time is written in the Java Language. > > Something else I noticed, neither Xlog nor Xdiag help with problematic > configurations - both only start logging after everything checked out, > so with missing modules (for example), they do not provide additional > information. The trace messages emitted by -Xdiag:resolver are printed as the resolver runs. So aside from the initial module then they would see some output when transitive dependences can't be found. -Alan From Alan.Bateman at oracle.com Thu Feb 2 08:09:11 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 2 Feb 2017 08:09:11 +0000 Subject: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied In-Reply-To: <970E0BAE-2DFA-4B30-8B4B-A730391308D5@oracle.com> References: <9E737664-1D12-4E3B-B1D6-BED53E581067@oracle.com> <5C71A420-B6F0-43E1-B2F4-6BB230464B35@oracle.com> <503ACAF4-A166-4950-9EF9-38B7093EE6BB@oracle.com> <0B66D3A8-A571-4881-8CDB-81193030FD01@oracle.com> <1ecd3a3e-d7ce-627e-ddb1-48a740a7edc2@oracle.com> <2891BDE5-2009-4A6E-8012-5DAFF9D8DCA0@oracle.com> <5BB17CBF-E3F2-424D-B140-053A0D0E518F@oracle.com> <0125272C-6FAD-45D7-8E2B-C413C38FCF89@oracle.com> <333E985C-F868-41F9-8B19-A89CE06A59DF@oracle.com> <52949887-B5EB-4131-B3A1-5E7693334302@oracle.com> <44576DF7-9F0F-4AEA-BF9B-89! A429E0AE00@oracle.com> <970E0BAE-2DFA-4B30-8B4B-A730391308D5@oracle.com> Message-ID: <913dc879-1b70-8530-7992-f06bc8674237@oracle.com> On 02/02/2017 02:12, Mandy Chung wrote: >> On Feb 1, 2017, at 3:07 AM, Doug Simon wrote: >> >> I?ve reworked the webrev as requested to make jdk.vm.compiler a non-upgradeable platform module, this allowing it to be mentioned in default.policy: >> >> http://cr.openjdk.java.net/~dnsimon/8145337/ > Looks good. > Looks okay to me too. -Alan. From doug.simon at oracle.com Wed Feb 1 11:07:21 2017 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 1 Feb 2017 12:07:21 +0100 Subject: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied In-Reply-To: <52949887-B5EB-4131-B3A1-5E7693334302@oracle.com> References: <9E737664-1D12-4E3B-B1D6-BED53E581067@oracle.com> <589793F7-0BD0-4B05-AF70-5253EF2907DC@oracle.com> <83F83107-EDB1-4C0A-BA6C-493A700A0AFC@oracle.com> <5C71A420-B6F0-43E1-B2F4-6BB230464B35@oracle.com> <503ACAF4-A166-4950-9EF9-38B7093EE6BB@oracle.com> <0B66D3A8-A571-4881-8CDB-81193030FD01@oracle.com> <1ecd3a3e-d7ce-627e-ddb1-48a740a7edc2@oracle.com> <2891BDE5-2009-4A6E-8012-5DAFF9D8DCA0@oracle.com> <5BB17CBF-E3F2-424D-B140-053A0D0E518F@oracle.com> <0125272C-6FAD-45D7-8E2B-C413C38FCF89@oracle.com> <333E985C-F868-41F9-8B19-A89CE06A59DF@oracle.com> <52949887-B5EB-4131-B3A1-5E7693334302@oracle.com> Message-ID: <44576DF7-9F0F-4AEA-BF9B-89A429E0AE00@oracle.com> I?ve reworked the webrev as requested to make jdk.vm.compiler a non-upgradeable platform module, this allowing it to be mentioned in default.policy: http://cr.openjdk.java.net/~dnsimon/8145337/ -Doug > On 30 Jan 2017, at 22:53, Mandy Chung wrote: > >> >> On Jan 30, 2017, at 1:36 PM, Doug Simon wrote: >> >> >>> On 30 Jan 2017, at 21:55, Mandy Chung wrote: >>> >>> >>>> On Jan 30, 2017, at 10:38 AM, Doug Simon wrote: >>>> >>>> I?ve extended the webrev with that change - please re-review: >>>> >>>> http://cr.openjdk.java.net/~dnsimon/8145337_make/webrev >>>> >>> >>> +1 >> >> Thanks. Is that a ?Reviewed?? >> > > Sorry. I only noticed now that you added this to UPGRADEABLE_MODULE. Please add it only to PLATFORM_MODULES list instead. > > Making it an upgradeable module is a separate issue. I suggest you reopen JDK-8171448. Specifically, since upgradeable modules are not tied with java.base, our goal for JDK 9 is to eliminate qualified exports from JDK modules to upgradeable modules, e.g. JDK-8170116, JDK-8166745, JDK-8161549. > >> I think I should get at least one sign-off from the security team. >> > > Hope Sean will review this one. Please send an updated webrev. > >> Also, since this is effectively making jdk.vm.compiler an upgradeable module, > > No it does not. > >> what?s the implication for it being a hash-checked module? > > When a module M is recorded in the ModuleHashes attribute of java.base, the runtime will check if module M resolved in the graph matches the one tied with java.base when created at build time; if not, it will fail. If an upgradeable module > >> It seems like these changes effectively achieve what I was requesting with https://bugs.openjdk.java.net/browse/JDK-8171448. > > JDK-8145337 is about the security permission. It?s better to separate this review from JDK-8171448. > > Mandy > >> >> -Doug >> >>> >>>> Strangely, there was no existing declaration of jdk.vm.compiler in Modules.gmk. >>>> >>> >>> Default is to be defined by the application class loader. The build will find all modules from the source. There is no need to list all modules. >>> >>>> BTW, I never answered your question: >>>> >>>> "How does JVMCI call out to jdk.vm.compiler? does it load classes using Class::forName with the system class loader?? >>>> >>>> It uses JVMCIServiceLocator[1] which is a mechanism built on the standard ServiceLoader. >>> >>> Thanks for the pointer. That confirms my understanding that loads the service providers using the system class loader. >>> >>> Mandy From doug.simon at oracle.com Wed Feb 1 20:03:50 2017 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 1 Feb 2017 21:03:50 +0100 Subject: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied In-Reply-To: References: <9E737664-1D12-4E3B-B1D6-BED53E581067@oracle.com> <83F83107-EDB1-4C0A-BA6C-493A700A0AFC@oracle.com> <5C71A420-B6F0-43E1-B2F4-6BB230464B35@oracle.com> <503ACAF4-A166-4950-9EF9-38B7093EE6BB@oracle.com> <0B66D3A8-A571-4881-8CDB-81193030FD01@oracle.com> <1ecd3a3e-d7ce-627e-ddb1-48a740a7edc2@oracle.com> <2891BDE5-2009-4A6E-8012-5DAFF9D8DCA0@oracle.com> <5BB17CBF-E3F2-424D-B140-053A0D0E518F@oracle.com> <0125272C-6FAD-45D7-8E2B-C413C38FCF89@oracle.com> <333E985C-F868-41F9-8B19-A89CE06A59DF@oracle.com> <52949887-B5EB-4131-B3A1-5E7693334302@oracle.com> <44576DF7-9F0F-4AEA-BF9B-89A429E0AE00@oracle.com> Message-ID: <3BC2EC38-D0B3-49EC-8BD0-FD72138C9369@oracle.com> > On 1 Feb 2017, at 20:54, Sean Mullan wrote: > > Couple of comments: > > - jdk.vm.ci is already loaded by the boot loader so it is implicitly granted AllPermission and does not need an entry in default.policy. Thanks - I removed it. > - all internal APIs in the jdk.vm.compiler module will now be restricted by default by SecurityManager::checkPackageAccess(), so if you have any code or tests running with a SecurityManager that are accessing internal APIs in the jdk.vm.compiler module, you will need to grant them an appropriate "accessClassInPackage" RuntimePermission in addition to any --add-exports option you are using to break through encapsulation. Vladimir, does the AOT need to run with a SecurityManager and if so, I assume the qualified exports from jdk.vm.compiler to jdk.aot will allow it to run without needed an extra policy file? -Doug > On 2/1/17 6:07 AM, Doug Simon wrote: >> I?ve reworked the webrev as requested to make jdk.vm.compiler a non-upgradeable platform module, this allowing it to be mentioned in default.policy: >> >> http://cr.openjdk.java.net/~dnsimon/8145337/ >> >> -Doug >> >>> On 30 Jan 2017, at 22:53, Mandy Chung wrote: >>> >>>> >>>> On Jan 30, 2017, at 1:36 PM, Doug Simon wrote: >>>> >>>> >>>>> On 30 Jan 2017, at 21:55, Mandy Chung wrote: >>>>> >>>>> >>>>>> On Jan 30, 2017, at 10:38 AM, Doug Simon wrote: >>>>>> >>>>>> I?ve extended the webrev with that change - please re-review: >>>>>> >>>>>> http://cr.openjdk.java.net/~dnsimon/8145337_make/webrev >>>>>> >>>>> >>>>> +1 >>>> >>>> Thanks. Is that a ?Reviewed?? >>>> >>> >>> Sorry. I only noticed now that you added this to UPGRADEABLE_MODULE. Please add it only to PLATFORM_MODULES list instead. >>> >>> Making it an upgradeable module is a separate issue. I suggest you reopen JDK-8171448. Specifically, since upgradeable modules are not tied with java.base, our goal for JDK 9 is to eliminate qualified exports from JDK modules to upgradeable modules, e.g. JDK-8170116, JDK-8166745, JDK-8161549. >>> >>>> I think I should get at least one sign-off from the security team. >>>> >>> >>> Hope Sean will review this one. Please send an updated webrev. >>> >>>> Also, since this is effectively making jdk.vm.compiler an upgradeable module, >>> >>> No it does not. >>> >>>> what?s the implication for it being a hash-checked module? >>> >>> When a module M is recorded in the ModuleHashes attribute of java.base, the runtime will check if module M resolved in the graph matches the one tied with java.base when created at build time; if not, it will fail. If an upgradeable module >>> >>>> It seems like these changes effectively achieve what I was requesting with https://bugs.openjdk.java.net/browse/JDK-8171448. >>> >>> JDK-8145337 is about the security permission. It?s better to separate this review from JDK-8171448. >>> >>> Mandy >>> >>>> >>>> -Doug >>>> >>>>> >>>>>> Strangely, there was no existing declaration of jdk.vm.compiler in Modules.gmk. >>>>>> >>>>> >>>>> Default is to be defined by the application class loader. The build will find all modules from the source. There is no need to list all modules. >>>>> >>>>>> BTW, I never answered your question: >>>>>> >>>>>> "How does JVMCI call out to jdk.vm.compiler? does it load classes using Class::forName with the system class loader?? >>>>>> >>>>>> It uses JVMCIServiceLocator[1] which is a mechanism built on the standard ServiceLoader. >>>>> >>>>> Thanks for the pointer. That confirms my understanding that loads the service providers using the system class loader. >>>>> >>>>> Mandy >> From vladimir.kozlov at oracle.com Wed Feb 1 21:19:50 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 1 Feb 2017 13:19:50 -0800 Subject: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied In-Reply-To: <3BC2EC38-D0B3-49EC-8BD0-FD72138C9369@oracle.com> References: <9E737664-1D12-4E3B-B1D6-BED53E581067@oracle.com> <83F83107-EDB1-4C0A-BA6C-493A700A0AFC@oracle.com> <5C71A420-B6F0-43E1-B2F4-6BB230464B35@oracle.com> <503ACAF4-A166-4950-9EF9-38B7093EE6BB@oracle.com> <0B66D3A8-A571-4881-8CDB-81193030FD01@oracle.com> <1ecd3a3e-d7ce-627e-ddb1-48a740a7edc2@oracle.com> <2891BDE5-2009-4A6E-8012-5DAFF9D8DCA0@oracle.com> <5BB17CBF-E3F2-424D-B140-053A0D0E518F@oracle.com> <0125272C-6FAD-45D7-8E2B-C413C38FCF89@oracle.com> <333E985C-F868-41F9-8B19-A89CE06A59DF@oracle.com> <52949887-B5EB-4131-B3A1-5E7693334302@oracle.com> <44576DF7-9F0F-4AEA-BF9B-89A429E0AE00@oracle.com> <3BC2EC38-D0B3-49EC-8BD0-FD72138C9369@oracle.com> Message-ID: <0FEF3A7E-DD48-4427-A3F2-3DFB985CF83F@oracle.com> AOT tool jaotc does not run with SecurityManager. We assume it runs in secure environment and it does not access any external resources. Thanks Vladimir > On Feb 1, 2017, at 12:03 PM, Doug Simon wrote: > > >> On 1 Feb 2017, at 20:54, Sean Mullan wrote: >> >> Couple of comments: >> >> - jdk.vm.ci is already loaded by the boot loader so it is implicitly granted AllPermission and does not need an entry in default.policy. > > Thanks - I removed it. > >> - all internal APIs in the jdk.vm.compiler module will now be restricted by default by SecurityManager::checkPackageAccess(), so if you have any code or tests running with a SecurityManager that are accessing internal APIs in the jdk.vm.compiler module, you will need to grant them an appropriate "accessClassInPackage" RuntimePermission in addition to any --add-exports option you are using to break through encapsulation. > > Vladimir, does the AOT need to run with a SecurityManager and if so, I assume the qualified exports from jdk.vm.compiler to jdk.aot will allow it to run without needed an extra policy file? > > -Doug > >>> On 2/1/17 6:07 AM, Doug Simon wrote: >>> I?ve reworked the webrev as requested to make jdk.vm.compiler a non-upgradeable platform module, this allowing it to be mentioned in default.policy: >>> >>> http://cr.openjdk.java.net/~dnsimon/8145337/ >>> >>> -Doug >>> >>>>> On 30 Jan 2017, at 22:53, Mandy Chung wrote: >>>>> >>>>> >>>>> On Jan 30, 2017, at 1:36 PM, Doug Simon wrote: >>>>> >>>>> >>>>>> On 30 Jan 2017, at 21:55, Mandy Chung wrote: >>>>>> >>>>>> >>>>>>> On Jan 30, 2017, at 10:38 AM, Doug Simon wrote: >>>>>>> >>>>>>> I?ve extended the webrev with that change - please re-review: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dnsimon/8145337_make/webrev >>>>>>> >>>>>> >>>>>> +1 >>>>> >>>>> Thanks. Is that a ?Reviewed?? >>>>> >>>> >>>> Sorry. I only noticed now that you added this to UPGRADEABLE_MODULE. Please add it only to PLATFORM_MODULES list instead. >>>> >>>> Making it an upgradeable module is a separate issue. I suggest you reopen JDK-8171448. Specifically, since upgradeable modules are not tied with java.base, our goal for JDK 9 is to eliminate qualified exports from JDK modules to upgradeable modules, e.g. JDK-8170116, JDK-8166745, JDK-8161549. >>>> >>>>> I think I should get at least one sign-off from the security team. >>>>> >>>> >>>> Hope Sean will review this one. Please send an updated webrev. >>>> >>>>> Also, since this is effectively making jdk.vm.compiler an upgradeable module, >>>> >>>> No it does not. >>>> >>>>> what?s the implication for it being a hash-checked module? >>>> >>>> When a module M is recorded in the ModuleHashes attribute of java.base, the runtime will check if module M resolved in the graph matches the one tied with java.base when created at build time; if not, it will fail. If an upgradeable module >>>> >>>>> It seems like these changes effectively achieve what I was requesting with https://bugs.openjdk.java.net/browse/JDK-8171448. >>>> >>>> JDK-8145337 is about the security permission. It?s better to separate this review from JDK-8171448. >>>> >>>> Mandy >>>> >>>>> >>>>> -Doug >>>>> >>>>>> >>>>>>> Strangely, there was no existing declaration of jdk.vm.compiler in Modules.gmk. >>>>>>> >>>>>> >>>>>> Default is to be defined by the application class loader. The build will find all modules from the source. There is no need to list all modules. >>>>>> >>>>>>> BTW, I never answered your question: >>>>>>> >>>>>>> "How does JVMCI call out to jdk.vm.compiler? does it load classes using Class::forName with the system class loader?? >>>>>>> >>>>>>> It uses JVMCIServiceLocator[1] which is a mechanism built on the standard ServiceLoader. >>>>>> >>>>>> Thanks for the pointer. That confirms my understanding that loads the service providers using the system class loader. >>>>>> >>>>>> Mandy >>> > From doug.simon at oracle.com Wed Feb 1 21:27:47 2017 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 1 Feb 2017 22:27:47 +0100 Subject: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied In-Reply-To: <0FEF3A7E-DD48-4427-A3F2-3DFB985CF83F@oracle.com> References: <9E737664-1D12-4E3B-B1D6-BED53E581067@oracle.com> <83F83107-EDB1-4C0A-BA6C-493A700A0AFC@oracle.com> <5C71A420-B6F0-43E1-B2F4-6BB230464B35@oracle.com> <503ACAF4-A166-4950-9EF9-38B7093EE6BB@oracle.com> <0B66D3A8-A571-4881-8CDB-81193030FD01@oracle.com> <1ecd3a3e-d7ce-627e-ddb1-48a740a7edc2@oracle.com> <2891BDE5-2009-4A6E-8012-5DAFF9D8DCA0@oracle.com> <5BB17CBF-E3F2-424D-B140-053A0D0E518F@oracle.com> <0125272C-6FAD-45D7-8E2B-C413C38FCF89@oracle.com> <333E985C-F868-41F9-8B19-A89CE06A59DF@oracle.com> <52949887-B5EB-4131-B3A1-5E7693334302@oracle.com> <44576DF7-9F0F-4AEA-BF9B-89A429E0AE00@oracle.com> <3BC2EC38-D0B3-49EC-8BD0-FD72138C9369@oracle.com> <0FEF3A7E-DD48-4427-A3F2-3DFB985CF83F@oracle.com> Message-ID: > On 1 Feb 2017, at 22:19, Vladimir Kozlov wrote: > > AOT tool jaotc does not run with SecurityManager. We assume it runs in secure environment and it does not access any external resources. Great. Can I now consider this change reviewed and integrate it? -Doug >> On Feb 1, 2017, at 12:03 PM, Doug Simon wrote: >> >> >>> On 1 Feb 2017, at 20:54, Sean Mullan wrote: >>> >>> Couple of comments: >>> >>> - jdk.vm.ci is already loaded by the boot loader so it is implicitly granted AllPermission and does not need an entry in default.policy. >> >> Thanks - I removed it. >> >>> - all internal APIs in the jdk.vm.compiler module will now be restricted by default by SecurityManager::checkPackageAccess(), so if you have any code or tests running with a SecurityManager that are accessing internal APIs in the jdk.vm.compiler module, you will need to grant them an appropriate "accessClassInPackage" RuntimePermission in addition to any --add-exports option you are using to break through encapsulation. >> >> Vladimir, does the AOT need to run with a SecurityManager and if so, I assume the qualified exports from jdk.vm.compiler to jdk.aot will allow it to run without needed an extra policy file? >> >> -Doug >> >>>> On 2/1/17 6:07 AM, Doug Simon wrote: >>>> I?ve reworked the webrev as requested to make jdk.vm.compiler a non-upgradeable platform module, this allowing it to be mentioned in default.policy: >>>> >>>> http://cr.openjdk.java.net/~dnsimon/8145337/ >>>> >>>> -Doug >>>> >>>>>> On 30 Jan 2017, at 22:53, Mandy Chung wrote: >>>>>> >>>>>> >>>>>> On Jan 30, 2017, at 1:36 PM, Doug Simon wrote: >>>>>> >>>>>> >>>>>>> On 30 Jan 2017, at 21:55, Mandy Chung wrote: >>>>>>> >>>>>>> >>>>>>>> On Jan 30, 2017, at 10:38 AM, Doug Simon wrote: >>>>>>>> >>>>>>>> I?ve extended the webrev with that change - please re-review: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dnsimon/8145337_make/webrev >>>>>>>> >>>>>>> >>>>>>> +1 >>>>>> >>>>>> Thanks. Is that a ?Reviewed?? >>>>>> >>>>> >>>>> Sorry. I only noticed now that you added this to UPGRADEABLE_MODULE. Please add it only to PLATFORM_MODULES list instead. >>>>> >>>>> Making it an upgradeable module is a separate issue. I suggest you reopen JDK-8171448. Specifically, since upgradeable modules are not tied with java.base, our goal for JDK 9 is to eliminate qualified exports from JDK modules to upgradeable modules, e.g. JDK-8170116, JDK-8166745, JDK-8161549. >>>>> >>>>>> I think I should get at least one sign-off from the security team. >>>>>> >>>>> >>>>> Hope Sean will review this one. Please send an updated webrev. >>>>> >>>>>> Also, since this is effectively making jdk.vm.compiler an upgradeable module, >>>>> >>>>> No it does not. >>>>> >>>>>> what?s the implication for it being a hash-checked module? >>>>> >>>>> When a module M is recorded in the ModuleHashes attribute of java.base, the runtime will check if module M resolved in the graph matches the one tied with java.base when created at build time; if not, it will fail. If an upgradeable module >>>>> >>>>>> It seems like these changes effectively achieve what I was requesting with https://bugs.openjdk.java.net/browse/JDK-8171448. >>>>> >>>>> JDK-8145337 is about the security permission. It?s better to separate this review from JDK-8171448. >>>>> >>>>> Mandy >>>>> >>>>>> >>>>>> -Doug >>>>>> >>>>>>> >>>>>>>> Strangely, there was no existing declaration of jdk.vm.compiler in Modules.gmk. >>>>>>>> >>>>>>> >>>>>>> Default is to be defined by the application class loader. The build will find all modules from the source. There is no need to list all modules. >>>>>>> >>>>>>>> BTW, I never answered your question: >>>>>>>> >>>>>>>> "How does JVMCI call out to jdk.vm.compiler? does it load classes using Class::forName with the system class loader?? >>>>>>>> >>>>>>>> It uses JVMCIServiceLocator[1] which is a mechanism built on the standard ServiceLoader. >>>>>>> >>>>>>> Thanks for the pointer. That confirms my understanding that loads the service providers using the system class loader. >>>>>>> >>>>>>> Mandy >>>> >> > From nipa at codefx.org Thu Feb 2 10:59:53 2017 From: nipa at codefx.org (Nicolai Parlog) Date: Thu, 2 Feb 2017 11:59:53 +0100 Subject: -Xlog and the module system In-Reply-To: References: <7c4c1751-17b9-6c4c-df62-162056fc0688@codefx.org> <03fac1c7-cc49-23f5-49ab-1bfac418e1ec@codefx.org> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Alan. > The trace messages emitted by -Xdiag:resolver are printed as the > resolver runs. I'm sorry for being such a noob but my Google Foo failed at telling me how to turn trace on for -Xdiag. :( Can you help me out? so long ... Nicolai On 02.02.2017 09:07, Alan Bateman wrote: > On 01/02/2017 21:49, Nicolai Parlog wrote: > >> Hi Alan, >> >> `-Xdiag:resolver` is awesome! :) I think these messages are >> great candidates for info-level messages with the "modules" tag >> via unified logging. > I agree it should be transparent to developers using the JDK as to > whether the implementation is in libjvm or else where, something > that will likely more of an issue going forward when more of the > run time is written in the Java Language. > >> >> Something else I noticed, neither Xlog nor Xdiag help with >> problematic configurations - both only start logging after >> everything checked out, so with missing modules (for example), >> they do not provide additional information. > The trace messages emitted by -Xdiag:resolver are printed as the > resolver runs. So aside from the initial module then they would see > some output when transitive dependences can't be found. > > -Alan > - -- PGP Key: http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509 Web: http://codefx.org a blog about software development https://www.sitepoint.com/java high-quality Java/JVM content http://do-foss.de Free and Open Source Software for the City of Dortmund Twitter: https://twitter.com/nipafx -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJYkxEpAAoJEMo7rS6czNUJcDMP/jxplSA7wD957SM1UWhbJ3Bq qcD6Zy/k4LWkQ3xkRhE8MYU9lHWnRpKSAJ9tn6hVx2xhNxyM26VwKr9mg6enrXNc xJn6UgokC6ypjQZWR7fCd4mibPFUujc2RCptph//UpUx8FcGDRvGbEt3l9LGL4JH tuJrtRc06RqQpa2zvIf6nwFV3XMO8N0bXag+vAFMWfLVWReSBO5yYx9NxeE4BEto H0fqGaSFLUGQ55YRqST5d5i9vcgX4CyCW8PzraPTjQq7Y92YgY4HCHLdFwrbtjp2 uX77CbrmZcXZI81Q0Z5F83WHEaiox+2xz2hazFRzyT+OGvnjBco+CdpMZ7LLL7ZY 4mZzRfDrlWXbwEsUkxzvPiO1Bkk9mjRQ7I15J2PjqgYHgNgnFwuU1txUwwN46VaH YZ18/oa74a90yiikARYBFi9RhkihCLFjMmWFAWJaZ8MHhR1kqQmU1warKXrqk6ui WW4ypATOvBAl+Fn/STDU+U41vxZIBpPC6Q1V8KuRDF49HY7K5bGqdOK0MXrYWc/P o7E5tEvVIUG/wljxZVDvtECidGEYf+Sz7NqLk+vbUT5Ckng1A7xuqBd1ycEZnoKy Fvib7x49TXC9aKorJ2bEHS6YPenEzOCybthtB/I1AwibVUEulcmJ3erndFjHuwPv q0Hq+U6ddlAy6Ivp8Lkf =pXtb -----END PGP SIGNATURE----- From nipa at codefx.org Thu Feb 2 11:28:13 2017 From: nipa at codefx.org (Nicolai Parlog) Date: Thu, 2 Feb 2017 12:28:13 +0100 Subject: Automatic module names In-Reply-To: References: Message-ID: <55f73bef-657f-8669-4969-0830d5119b72@codefx.org> Hi everyone, after thinking about this a little longer, I came to the conclusion that compile-time/launch-time aliasing might be the only way out of this (at least the only I could come up with) that keeps automatic modules alive and does not introduce a conceptual dependency on Maven. The idea: A command line option, let's say `--alias-modules A=X`, maps module name A to module name X. Every dependency on either A or X will be resolved to X, implying that there must a module X in the universe of observable modules. There can be several aliases for the same module (`--alias-modules A=X,B=X`; X needs to be observable) and they can be chained (`--alias-modules A=X,X=Y`; Y needs to be observable) Aliasing would of course have to be applied to qualified exports, opens, and similar mechanisms as well. It might be worth adding the rule that no observable module must have an aliased name. So for `--alias-modules A=X` there must be no observable module A. This prevents ambiguity and would effectively prevent aliasing platform modules. That might be a good thing because it looks like aliasing and upgrading modules has quite some overlap (or is even identical?) Unfortunately I could not come up with a way to limit aliasing to automatic module names (in case that were desirable) without somehow marking dependencies on automatic modules, likely in the module declaration. If changing module declaration syntax is still on the table, it could be changed so that dependencies on automatic modules must be phrased as something like `requires automatic`. The obvious semantics would be that only such requires clauses can be fulfilled with automatic modules and that only such dependencies could be aliased (this might make it prudent to phrase the aliasing option accordingly, e.g. `--alias-automatic-modules`). This could also be used to help developers in keeping their module declarations clean: The compiler could to emit a warning if a `requires automatic` clause is fulfilled by a regular module. I would love to hear some thoughts on this idea, even if it considered to be stupid, impractical,etc. :) so long ... Nicolai On 27.01.2017 15:11, Stephen Colebourne wrote: > Back in October, I raised the issue of modules names generally and for > automatic modules specifically [1]. The short thread came to no > conclusion, but recent threads have again raised similar problems. The > problem is that automatic modules have magical name creation from a > filename, which is brittle and unlike anything else in Java. > > I also recently looked at the Joda-Convert and Joda-Beans libraries, > to see if I could add module-info in preparation for Java 9. I quickly > backed away, again because of the same issue. Put simply, I am > unwilling to write a module-info file that refers to a dependency that > is not yet a module. And I have to advise all open source projects to > do the same. Given this, there can be no simple migration to the JPMS > for open source projects. Each open source project must wait for all > its dependencies to migrate to JPMS (by adding a module-info and > publishing to Maven Central). > > The issue is clear. If I write this: > > module org.joda.convert { > requires guava; > } > > where guava is an automatic module, I am locking in the name of the > guava dependency, something that I do not control. The name "guava" is > just a guess. The guava authors might choose "com.google.guava" or > something else entirely. > > In a closed system of modules, ie. a private application, automatic > modules are fine, because the requires clause can be changed if it > turns out the guess was wrong. But once published as an open source > project to Maven Central or elsewhere, the guess cannot be fixed if it > is wrong (without releasing a new version of the library, which is not > an acceptable solution). > > I also strongly believe that module names cannot be flat and > unstructured, such as "joda-convert" or "guava". They must have > structure, such as the domain name or a Maven-style group name > "org.joda.convert" or "org.joda:joda-convert". The potential for > clashes has been shown by the Maven team [2]. > > Some brainstormed possible changes: > > - Remove the automatic module concept altogether > > - Define a clear mapping from Maven Central co-ordinates to module > name that includes the group, artifact and classifier > > - Provide a text file to JPMS that allows incorrect module names to be > mapped to the correct name > > - Publicly advise against using automatic modules for open source projects > > - Change rules of Maven Central to prevent modular jars being added > that depend on an automatic module > > - Allow requires clauses to have aliases - requires org.guava.guava OR guava. > > - Allow modules to have aliases - module org.guava.guava AKA guava > > > Given that applications can depend on libraries that haven't been > released in years, this has the potential to be a critical problem for > the ecosystem. My preference remains to define a clear mapping from > the widely adopted Maven Central naming strategy to JPMS modules. > Ideally, this would be a formal group concept in the JPMS, something > that I believe is sorely lacking. > > Stephen > > [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-October/009631.html > [2] http://mail.openjdk.java.net/pipermail/jpms-spec-observers/2017-January/000707.html > -- PGP Key: http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509 Web: http://codefx.org a blog about software development https://www.sitepoint.com/java high-quality Java/JVM content http://do-foss.de Free and Open Source Software for the City of Dortmund Twitter: https://twitter.com/nipafx From david.holmes at oracle.com Thu Feb 2 12:11:58 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 2 Feb 2017 22:11:58 +1000 Subject: -Xlog and the module system In-Reply-To: References: <7c4c1751-17b9-6c4c-df62-162056fc0688@codefx.org> <03fac1c7-cc49-23f5-49ab-1bfac418e1ec@codefx.org> Message-ID: <6327655f-1cb9-9b5c-3a2f-57d57e648dfd@oracle.com> On 2/02/2017 8:59 PM, Nicolai Parlog wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hi Alan. > >> The trace messages emitted by -Xdiag:resolver are printed as the >> resolver runs. > > I'm sorry for being such a noob but my Google Foo failed at telling me > how to turn trace on for -Xdiag. :( Can you help me out? java -Xdiag ... will enable tracing for general launcher "diagnostics" as well as the resolver. java -Xdiag:resolver ... will only enable tracing for the resolver. David > so long ... Nicolai > > > > On 02.02.2017 09:07, Alan Bateman wrote: >> On 01/02/2017 21:49, Nicolai Parlog wrote: >> >>> Hi Alan, >>> >>> `-Xdiag:resolver` is awesome! :) I think these messages are >>> great candidates for info-level messages with the "modules" tag >>> via unified logging. >> I agree it should be transparent to developers using the JDK as to >> whether the implementation is in libjvm or else where, something >> that will likely more of an issue going forward when more of the >> run time is written in the Java Language. >> >>> >>> Something else I noticed, neither Xlog nor Xdiag help with >>> problematic configurations - both only start logging after >>> everything checked out, so with missing modules (for example), >>> they do not provide additional information. >> The trace messages emitted by -Xdiag:resolver are printed as the >> resolver runs. So aside from the initial module then they would see >> some output when transitive dependences can't be found. >> >> -Alan >> > > - -- > > PGP Key: > http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509 > > Web: > http://codefx.org > a blog about software development > https://www.sitepoint.com/java > high-quality Java/JVM content > http://do-foss.de > Free and Open Source Software for the City of Dortmund > > Twitter: > https://twitter.com/nipafx > -----BEGIN PGP SIGNATURE----- > > iQIcBAEBCAAGBQJYkxEpAAoJEMo7rS6czNUJcDMP/jxplSA7wD957SM1UWhbJ3Bq > qcD6Zy/k4LWkQ3xkRhE8MYU9lHWnRpKSAJ9tn6hVx2xhNxyM26VwKr9mg6enrXNc > xJn6UgokC6ypjQZWR7fCd4mibPFUujc2RCptph//UpUx8FcGDRvGbEt3l9LGL4JH > tuJrtRc06RqQpa2zvIf6nwFV3XMO8N0bXag+vAFMWfLVWReSBO5yYx9NxeE4BEto > H0fqGaSFLUGQ55YRqST5d5i9vcgX4CyCW8PzraPTjQq7Y92YgY4HCHLdFwrbtjp2 > uX77CbrmZcXZI81Q0Z5F83WHEaiox+2xz2hazFRzyT+OGvnjBco+CdpMZ7LLL7ZY > 4mZzRfDrlWXbwEsUkxzvPiO1Bkk9mjRQ7I15J2PjqgYHgNgnFwuU1txUwwN46VaH > YZ18/oa74a90yiikARYBFi9RhkihCLFjMmWFAWJaZ8MHhR1kqQmU1warKXrqk6ui > WW4ypATOvBAl+Fn/STDU+U41vxZIBpPC6Q1V8KuRDF49HY7K5bGqdOK0MXrYWc/P > o7E5tEvVIUG/wljxZVDvtECidGEYf+Sz7NqLk+vbUT5Ckng1A7xuqBd1ycEZnoKy > Fvib7x49TXC9aKorJ2bEHS6YPenEzOCybthtB/I1AwibVUEulcmJ3erndFjHuwPv > q0Hq+U6ddlAy6Ivp8Lkf > =pXtb > -----END PGP SIGNATURE----- > From alan.bateman at oracle.com Thu Feb 2 17:04:42 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 02 Feb 2017 17:04:42 +0000 Subject: hg: jigsaw/jake/langtools: Correct values for ACC_TRANSITIVE/ACC_STATIC_PHASE Message-ID: <201702021704.v12H4gcr001667@aojmv0008.oracle.com> Changeset: 9982dbd88459 Author: alanb Date: 2017-02-02 16:26 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/9982dbd88459 Correct values for ACC_TRANSITIVE/ACC_STATIC_PHASE ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Directive.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/Module_attribute.java From alan.bateman at oracle.com Thu Feb 2 17:04:56 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 02 Feb 2017 17:04:56 +0000 Subject: hg: jigsaw/jake/jdk: 4 new changesets Message-ID: <201702021704.v12H4ufu001739@aojmv0008.oracle.com> Changeset: 85331a665469 Author: alanb Date: 2017-02-02 16:28 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/85331a665469 Correct values for ACC_TRANSITIVE/ACC_STATIC_PHASE ! src/java.base/share/classes/jdk/internal/module/ClassFileConstants.java Changeset: e26e4e89d174 Author: alanb Date: 2017-02-02 16:30 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e26e4e89d174 Remove size of packageToModule on minimal image Contributed-by: claes.redestad at oracle.com ! src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java Changeset: ecce824c6a64 Author: alanb Date: 2017-02-02 17:02 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ecce824c6a64 Lookup.UNCONDITIONAL ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/sun/invoke/util/VerifyAccess.java ! test/java/lang/invoke/AccessControlTest.java ! test/java/lang/invoke/DropLookupModeTest.java + test/java/lang/invoke/modules/Driver.java - test/java/lang/invoke/modules/ModuleAccessControlTest.java + test/java/lang/invoke/modules/Unnamed.java + test/java/lang/invoke/modules/m1/module-info.java + test/java/lang/invoke/modules/m1/p1/Main.java + test/java/lang/invoke/modules/m1/p1/Type1.java + test/java/lang/invoke/modules/m1/p2/Type2.java + test/java/lang/invoke/modules/m2/module-info.java + test/java/lang/invoke/modules/m2/q1/Type1.java + test/java/lang/invoke/modules/m2/q2/Type2.java - test/java/lang/invoke/modules/src/m1/module-info.java - test/java/lang/invoke/modules/src/m1/p1/Main.java - test/java/lang/invoke/modules/src/m1/p1/Type1.java - test/java/lang/invoke/modules/src/m1/p2/Type2.java - test/java/lang/invoke/modules/src/m2/module-info.java - test/java/lang/invoke/modules/src/m2/q1/Type1.java - test/java/lang/invoke/modules/src/m2/q2/Type2.java Changeset: 816c5fec6198 Author: alanb Date: 2017-02-02 17:02 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/816c5fec6198 tools/launcher/modules/patch/systemmodules/PatchSystemModules.java failing ! test/tools/launcher/modules/patch/systemmodules/src1/java.base/jdk/internal/modules/SystemModules.java From nipa at codefx.org Thu Feb 2 21:27:11 2017 From: nipa at codefx.org (Nicolai Parlog) Date: Thu, 2 Feb 2017 22:27:11 +0100 Subject: -Xlog and the module system In-Reply-To: <6327655f-1cb9-9b5c-3a2f-57d57e648dfd@oracle.com> References: <7c4c1751-17b9-6c4c-df62-162056fc0688@codefx.org> <03fac1c7-cc49-23f5-49ab-1bfac418e1ec@codefx.org> <6327655f-1cb9-9b5c-3a2f-57d57e648dfd@oracle.com> Message-ID: Hi! What the *$%& did I try then? I did that of course and thought I did not see any messages in cases where the configuration was faulty. Under the assumption that Xdiag's log level was too high, I went looking for a way to set it to trace - without success. But whatever I did that lead me to the conclusion that -Xdiag did not print any messages was utterly wrong. java9 -p mods/ -Xdiag:resolver -m org.codefx.demo.advent [Resolver] Root module org.codefx.demo.advent located [Resolver] Module java.base located, required by org.codefx.demo.advent [Resolver] Module org.codefx.demo.advent.calendar located, required by org.codefx.demo.advent Error occurred during initialization of VM java.lang.module.ResolutionException: Module org.codefx.demo.advent.surprise not found, required by org.codefx.demo.advent.calendar Everything in order... Thanks for helping a noob :) so long ... Nicolai On 02.02.2017 13:11, David Holmes wrote: > On 2/02/2017 8:59 PM, Nicolai Parlog wrote: > Hi Alan. > >>>> The trace messages emitted by -Xdiag:resolver are printed as the >>>> resolver runs. > > I'm sorry for being such a noob but my Google Foo failed at telling me > how to turn trace on for -Xdiag. :( Can you help me out? > >> java -Xdiag ... > >> will enable tracing for general launcher "diagnostics" as well as the >> resolver. > >> java -Xdiag:resolver ... > >> will only enable tracing for the resolver. > >> David > > so long ... Nicolai > > > > On 02.02.2017 09:07, Alan Bateman wrote: >>>> On 01/02/2017 21:49, Nicolai Parlog wrote: >>>> >>>>> Hi Alan, >>>>> >>>>> `-Xdiag:resolver` is awesome! :) I think these messages are >>>>> great candidates for info-level messages with the "modules" tag >>>>> via unified logging. >>>> I agree it should be transparent to developers using the JDK as to >>>> whether the implementation is in libjvm or else where, something >>>> that will likely more of an issue going forward when more of the >>>> run time is written in the Java Language. >>>> >>>>> >>>>> Something else I noticed, neither Xlog nor Xdiag help with >>>>> problematic configurations - both only start logging after >>>>> everything checked out, so with missing modules (for example), >>>>> they do not provide additional information. >>>> The trace messages emitted by -Xdiag:resolver are printed as the >>>> resolver runs. So aside from the initial module then they would see >>>> some output when transitive dependences can't be found. >>>> >>>> -Alan >>>> > >> > -- PGP Key: http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509 Web: http://codefx.org a blog about software development https://www.sitepoint.com/java high-quality Java/JVM content http://do-foss.de Free and Open Source Software for the City of Dortmund Twitter: https://twitter.com/nipafx From alan.bateman at oracle.com Fri Feb 3 09:36:43 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 03 Feb 2017 09:36:43 +0000 Subject: hg: jigsaw/jake: 6 new changesets Message-ID: <201702030936.v139aiPv018318@aojmv0008.oracle.com> Changeset: 33169b3b9542 Author: chegar Date: 2017-01-25 14:10 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/33169b3b9542 8173354: javadoc warning notice for types in Incubator Modules Reviewed-by: erikj, michaelm ! make/Javadoc.gmk Changeset: c7e03e50dd5c Author: lana Date: 2017-01-26 21:20 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/c7e03e50dd5c Merge Changeset: b88023f46daa Author: erikj Date: 2017-01-27 10:15 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/b88023f46daa 8170483: Remove modules_src_jake workaround for JavaFX transition to new module-info syntax Reviewed-by: alanb, mchung ! common/autoconf/generated-configure.sh ! common/autoconf/source-dirs.m4 ! make/common/Modules.gmk Changeset: 688a3863c00e Author: erikj Date: 2017-01-27 16:50 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/688a3863c00e 8173476: Provide lldb from devkit when running tests on macosx Reviewed-by: ihse, tbell ! common/conf/jib-profiles.js Changeset: e338abeb33a3 Author: lana Date: 2017-02-02 21:20 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/e338abeb33a3 Added tag jdk-9+155 for changeset 688a3863c00e ! .hgtags Changeset: 7ad5324ee5a7 Author: alanb Date: 2017-02-03 09:34 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/7ad5324ee5a7 Merge ! .hgtags ! common/autoconf/generated-configure.sh ! common/autoconf/source-dirs.m4 ! common/conf/jib-profiles.js ! make/Javadoc.gmk ! make/common/Modules.gmk From alan.bateman at oracle.com Fri Feb 3 09:36:44 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 03 Feb 2017 09:36:44 +0000 Subject: hg: jigsaw/jake/corba: 5 new changesets Message-ID: <201702030936.v139aiSK018356@aojmv0008.oracle.com> Changeset: b33379591dea Author: coffeys Date: 2017-01-25 12:09 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/b33379591dea 8077395: org.omg.CORBA_2_3.portable.InputStream constructor should not specify JDK-specific property Reviewed-by: lancea, rriggs ! src/java.corba/share/classes/org/omg/CORBA_2_3/portable/InputStream.java ! src/java.corba/share/classes/org/omg/CORBA_2_3/portable/OutputStream.java Changeset: 16e84753114b Author: lana Date: 2017-01-26 21:20 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/16e84753114b Merge Changeset: a545f54babfa Author: prappo Date: 2017-01-27 16:28 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/a545f54babfa 8170116: Remove qualified exports from java.base to java.corba Reviewed-by: dfuchs, alanb, mchung Contributed-by: Chris Hegarty , Daniel Fuchs ! src/java.corba/share/classes/com/sun/corba/se/spi/orb/ORB.java ! src/java.corba/share/classes/org/omg/CORBA/ORB.java ! src/java.corba/share/classes/sun/corba/Bridge.java Changeset: 907c26240cd4 Author: lana Date: 2017-02-02 21:20 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/907c26240cd4 Added tag jdk-9+155 for changeset a545f54babfa ! .hgtags Changeset: 3189e56cc290 Author: alanb Date: 2017-02-03 09:34 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/3189e56cc290 Merge ! .hgtags ! src/java.corba/share/classes/org/omg/CORBA/ORB.java ! src/java.corba/share/classes/sun/corba/Bridge.java From alan.bateman at oracle.com Fri Feb 3 09:36:47 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 03 Feb 2017 09:36:47 +0000 Subject: hg: jigsaw/jake/jaxp: 6 new changesets Message-ID: <201702030936.v139alBo018430@aojmv0008.oracle.com> Changeset: 620d0c38581f Author: clanger Date: 2017-01-24 11:10 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/620d0c38581f 8173261: JAXP: TESTBUG: javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh Reviewed-by: dfuchs, fyuan ! test/ProblemList.txt ! test/javax/xml/jaxp/isolatedjdk/IsolatedJDK.sh ! test/javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.java - test/javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh ! test/javax/xml/jaxp/libs/catalog/CatalogTestUtils.java ! test/javax/xml/jaxp/libs/jaxp/library/JAXPTestUtilities.java Changeset: 2d7bf6955c05 Author: dfuchs Date: 2017-01-24 16:34 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/2d7bf6955c05 8173111: Excessive recursion in EventFilterSupport when filtering over large number of XML events can cause StackOverflow Summary: This fix replaces un unwanted recursion in the XML streams event filtering support by a simple loop (in nextEvent/nextTag). Reviewed-by: aefimov, clanger, lancea, rriggs ! src/java.xml/share/classes/com/sun/xml/internal/stream/EventFilterSupport.java + test/javax/xml/jaxp/unittest/stream/EventsTest/EventFilterSupportTest.java Changeset: b7bd7cac2790 Author: lana Date: 2017-01-26 21:20 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/b7bd7cac2790 Merge - test/javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh Changeset: 48fa77af1532 Author: dfuchs Date: 2017-01-27 20:33 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/48fa77af1532 8173260: CatalogManager.catalogResolver should not fail when non-existing URI is passed to it Summary: removed the code that special cased file and jar and threw IAE if the file did not exist. Reviewed-by: alanb, lancea ! src/java.xml/share/classes/javax/xml/catalog/Util.java ! test/javax/xml/jaxp/unittest/catalog/CatalogFileInputTest.java Changeset: 7d5ef01b8123 Author: lana Date: 2017-02-02 21:20 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/7d5ef01b8123 Added tag jdk-9+155 for changeset 48fa77af1532 ! .hgtags Changeset: 1c9babc54cd7 Author: alanb Date: 2017-02-03 09:34 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/1c9babc54cd7 Merge ! .hgtags - test/javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh From alan.bateman at oracle.com Fri Feb 3 09:36:47 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 03 Feb 2017 09:36:47 +0000 Subject: hg: jigsaw/jake/nashorn: 7 new changesets Message-ID: <201702030936.v139alao018439@aojmv0008.oracle.com> Changeset: 9aa94f11a8b9 Author: sundar Date: 2017-01-24 18:08 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/9aa94f11a8b9 8173257: test/script/trusted/JDK-8021189.js and test/script/trusted/JDK-8021129.js fail in nashorn nightly Reviewed-by: hannesw, jlaskey ! make/build.xml ! make/project.properties Changeset: c1792836521e Author: hannesw Date: 2017-01-25 09:49 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/c1792836521e 8166186: ClassCastException with arguments usage Reviewed-by: attila, sundar ! README ! src/jdk.dynalink/share/classes/jdk/dynalink/linker/GuardedInvocation.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/linker/NashornLinkerExporter.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptFunction.java + test/script/basic/JDK-8166186.js + test/script/basic/JDK-8166186.js.EXPECTED Changeset: 8e7ef537aa54 Author: hannesw Date: 2017-01-26 12:58 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/8e7ef537aa54 8172006: Nashorn JavaScript engine fails to call @FunctionalInterface with a java.util.List argument Reviewed-by: attila, jlaskey ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornBeansLinker.java + test/script/basic/JDK-8172006.js + test/src/jdk/nashorn/test/models/FunctionalInterfaceProvider.java Changeset: 6f5bf136f6c9 Author: lana Date: 2017-01-26 21:20 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/6f5bf136f6c9 Merge Changeset: f9bb37a817b3 Author: hannesw Date: 2017-01-31 10:48 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/f9bb37a817b3 8173480: in operator should work on java objects and classes Reviewed-by: jlaskey, sundar ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptRuntime.java + test/script/basic/JDK-8173480.js Changeset: 344778c020a0 Author: lana Date: 2017-02-02 21:20 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/344778c020a0 Added tag jdk-9+155 for changeset f9bb37a817b3 ! .hgtags Changeset: 02f267732424 Author: alanb Date: 2017-02-03 09:34 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/02f267732424 Merge ! .hgtags ! make/build.xml ! make/project.properties From alan.bateman at oracle.com Fri Feb 3 09:36:48 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 03 Feb 2017 09:36:48 +0000 Subject: hg: jigsaw/jake/jaxws: 2 new changesets Message-ID: <201702030936.v139amtj018445@aojmv0008.oracle.com> Changeset: 83c33cc9f158 Author: lana Date: 2017-02-02 21:20 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/83c33cc9f158 Added tag jdk-9+155 for changeset 9b9918656c97 ! .hgtags Changeset: 9af8d95119b5 Author: alanb Date: 2017-02-03 09:34 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/9af8d95119b5 Merge ! .hgtags From alan.bateman at oracle.com Fri Feb 3 09:36:50 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 03 Feb 2017 09:36:50 +0000 Subject: hg: jigsaw/jake/langtools: 17 new changesets Message-ID: <201702030936.v139aoKn018509@aojmv0008.oracle.com> Changeset: 17a11ffc6a0a Author: jlahoda Date: 2017-01-24 13:29 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/17a11ffc6a0a 8153759: jshell tool: Smart completion detection is not reliable Summary: Reverting back to smart completion if any action follows a completion action. Reviewed-by: rfield ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java Changeset: 3df160c5f83a Author: jjg Date: 2017-01-24 16:18 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/3df160c5f83a 8051768: Inconsistent output for Visible and InvisibleParameterAnnotations Reviewed-by: jjg Contributed-by: istomin.den at gmail.com ! src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java + test/tools/javap/typeAnnotations/InvisibleParameterAnnotationsTest.java Changeset: c2dfa170f6f0 Author: jjg Date: 2017-01-24 17:36 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/c2dfa170f6f0 8041793: javap misses newline after printing AnnotationDefault Reviewed-by: jjg Contributed-by: istomin.den at gmail.com ! src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java + test/tools/javap/typeAnnotations/AnnotationDefaultNewlineTest.java Changeset: edd091e7a9a3 Author: rfield Date: 2017-01-25 10:22 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/edd091e7a9a3 8173232: JShell tests: ReplaceTest takes too long 8173234: JShell tests: remove from ProblemList jdk/jshell/ToolFormatTest.java 8173204: JShell tests: ProblemList jdk/jshell/UserJdiUserRemoteTest.java Reviewed-by: jlahoda ! test/ProblemList.txt + test/jdk/jshell/ForwardReferenceImportTest.java + test/jdk/jshell/ForwardReferenceTest.java ! test/jdk/jshell/ReplaceTest.java Changeset: 919a15cb34bb Author: rfield Date: 2017-01-25 10:43 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/919a15cb34bb 8171343: jshell tool: missing options: --help-extra --show-version Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties ! test/jdk/jshell/StartOptionTest.java ! test/jdk/jshell/ToolProviderTest.java Changeset: 3fdaf9e50f5c Author: jlahoda Date: 2017-01-26 14:11 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/3fdaf9e50f5c 8067747: javac throws exception during compilation when annotation processing is enabled Summary: Enforcing Filer rules regarding initial inputs, to avoid downstream problems. Reviewed-by: darcy, jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacFiler.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java + test/tools/javac/processing/OverwriteInitialInput.java Changeset: 923a093b4bd8 Author: jlahoda Date: 2017-01-26 14:14 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/923a093b4bd8 8173068: ElementUtils getPackageElement does not allow for an unnamed package Summary: Removing special handling of unnamed packages in Elements.getPackageElement. Reviewed-by: darcy, jjg, ksrini ! src/java.compiler/share/classes/javax/lang/model/util/Elements.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/model/JavacElements.java ! test/tools/javac/modules/EdgeCases.java Changeset: 407027d18f9c Author: bpatel Date: 2017-01-26 13:01 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/407027d18f9c 8166175: javadoc search doesn't work on local doc bundles Reviewed-by: jjg, ksrini ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/script.js ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocPaths.java ! test/jdk/javadoc/doclet/testSearch/TestSearch.java Changeset: f9a22473d7f7 Author: lana Date: 2017-01-26 21:20 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/f9a22473d7f7 Merge Changeset: 86efeea0e59f Author: jjg Date: 2017-01-26 14:35 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/86efeea0e59f 8173312: Hide support for --inherit-runtime-environment Reviewed-by: mchung ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java Changeset: ef142ac9824e Author: bpatel Date: 2017-01-26 16:53 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/ef142ac9824e 8173419: Javadoc fix 8166175 results in test failures Reviewed-by: jjg, ksrini ! test/jdk/javadoc/tool/api/basic/APITest.java ! test/tools/javadoc/api/basic/APITest.java Changeset: 37c0e34e835c Author: jjg Date: 2017-01-27 15:49 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/37c0e34e835c 8081820: javadoc does not report warnings in case of multiple "@param" tags for the same parameter and multiple "@return" tags for the same method. Reviewed-by: jjg Contributed-by: istomin.den at gmail.com ! src/jdk.compiler/share/classes/com/sun/tools/doclint/Checker.java ! src/jdk.compiler/share/classes/com/sun/tools/doclint/resources/doclint.properties + test/tools/doclint/DuplicateParamTest.java + test/tools/doclint/DuplicateParamTest.out + test/tools/doclint/DuplicateReturnTest.java + test/tools/doclint/DuplicateReturnTest.out Changeset: b7bb3f51028a Author: darcy Date: 2017-01-30 15:08 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/b7bb3f51028a 8173609: Elements.printElements needs to support modules Reviewed-by: forax, jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java Changeset: a21e5b9dc5c3 Author: jjg Date: 2017-01-30 17:43 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/a21e5b9dc5c3 8172810: ModuleElement should declare and provide appropriate modifiers Reviewed-by: darcy ! src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java Changeset: dfcfdb2db85f Author: henryjen Date: 2017-01-31 13:55 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/dfcfdb2db85f 8172309: classpath wildcards code does not support --class-path Reviewed-by: jjg, ksrini ! test/tools/javac/Paths/wcMineField.sh Changeset: 804b6a348702 Author: lana Date: 2017-02-02 21:20 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/804b6a348702 Added tag jdk-9+155 for changeset dfcfdb2db85f ! .hgtags Changeset: 8c7bb3a85065 Author: alanb Date: 2017-02-03 09:34 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/8c7bb3a85065 Merge ! .hgtags ! src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java ! src/java.compiler/share/classes/javax/lang/model/util/Elements.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.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/model/JavacElements.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/script.js ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocPaths.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java ! test/ProblemList.txt ! test/tools/javac/modules/EdgeCases.java From alan.bateman at oracle.com Fri Feb 3 09:36:48 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 03 Feb 2017 09:36:48 +0000 Subject: hg: jigsaw/jake/hotspot: 5 new changesets Message-ID: <201702030936.v139amF5018442@aojmv0008.oracle.com> Changeset: e20d7e4a25ac Author: adinn Date: 2017-01-26 11:47 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e20d7e4a25ac 8173339: AArch64: Fix minimum stack size computations Reviewed-by: aph ! src/cpu/aarch64/vm/globals_aarch64.hpp Changeset: 7b0f663ad09c Author: lana Date: 2017-01-26 21:20 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7b0f663ad09c Merge Changeset: f3b3d77a1751 Author: adinn Date: 2017-01-27 07:56 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f3b3d77a1751 8173474: AArch64: fix reported -Xss minimum Reviewed-by: aph ! src/os_cpu/linux_aarch64/vm/os_linux_aarch64.cpp Changeset: 23667c4b2f0e Author: lana Date: 2017-02-02 21:20 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/23667c4b2f0e Added tag jdk-9+155 for changeset f3b3d77a1751 ! .hgtags Changeset: f67dc475dd73 Author: alanb Date: 2017-02-03 09:34 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f67dc475dd73 Merge ! .hgtags From alan.bateman at oracle.com Fri Feb 3 09:36:53 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 03 Feb 2017 09:36:53 +0000 Subject: hg: jigsaw/jake/jdk: 48 new changesets Message-ID: <201702030936.v139at2F018516@aojmv0008.oracle.com> Changeset: d191fcd1525d Author: rgoel Date: 2017-01-24 12:06 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d191fcd1525d 8167273: Calendar.getDisplayNames inconsistent with DateFormatSymbols Reviewed-by: naoto ! make/gensrc/GensrcLocaleData.gmk ! make/src/classes/build/tools/cldrconverter/Bundle.java ! src/java.base/share/classes/sun/util/cldr/CLDRLocaleProviderAdapter.java + test/java/util/Calendar/Bug8167273.java ! test/sun/util/locale/provider/Bug8038436.java Changeset: 082c6c17f6e4 Author: mli Date: 2017-01-24 00:48 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/082c6c17f6e4 8171142: jdk_rmi registry test fail to clean up on failure Reviewed-by: rriggs, dholmes ! test/java/rmi/activation/Activatable/shutdownGracefully/ShutdownGracefully.java ! test/java/rmi/reliability/benchmark/bench/rmi/Main.java ! test/java/rmi/server/UnicastRemoteObject/keepAliveDuringCall/KeepAliveDuringCall.java ! test/java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java ! test/java/rmi/testlibrary/JavaVM.java ! test/java/rmi/transport/checkFQDN/CheckFQDN.java ! test/java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java ! test/javax/rmi/PortableRemoteObject/8146975/RmiIiopReturnValueTest.java ! test/javax/rmi/PortableRemoteObject/ConcurrentHashMapTest.java ! test/sun/rmi/runtime/Log/4504153/Test4504153.java ! test/sun/rmi/runtime/Log/6409194/NoConsoleOutput.java Changeset: 038f5ea6e2f4 Author: apetcher Date: 2017-01-24 16:19 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/038f5ea6e2f4 8168075: Custom system class loader + security manager + malformed policy file = recursive initialization Reviewed-by: mchung, mullan ! src/java.base/share/classes/sun/security/provider/PolicyFile.java ! src/java.base/share/classes/sun/security/provider/PolicyParser.java + src/java.base/share/classes/sun/security/util/LocalizedMessage.java + test/sun/security/util/Resources/customSysClassLoader/BootMessages.java + test/sun/security/util/Resources/customSysClassLoader/CustomClassLoader.java + test/sun/security/util/Resources/customSysClassLoader/MessageFormatting.java + test/sun/security/util/Resources/customSysClassLoader/error.policy Changeset: 485e8eb733e1 Author: xuelei Date: 2017-01-24 23:07 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/485e8eb733e1 8172869: 4096 is not supported yet for the DH Parameter Generator Reviewed-by: ascarpino, mullan ! src/java.base/share/classes/java/security/AlgorithmParameterGenerator.java Changeset: c5840d5b92cc Author: psandoz Date: 2017-01-24 18:24 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c5840d5b92cc 8172732: spec clarification for URLClassLoader for Multirelease jars Reviewed-by: mchung, chegar, alanb ! src/java.base/share/classes/java/net/URLClassLoader.java Changeset: a468135ebe8e Author: mli Date: 2017-01-24 18:41 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a468135ebe8e 8171900: javax/net/ssl/SSLSession/SessionTimeOutTests.java failed with "SSLHandshakeException: Remote host terminated the handshake" Summary: The fix takes some code patterns from SSLSocketTemplate to deal with possible SSLHandshakeException and SocketTimeoutException, and it also resolves a potential mismatch on the connections between the clients and the servers. Reviewed-by: xuelei Contributed-by: John Jiang ! test/javax/net/ssl/SSLSession/SessionTimeOutTests.java Changeset: 4a36e73e0e18 Author: mli Date: 2017-01-25 03:47 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4a36e73e0e18 8173326: Problem list java/rmi/registry/readTest/CodebaseTest.java on Windows Reviewed-by: dholmes ! test/ProblemList.txt Changeset: e8dab4820716 Author: chegar Date: 2017-01-25 14:10 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e8dab4820716 8173354: javadoc warning notice for types in Incubator Modules Reviewed-by: erikj, michaelm + make/src/classes/build/tools/taglet/Incubating.java ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/HttpClient.java ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/HttpHeaders.java ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/HttpRequest.java ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/HttpResponse.java ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/HttpTimeoutException.java ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/MultiMapResult.java ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/WebSocket.java ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/WebSocketHandshakeException.java ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/package-info.java ! src/jdk.incubator.httpclient/share/classes/module-info.java Changeset: 9ecf1f5bc96c Author: plevart Date: 2017-01-25 15:41 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9ecf1f5bc96c 8173056: Add test that captures current behavior of annotations with invalid annotation types Reviewed-by: redestad ! test/java/lang/annotation/AnnotationVerifier.java ! test/java/lang/annotation/ClassFileGenerator.java + test/java/lang/annotation/GoodAnnotation.java Changeset: c7d93950979d Author: plevart Date: 2017-01-25 15:53 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c7d93950979d Merge Changeset: 5c7dda0aa8ce Author: mchung Date: 2017-01-25 10:53 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5c7dda0aa8ce 8172808: Handle sun.security.util.Resources bundle in ResourcesMgr in the same way as AuthResources Reviewed-by: mullan ! src/java.base/share/classes/sun/security/util/LocalizedMessage.java ! src/java.base/share/classes/sun/security/util/ResourcesMgr.java ! test/sun/security/util/Resources/customSysClassLoader/CustomClassLoader.java Changeset: f5f50c8d8714 Author: anazarov Date: 2017-01-26 14:32 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f5f50c8d8714 8173372: Add tests for multi-release module jar API validator Reviewed-by: psandoz ! test/tools/jar/multiRelease/ApiValidatorTest.java Changeset: e2025c196c21 Author: anazarov Date: 2017-01-26 19:06 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e2025c196c21 8173395: Problemlist tools/jar/multiRelease/ApiValidatorTest.java Reviewed-by: ksrini ! test/ProblemList.txt Changeset: 543c4e4b0311 Author: serb Date: 2017-01-18 18:14 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/543c4e4b0311 8149879: Examine UIDefaults::addResourceBundle(String bundleName) with resource encapsulation Reviewed-by: prr, mchung, alexsch ! src/java.desktop/macosx/classes/com/apple/laf/AquaLookAndFeel.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifLookAndFeel.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java ! src/java.desktop/share/classes/javax/swing/UIDefaults.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java ! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java ! src/java.desktop/share/classes/sun/swing/SwingAccessor.java + test/javax/swing/UIDefaults/8149879/InternalResourceBundle.java Changeset: f1d567c355a9 Author: alexsch Date: 2017-01-18 17:22 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f1d567c355a9 8168537: Test fails with AccessControlException Reviewed-by: prr, serb ! src/java.desktop/share/classes/sun/awt/shell/ShellFolder.java Changeset: 78392a83b36e Author: prr Date: 2017-01-18 17:36 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/78392a83b36e 6232267: TrueType Fonts which have only Apple platform names cannot be loaded Reviewed-by: psadhukhan ! src/java.desktop/share/classes/sun/font/TrueTypeFont.java + test/java/awt/FontClass/AppleFontNameTest.java Changeset: 4a198f260d12 Author: prr Date: 2017-01-19 12:04 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4a198f260d12 8172813: test/java/awt/font/JNICheck/JNICheck.sh fails on Linux Reviewed-by: serb, psadhukhan, pnarayanan ! src/java.desktop/unix/native/common/awt/fontpath.c ! test/java/awt/font/JNICheck/JNICheck.sh Changeset: 2c0a514ebdfb Author: aniyogi Date: 2017-01-20 12:56 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2c0a514ebdfb 8172509: [TEST_BUG] [macosx] Failure of the new test java/awt/Focus/FocusTraversalPolicy/ButtonGroupLayoutTraversal/ButtonGroupLayoutTraversalTest.java Reviewed-by: serb, alexsch ! test/java/awt/Focus/FocusTraversalPolicy/ButtonGroupLayoutTraversal/ButtonGroupLayoutTraversalTest.java Changeset: 98ae8c0231f5 Author: jdv Date: 2017-01-20 14:28 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/98ae8c0231f5 8173064: Unexpected tag in javax/imageio/plugins/tiff/package.html Reviewed-by: psadhukhan, arapte ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/package.html Changeset: bfae5ff40ba4 Author: prr Date: 2017-01-20 10:28 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/bfae5ff40ba4 8172999: Crash on Windows getting FontMetrics since JDK 9 b96 Reviewed-by: serb, vadim ! src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsDevice.cpp + test/java/awt/FontMetrics/FontCrash.java Changeset: d4150b065b15 Author: ddehaven Date: 2017-01-20 08:53 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d4150b065b15 Merge - test/java/lang/SecurityManager/RestrictedPackages.java Changeset: a928fe94b745 Author: bpb Date: 2017-01-20 15:09 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a928fe94b745 8145019: Exceptions from TIFFImageReader.read() when loading bit depth test images Summary: Fix some problems reading unusual bit depth images relating to setting the correct ImageTypeSpecifier and reformatting discontiguous data Reviewed-by: prr ! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFDecompressor.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFImageReader.java Changeset: c17354987c3c Author: bpb Date: 2017-01-20 15:13 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c17354987c3c 8154228: [TIFF] IIOException: "Insufficient data offsets or byte counts" when loading test image Summary: If byte counts are not provided attempt to compute them if feasible. Reviewed-by: prr ! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFIFD.java Changeset: f942a44fc47c Author: prr Date: 2017-01-20 16:03 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f942a44fc47c 8171836: Memory leak in java.desktop/unix/native/common/awt/fontpath.c Reviewed-by: prr, arapte Contributed-by: David Carlier ! src/java.desktop/unix/native/common/awt/fontpath.c Changeset: 0b8c68007690 Author: alitvinov Date: 2017-01-23 19:58 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0b8c68007690 8168751: Two "Direct Clip" threads are created to play the same "AudioClip" object, what makes clip sound corrupted Reviewed-by: serb, amenkov ! src/java.desktop/share/classes/com/sun/media/sound/DirectAudioDevice.java Changeset: 7396ce69df70 Author: prr Date: 2017-01-23 10:27 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7396ce69df70 Merge - src/java.base/share/classes/sun/security/util/AuthResourcesProvider.java - src/java.base/share/classes/sun/security/util/AuthResourcesProviderImpl.java - src/linux/doc/man/ja/jvisualvm.1 - src/linux/doc/man/jvisualvm.1 - src/solaris/doc/sun/man/man1/ja/jvisualvm.1 - src/solaris/doc/sun/man/man1/jvisualvm.1 Changeset: 87b36fe054e1 Author: prr Date: 2017-01-23 11:59 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/87b36fe054e1 8167228: Update to libpng 1.6.28 Reviewed-by: serb, azvegint ! src/java.desktop/share/native/libsplashscreen/libpng/CHANGES ! src/java.desktop/share/native/libsplashscreen/libpng/LICENSE ! src/java.desktop/share/native/libsplashscreen/libpng/README ! src/java.desktop/share/native/libsplashscreen/libpng/png.c ! src/java.desktop/share/native/libsplashscreen/libpng/png.h ! src/java.desktop/share/native/libsplashscreen/libpng/pngconf.h ! src/java.desktop/share/native/libsplashscreen/libpng/pngerror.c ! src/java.desktop/share/native/libsplashscreen/libpng/pngget.c ! src/java.desktop/share/native/libsplashscreen/libpng/pnglibconf.h ! src/java.desktop/share/native/libsplashscreen/libpng/pngmem.c ! src/java.desktop/share/native/libsplashscreen/libpng/pngpread.c ! src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h ! src/java.desktop/share/native/libsplashscreen/libpng/pngread.c ! src/java.desktop/share/native/libsplashscreen/libpng/pngrio.c ! src/java.desktop/share/native/libsplashscreen/libpng/pngrtran.c ! src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c ! src/java.desktop/share/native/libsplashscreen/libpng/pngset.c ! src/java.desktop/share/native/libsplashscreen/libpng/pngstruct.h - src/java.desktop/share/native/libsplashscreen/libpng/pngtest.c ! src/java.desktop/share/native/libsplashscreen/libpng/pngtrans.c - src/java.desktop/share/native/libsplashscreen/libpng/pngwio.c - src/java.desktop/share/native/libsplashscreen/libpng/pngwrite.c - src/java.desktop/share/native/libsplashscreen/libpng/pngwtran.c - src/java.desktop/share/native/libsplashscreen/libpng/pngwutil.c Changeset: 8270102790e5 Author: alexsch Date: 2017-01-24 11:37 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8270102790e5 8003495: [findbugs] javax.swing.* - Storing a reference to an externally mutable object into the internal representation Reviewed-by: prr, serb ! src/java.desktop/share/classes/javax/swing/JColorChooser.java ! src/java.desktop/share/classes/javax/swing/JOptionPane.java ! src/java.desktop/share/classes/sun/swing/FilePane.java Changeset: 1a13fbf70807 Author: prr Date: 2017-01-26 08:36 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1a13fbf70807 Merge - make/copy/Copy-jdk.crypto.token.gmk - make/lib/Lib-jdk.crypto.token.gmk - src/jdk.crypto.token/share/classes/module-info.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/Config.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/KeyCache.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/P11Cipher.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/P11DHKeyFactory.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/P11DSAKeyFactory.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/P11Digest.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/P11ECDHKeyAgreement.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/P11ECKeyFactory.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/P11Key.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/P11KeyAgreement.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/P11KeyFactory.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/P11KeyGenerator.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/P11KeyPairGenerator.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/P11KeyStore.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/P11Mac.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/P11RSACipher.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/P11RSAKeyFactory.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/P11SecureRandom.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/P11Signature.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/P11TlsKeyMaterialGenerator.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/P11TlsMasterSecretGenerator.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/P11TlsPrfGenerator.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/P11TlsRsaPremasterSecretGenerator.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/P11Util.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/Secmod.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/Session.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/SessionManager.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/SunPKCS11.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/TemplateManager.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/Token.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_AES_CTR_PARAMS.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_ATTRIBUTE.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_CREATEMUTEX.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_C_INITIALIZE_ARGS.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_DATE.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_DESTROYMUTEX.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_ECDH1_DERIVE_PARAMS.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_ECDH2_DERIVE_PARAMS.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_INFO.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_LOCKMUTEX.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM_INFO.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_NOTIFY.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_PBE_PARAMS.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_RSA_PKCS_OAEP_PARAMS.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_RSA_PKCS_PSS_PARAMS.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_SESSION_INFO.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_SLOT_INFO.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_SSL3_KEY_MAT_OUT.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_SSL3_KEY_MAT_PARAMS.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_SSL3_MASTER_KEY_DERIVE_PARAMS.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_SSL3_RANDOM_DATA.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_TLS_PRF_PARAMS.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_TOKEN_INFO.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_UNLOCKMUTEX.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_VERSION.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH1_DERIVE_PARAMS.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH2_DERIVE_PARAMS.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/Constants.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/Functions.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/PKCS11.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/PKCS11Exception.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/PKCS11RuntimeException.java - src/jdk.crypto.token/share/legal/pkcs11cryptotoken.md - src/jdk.crypto.token/share/legal/pkcs11wrapper.md - src/jdk.crypto.token/share/native/libj2pkcs11/j2secmod.c - src/jdk.crypto.token/share/native/libj2pkcs11/j2secmod.h - src/jdk.crypto.token/share/native/libj2pkcs11/p11_convert.c - src/jdk.crypto.token/share/native/libj2pkcs11/p11_crypt.c - src/jdk.crypto.token/share/native/libj2pkcs11/p11_digest.c - src/jdk.crypto.token/share/native/libj2pkcs11/p11_dual.c - src/jdk.crypto.token/share/native/libj2pkcs11/p11_general.c - src/jdk.crypto.token/share/native/libj2pkcs11/p11_keymgmt.c - src/jdk.crypto.token/share/native/libj2pkcs11/p11_mutex.c - src/jdk.crypto.token/share/native/libj2pkcs11/p11_objmgmt.c - src/jdk.crypto.token/share/native/libj2pkcs11/p11_sessmgmt.c - src/jdk.crypto.token/share/native/libj2pkcs11/p11_sign.c - src/jdk.crypto.token/share/native/libj2pkcs11/p11_util.c - src/jdk.crypto.token/share/native/libj2pkcs11/pkcs-11v2-20a3.h - src/jdk.crypto.token/share/native/libj2pkcs11/pkcs11.h - src/jdk.crypto.token/share/native/libj2pkcs11/pkcs11f.h - src/jdk.crypto.token/share/native/libj2pkcs11/pkcs11t.h - src/jdk.crypto.token/share/native/libj2pkcs11/pkcs11wrapper.h - src/jdk.crypto.token/solaris/conf/security/sunpkcs11-solaris.cfg - src/jdk.crypto.token/unix/native/libj2pkcs11/j2secmod_md.c - src/jdk.crypto.token/unix/native/libj2pkcs11/j2secmod_md.h - src/jdk.crypto.token/unix/native/libj2pkcs11/p11_md.c - src/jdk.crypto.token/unix/native/libj2pkcs11/p11_md.h - src/jdk.crypto.token/windows/native/libj2pkcs11/j2secmod_md.c - src/jdk.crypto.token/windows/native/libj2pkcs11/j2secmod_md.h - src/jdk.crypto.token/windows/native/libj2pkcs11/p11_md.c - src/jdk.crypto.token/windows/native/libj2pkcs11/p11_md.h Changeset: 03ea56f485f2 Author: lana Date: 2017-01-26 21:21 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/03ea56f485f2 Merge - src/java.desktop/share/native/libsplashscreen/libpng/pngtest.c - src/java.desktop/share/native/libsplashscreen/libpng/pngwio.c - src/java.desktop/share/native/libsplashscreen/libpng/pngwrite.c - src/java.desktop/share/native/libsplashscreen/libpng/pngwtran.c - src/java.desktop/share/native/libsplashscreen/libpng/pngwutil.c Changeset: d8dbac6098fe Author: henryjen Date: 2017-01-25 12:52 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d8dbac6098fe 8170832: Add a new launcher environment variable JAVA_OPTIONS Reviewed-by: mchung, ksrini ! make/lib/CoreLibraries.gmk ! make/mapfiles/libjli/mapfile-vers ! src/java.base/share/classes/sun/launcher/resources/launcher.properties ! src/java.base/share/classes/sun/launcher/resources/launcher_de.properties ! src/java.base/share/classes/sun/launcher/resources/launcher_es.properties ! src/java.base/share/classes/sun/launcher/resources/launcher_fr.properties ! src/java.base/share/classes/sun/launcher/resources/launcher_it.properties ! src/java.base/share/classes/sun/launcher/resources/launcher_ja.properties ! src/java.base/share/classes/sun/launcher/resources/launcher_ko.properties ! src/java.base/share/classes/sun/launcher/resources/launcher_pt_BR.properties ! src/java.base/share/classes/sun/launcher/resources/launcher_sv.properties ! src/java.base/share/classes/sun/launcher/resources/launcher_zh_CN.properties ! src/java.base/share/classes/sun/launcher/resources/launcher_zh_TW.properties ! src/java.base/share/native/launcher/main.c ! src/java.base/share/native/libjli/args.c ! src/java.base/share/native/libjli/emessages.h ! src/java.base/share/native/libjli/java.c ! src/java.base/share/native/libjli/java.h ! src/java.base/share/native/libjli/jli_util.h ! src/java.base/windows/native/libjli/cmdtoargs.c + test/tools/launcher/ArgsEnvVar.java ! test/tools/launcher/ArgsFileTest.java ! test/tools/launcher/I18NArgTest.java Changeset: 3fc9f267acc2 Author: valeriep Date: 2017-01-26 22:56 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3fc9f267acc2 8062731: Cipher object can be created without calling Cipher.getInstance Summary: Fixed the check in JCE so that only trusted providers can extend Cipher class Reviewed-by: wetmore ! src/java.base/share/classes/javax/crypto/JceSecurityManager.java Changeset: bbc90d3ffe84 Author: valeriep Date: 2017-01-26 23:11 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/bbc90d3ffe84 Merge Changeset: 39a8a0525677 Author: sundar Date: 2017-01-27 19:07 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/39a8a0525677 8172864: Remove custom plugin module path Reviewed-by: alanb, jlaskey ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties ! test/ProblemList.txt - test/tools/jlink/CustomPluginTest.java ! test/tools/jlink/JLink2Test.java - test/tools/jlink/customplugin/module-info.java - test/tools/jlink/customplugin/plugin/CustomPlugin.java - test/tools/jlink/customplugin/plugin/HelloPlugin.java - test/tools/jlink/customplugin/plugin/RogueAdderPlugin.java - test/tools/jlink/customplugin/plugin/RogueFilterPlugin.java Changeset: f467a23ab0c0 Author: prappo Date: 2017-01-27 16:27 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f467a23ab0c0 8170116: Remove qualified exports from java.base to java.corba Reviewed-by: dfuchs, alanb, mchung Contributed-by: Chris Hegarty , Daniel Fuchs ! src/java.base/share/classes/module-info.java Changeset: 5dab7d15ccbe Author: henryjen Date: 2017-01-27 13:10 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5dab7d15ccbe 8172309: classpath wildcards code does not support --class-path Reviewed-by: ksrini ! src/java.base/share/native/libjli/java.c ! src/java.base/share/native/libjli/wildcard.c ! test/tools/launcher/ClassPathWildCard.sh Changeset: ee8923e260c7 Author: sherman Date: 2017-01-28 20:51 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ee8923e260c7 8173396: Error message issue with jar tool API validator Reviewed-by: psandoz, mchung ! src/jdk.jartool/share/classes/sun/tools/jar/Validator.java ! test/ProblemList.txt ! test/tools/jar/multiRelease/ApiValidatorTest.java Changeset: 66e255787b73 Author: ihse Date: 2017-01-30 09:09 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/66e255787b73 8081694: Remove DISABLED_WARNINGS_gcc for libsctp Reviewed-by: erikj ! make/lib/Lib-jdk.sctp.gmk Changeset: d1127ebe902c Author: jlahoda Date: 2017-01-30 13:14 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d1127ebe902c 8166535: jshell tool: cannot handle non-ascii characters Summary: Using a more appropriate native method to read from the console. Reviewed-by: rfield ! src/jdk.internal.le/windows/native/lible/WindowsTerminal.cpp Changeset: 65a1441c9c80 Author: clanger Date: 2017-01-30 16:33 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/65a1441c9c80 8173634: libjli/cmdtoargs.c does not compile with VS2010 Reviewed-by: rriggs ! src/java.base/windows/native/libjli/cmdtoargs.c Changeset: 82e3708a0cf9 Author: skovalev Date: 2017-01-30 13:11 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/82e3708a0cf9 8173478: SSL related tests failes with message: "java.security.NoSuchAlgorithmException: EC KeyFactory not available" Reviewed-by: xuelei ! test/javax/net/ssl/FixingJavadocs/SSLSessionNulls.java ! test/javax/net/ssl/interop/ClientHelloChromeInterOp.java ! test/javax/net/ssl/templates/SSLSocketTemplate.java Changeset: f9e86da24d74 Author: mchung Date: 2017-01-30 11:00 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f9e86da24d74 8173381: osName/osArch/osVersion is missing in ModuleDescriptor created by SystemModules Reviewed-by: alanb ! src/java.base/share/classes/jdk/internal/module/ModuleInfoExtender.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ModuleSorter.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties ! test/tools/jlink/plugins/SystemModuleDescriptors/SystemModulesTest.java ! test/tools/jlink/plugins/SystemModuleDescriptors/UserModuleTest.java ! test/tools/jlink/plugins/SystemModuleDescriptors/src/m1/p1/Main.java + test/tools/jlink/plugins/SystemModuleDescriptors/src/m4/p4/Main.java + test/tools/jlink/plugins/SystemModuleDescriptors/src/m4/p4/dummy/dummy.properties Changeset: bb6976827304 Author: naoto Date: 2017-01-30 14:38 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/bb6976827304 8172365: Provide a better migration path for ResourceBundleControlProvider Reviewed-by: mchung ! src/java.base/share/classes/java/util/ResourceBundle.java ! src/java.base/share/classes/java/util/spi/ResourceBundleControlProvider.java + test/java/util/spi/ResourceBundleControlProvider/UserDefaultControlTest.java + test/java/util/spi/ResourceBundleControlProvider/com/foo/UserControlProvider.java + test/java/util/spi/ResourceBundleControlProvider/com/foo/UserXMLControl.java + test/java/util/spi/ResourceBundleControlProvider/com/foo/XmlRB.xml + test/java/util/spi/ResourceBundleControlProvider/com/foo/XmlRB_ja.xml + test/java/util/spi/ResourceBundleControlProvider/simple.properties + test/java/util/spi/ResourceBundleControlProvider/test/jdk/test/ResourceBundleDelegate.java + test/java/util/spi/ResourceBundleControlProvider/test/module-info.java Changeset: e0ab92b7360f Author: naoto Date: 2017-01-31 13:18 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e0ab92b7360f 8173423: Wrong display name for supplemental Japanese era Reviewed-by: sherman ! src/java.base/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java ! test/java/util/Calendar/SupplementalJapaneseEraTest.java ! test/java/util/Calendar/SupplementalJapaneseEraTest.sh Changeset: 69342000c9a9 Author: rasbold Date: 2017-01-31 21:33 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/69342000c9a9 8173581: performance regression in com/sun/crypto/provider/OutputFeedback.java Summary: Corrected the problem in OutputFeedback class Reviewed-by: valeriep Contributed-by: rasbold at google.com ! src/java.base/share/classes/com/sun/crypto/provider/OutputFeedback.java Changeset: e170c858888e Author: mchung Date: 2017-01-31 14:47 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e170c858888e 8173711: Disable JAVA_OPTIONS env variable support until JDK-8173712 is resolved Reviewed-by: ksrini, henryjen ! src/java.base/share/native/libjli/args.c ! test/ProblemList.txt ! test/tools/launcher/I18NArgTest.java Changeset: 802428c8b55d Author: lana Date: 2017-02-02 21:20 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/802428c8b55d Added tag jdk-9+155 for changeset e170c858888e ! .hgtags Changeset: 6864464edf8e Author: alanb Date: 2017-02-03 09:34 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6864464edf8e Merge ! .hgtags ! make/gensrc/GensrcLocaleData.gmk ! make/lib/CoreLibraries.gmk ! make/lib/Lib-jdk.sctp.gmk ! src/java.base/share/classes/java/net/URLClassLoader.java ! src/java.base/share/classes/java/util/ResourceBundle.java ! src/java.base/share/classes/java/util/spi/ResourceBundleControlProvider.java ! src/java.base/share/classes/jdk/internal/module/ModuleInfoExtender.java ! src/java.base/share/classes/module-info.java ! src/java.base/share/classes/sun/launcher/resources/launcher.properties ! src/java.base/share/classes/sun/security/provider/PolicyFile.java ! src/java.base/share/classes/sun/util/cldr/CLDRLocaleProviderAdapter.java ! src/java.base/share/native/launcher/main.c ! src/java.base/share/native/libjli/args.c ! src/java.base/share/native/libjli/emessages.h ! src/java.base/share/native/libjli/java.c ! src/java.base/share/native/libjli/java.h ! src/java.base/share/native/libjli/wildcard.c ! src/java.desktop/share/classes/javax/swing/UIDefaults.java - src/java.desktop/share/native/libsplashscreen/libpng/pngtest.c - src/java.desktop/share/native/libsplashscreen/libpng/pngwio.c - src/java.desktop/share/native/libsplashscreen/libpng/pngwrite.c - src/java.desktop/share/native/libsplashscreen/libpng/pngwtran.c - src/java.desktop/share/native/libsplashscreen/libpng/pngwutil.c ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties ! test/ProblemList.txt ! test/java/rmi/transport/checkFQDN/CheckFQDN.java ! test/javax/rmi/PortableRemoteObject/ConcurrentHashMapTest.java ! test/sun/rmi/runtime/Log/6409194/NoConsoleOutput.java - test/tools/jlink/CustomPluginTest.java ! test/tools/jlink/JLink2Test.java - test/tools/jlink/customplugin/module-info.java - test/tools/jlink/customplugin/plugin/CustomPlugin.java - test/tools/jlink/customplugin/plugin/HelloPlugin.java - test/tools/jlink/customplugin/plugin/RogueAdderPlugin.java - test/tools/jlink/customplugin/plugin/RogueFilterPlugin.java ! test/tools/jlink/plugins/SystemModuleDescriptors/SystemModulesTest.java ! test/tools/jlink/plugins/SystemModuleDescriptors/UserModuleTest.java ! test/tools/jlink/plugins/SystemModuleDescriptors/src/m1/p1/Main.java From rfscholte at apache.org Fri Feb 3 11:44:38 2017 From: rfscholte at apache.org (Robert Scholte) Date: Fri, 03 Feb 2017 12:44:38 +0100 Subject: Automatic module names In-Reply-To: <55f73bef-657f-8669-4969-0830d5119b72@codefx.org> References: <55f73bef-657f-8669-4969-0830d5119b72@codefx.org> Message-ID: Hi Nicolai, let's consider that my project depends on the following dependencies: com.foo.bar:library:1.0 and com.acme:library:2.3.1, both unnamed. I somehow want to have them both as requirements: module M.N { requires static library; // com.foo.bar:library requires library; // com.acme:library } How can I define that the 'requires static library' should be mapped to com.foo.bar:library:1.0 on the modulepath, while 'requires library' should be mapped to com.acme:library:2.3.1 One ugly solution would be: requires static library containing com.foo.bar.baz.SomeClass; requires library containing acme.AnotherClass; We should really wonder if ease-of-transition is worth the minefield we're creating with the introduction of automodules. IMHO all options we're trying to add to keep automodules will only over-complicate things, not even being sure if all edges are covered. thanks, Robert On Thu, 02 Feb 2017 12:28:13 +0100, Nicolai Parlog wrote: > Hi everyone, > > after thinking about this a little longer, I came to the conclusion that > compile-time/launch-time aliasing might be the only way out of this (at > least the only I could come up with) that keeps automatic modules alive > and does not introduce a conceptual dependency on Maven. > > The idea: > > A command line option, let's say `--alias-modules A=X`, maps module name > A to module name X. Every dependency on either A or X will be resolved > to X, implying that there must a module X in the universe of observable > modules. There can be several aliases for the same module > (`--alias-modules A=X,B=X`; X needs to be observable) and they can be > chained (`--alias-modules A=X,X=Y`; Y needs to be observable) > > Aliasing would of course have to be applied to qualified exports, opens, > and similar mechanisms as well. > > It might be worth adding the rule that no observable module must have an > aliased name. So for `--alias-modules A=X` there must be no observable > module A. This prevents ambiguity and would effectively prevent aliasing > platform modules. That might be a good thing because it looks like > aliasing and upgrading modules has quite some overlap (or is even > identical?) > > Unfortunately I could not come up with a way to limit aliasing to > automatic module names (in case that were desirable) without somehow > marking dependencies on automatic modules, likely in the module > declaration. If changing module declaration syntax is still on the > table, it could be changed so that dependencies on automatic modules > must be phrased as something like `requires automatic`. > > The obvious semantics would be that only such requires clauses can be > fulfilled with automatic modules and that only such dependencies could > be aliased (this might make it prudent to phrase the aliasing option > accordingly, e.g. `--alias-automatic-modules`). > > This could also be used to help developers in keeping their module > declarations clean: The compiler could to emit a warning if a `requires > automatic` clause is fulfilled by a regular module. > > I would love to hear some thoughts on this idea, even if it considered > to be stupid, impractical,etc. :) > > so long ... Nicolai > > > > On 27.01.2017 15:11, Stephen Colebourne wrote: >> Back in October, I raised the issue of modules names generally and for >> automatic modules specifically [1]. The short thread came to no >> conclusion, but recent threads have again raised similar problems. The >> problem is that automatic modules have magical name creation from a >> filename, which is brittle and unlike anything else in Java. >> >> I also recently looked at the Joda-Convert and Joda-Beans libraries, >> to see if I could add module-info in preparation for Java 9. I quickly >> backed away, again because of the same issue. Put simply, I am >> unwilling to write a module-info file that refers to a dependency that >> is not yet a module. And I have to advise all open source projects to >> do the same. Given this, there can be no simple migration to the JPMS >> for open source projects. Each open source project must wait for all >> its dependencies to migrate to JPMS (by adding a module-info and >> publishing to Maven Central). >> >> The issue is clear. If I write this: >> >> module org.joda.convert { >> requires guava; >> } >> >> where guava is an automatic module, I am locking in the name of the >> guava dependency, something that I do not control. The name "guava" is >> just a guess. The guava authors might choose "com.google.guava" or >> something else entirely. >> >> In a closed system of modules, ie. a private application, automatic >> modules are fine, because the requires clause can be changed if it >> turns out the guess was wrong. But once published as an open source >> project to Maven Central or elsewhere, the guess cannot be fixed if it >> is wrong (without releasing a new version of the library, which is not >> an acceptable solution). >> >> I also strongly believe that module names cannot be flat and >> unstructured, such as "joda-convert" or "guava". They must have >> structure, such as the domain name or a Maven-style group name >> "org.joda.convert" or "org.joda:joda-convert". The potential for >> clashes has been shown by the Maven team [2]. >> >> Some brainstormed possible changes: >> >> - Remove the automatic module concept altogether >> >> - Define a clear mapping from Maven Central co-ordinates to module >> name that includes the group, artifact and classifier >> >> - Provide a text file to JPMS that allows incorrect module names to be >> mapped to the correct name >> >> - Publicly advise against using automatic modules for open source >> projects >> >> - Change rules of Maven Central to prevent modular jars being added >> that depend on an automatic module >> >> - Allow requires clauses to have aliases - requires org.guava.guava OR >> guava. >> >> - Allow modules to have aliases - module org.guava.guava AKA guava >> >> >> Given that applications can depend on libraries that haven't been >> released in years, this has the potential to be a critical problem for >> the ecosystem. My preference remains to define a clear mapping from >> the widely adopted Maven Central naming strategy to JPMS modules. >> Ideally, this would be a formal group concept in the JPMS, something >> that I believe is sorely lacking. >> >> Stephen >> >> [1] >> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-October/009631.html >> [2] >> http://mail.openjdk.java.net/pipermail/jpms-spec-observers/2017-January/000707.html >> From alan.bateman at oracle.com Fri Feb 3 12:07:09 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 03 Feb 2017 12:07:09 +0000 Subject: hg: jigsaw/jake/jdk: 2 new changesets Message-ID: <201702031207.v13C79kt021495@aojmv0008.oracle.com> Changeset: a0a6f078fefe Author: alanb Date: 2017-02-03 12:06 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a0a6f078fefe Tighten up ModuleReader for exploded modules ! src/java.base/share/classes/java/lang/module/ModuleReader.java ! src/java.base/share/classes/jdk/internal/loader/ResourceHelper.java ! test/java/lang/module/ModuleReader/ModuleReaderTest.java Changeset: ee81e3ab4655 Author: alanb Date: 2017-02-03 12:06 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ee81e3ab4655 Minor SL javadoc update ! src/java.base/share/classes/java/util/ServiceLoader.java From david.lloyd at redhat.com Fri Feb 3 14:29:02 2017 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 3 Feb 2017 08:29:02 -0600 Subject: Automatic module names In-Reply-To: References: <55f73bef-657f-8669-4969-0830d5119b72@codefx.org> Message-ID: <54002ec6-be4d-ec33-6e60-8b5e1fb91a33@redhat.com> I think one option we should consider is to perhaps disable automatic modules for 9 and revisit the idea for 10, as it's late in the day and still clearly not settled. On 02/03/2017 05:44 AM, Robert Scholte wrote: > Hi Nicolai, > > let's consider that my project depends on the following dependencies: > com.foo.bar:library:1.0 and com.acme:library:2.3.1, both unnamed. > > I somehow want to have them both as requirements: > module M.N { > requires static library; // com.foo.bar:library > requires library; // com.acme:library > } > > How can I define that the 'requires static library' should be mapped to > com.foo.bar:library:1.0 on the modulepath, while 'requires library' > should be mapped to com.acme:library:2.3.1 > > One ugly solution would be: > requires static library containing com.foo.bar.baz.SomeClass; > requires library containing acme.AnotherClass; > > We should really wonder if ease-of-transition is worth the minefield > we're creating with the introduction of automodules. IMHO all options > we're trying to add to keep automodules will only over-complicate > things, not even being sure if all edges are covered. > > thanks, > Robert > > On Thu, 02 Feb 2017 12:28:13 +0100, Nicolai Parlog wrote: > >> Hi everyone, >> >> after thinking about this a little longer, I came to the conclusion that >> compile-time/launch-time aliasing might be the only way out of this (at >> least the only I could come up with) that keeps automatic modules alive >> and does not introduce a conceptual dependency on Maven. >> >> The idea: >> >> A command line option, let's say `--alias-modules A=X`, maps module name >> A to module name X. Every dependency on either A or X will be resolved >> to X, implying that there must a module X in the universe of observable >> modules. There can be several aliases for the same module >> (`--alias-modules A=X,B=X`; X needs to be observable) and they can be >> chained (`--alias-modules A=X,X=Y`; Y needs to be observable) >> >> Aliasing would of course have to be applied to qualified exports, opens, >> and similar mechanisms as well. >> >> It might be worth adding the rule that no observable module must have an >> aliased name. So for `--alias-modules A=X` there must be no observable >> module A. This prevents ambiguity and would effectively prevent aliasing >> platform modules. That might be a good thing because it looks like >> aliasing and upgrading modules has quite some overlap (or is even >> identical?) >> >> Unfortunately I could not come up with a way to limit aliasing to >> automatic module names (in case that were desirable) without somehow >> marking dependencies on automatic modules, likely in the module >> declaration. If changing module declaration syntax is still on the >> table, it could be changed so that dependencies on automatic modules >> must be phrased as something like `requires automatic`. >> >> The obvious semantics would be that only such requires clauses can be >> fulfilled with automatic modules and that only such dependencies could >> be aliased (this might make it prudent to phrase the aliasing option >> accordingly, e.g. `--alias-automatic-modules`). >> >> This could also be used to help developers in keeping their module >> declarations clean: The compiler could to emit a warning if a `requires >> automatic` clause is fulfilled by a regular module. >> >> I would love to hear some thoughts on this idea, even if it considered >> to be stupid, impractical,etc. :) >> >> so long ... Nicolai >> >> >> >> On 27.01.2017 15:11, Stephen Colebourne wrote: >>> Back in October, I raised the issue of modules names generally and for >>> automatic modules specifically [1]. The short thread came to no >>> conclusion, but recent threads have again raised similar problems. The >>> problem is that automatic modules have magical name creation from a >>> filename, which is brittle and unlike anything else in Java. >>> >>> I also recently looked at the Joda-Convert and Joda-Beans libraries, >>> to see if I could add module-info in preparation for Java 9. I quickly >>> backed away, again because of the same issue. Put simply, I am >>> unwilling to write a module-info file that refers to a dependency that >>> is not yet a module. And I have to advise all open source projects to >>> do the same. Given this, there can be no simple migration to the JPMS >>> for open source projects. Each open source project must wait for all >>> its dependencies to migrate to JPMS (by adding a module-info and >>> publishing to Maven Central). >>> >>> The issue is clear. If I write this: >>> >>> module org.joda.convert { >>> requires guava; >>> } >>> >>> where guava is an automatic module, I am locking in the name of the >>> guava dependency, something that I do not control. The name "guava" is >>> just a guess. The guava authors might choose "com.google.guava" or >>> something else entirely. >>> >>> In a closed system of modules, ie. a private application, automatic >>> modules are fine, because the requires clause can be changed if it >>> turns out the guess was wrong. But once published as an open source >>> project to Maven Central or elsewhere, the guess cannot be fixed if it >>> is wrong (without releasing a new version of the library, which is not >>> an acceptable solution). >>> >>> I also strongly believe that module names cannot be flat and >>> unstructured, such as "joda-convert" or "guava". They must have >>> structure, such as the domain name or a Maven-style group name >>> "org.joda.convert" or "org.joda:joda-convert". The potential for >>> clashes has been shown by the Maven team [2]. >>> >>> Some brainstormed possible changes: >>> >>> - Remove the automatic module concept altogether >>> >>> - Define a clear mapping from Maven Central co-ordinates to module >>> name that includes the group, artifact and classifier >>> >>> - Provide a text file to JPMS that allows incorrect module names to be >>> mapped to the correct name >>> >>> - Publicly advise against using automatic modules for open source >>> projects >>> >>> - Change rules of Maven Central to prevent modular jars being added >>> that depend on an automatic module >>> >>> - Allow requires clauses to have aliases - requires org.guava.guava >>> OR guava. >>> >>> - Allow modules to have aliases - module org.guava.guava AKA guava >>> >>> >>> Given that applications can depend on libraries that haven't been >>> released in years, this has the potential to be a critical problem for >>> the ecosystem. My preference remains to define a clear mapping from >>> the widely adopted Maven Central naming strategy to JPMS modules. >>> Ideally, this would be a formal group concept in the JPMS, something >>> that I believe is sorely lacking. >>> >>> Stephen >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-October/009631.html >>> >>> [2] >>> http://mail.openjdk.java.net/pipermail/jpms-spec-observers/2017-January/000707.html >>> >>> -- - DML From adinn at redhat.com Fri Feb 3 14:43:41 2017 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 3 Feb 2017 14:43:41 +0000 Subject: Automatic module names In-Reply-To: <54002ec6-be4d-ec33-6e60-8b5e1fb91a33@redhat.com> References: <55f73bef-657f-8669-4969-0830d5119b72@codefx.org> <54002ec6-be4d-ec33-6e60-8b5e1fb91a33@redhat.com> Message-ID: <5ba1ec95-4382-d38f-1e0f-0e5509179c39@redhat.com> On 03/02/17 14:29, David M. Lloyd wrote: > I think one option we should consider is to perhaps disable automatic > modules for 9 and revisit the idea for 10, as it's late in the day and > still clearly not settled. I don't think this is thinking about the trade-off correctly. Automatic modules may not work for some (or maybe many) of the more complicated cases but those failures can be addressed over time by adding a module.xml to update releases of jars. Automatic modules definitely does work for straightforward cases to provide an easy way of deploying jars you don't own/can't rewrite as modules. Much as I admit that there are going to be lots of cases where it will fail I think those where it just works will still be a large subset. So, automatic modules will definitely be a big help to a lot of users who want to get started with Jigsaw. And, well, maybe I need to say this -- yes, an easy start is a /big/ priority. That's merely 2 cents, gratis. Your mileage may vary, particularly when it fails for your app. But I don't the mere possibility of the latter as a reason to poop on someone (everyone?) else's parade. regards, Andrew Dinn ----------- From Alan.Bateman at oracle.com Fri Feb 3 15:40:43 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 3 Feb 2017 15:40:43 +0000 Subject: Automatic module names In-Reply-To: References: <55f73bef-657f-8669-4969-0830d5119b72@codefx.org> Message-ID: <617664d5-8ea6-1be8-7790-8d7ecd669e96@oracle.com> On 03/02/2017 11:44, Robert Scholte wrote: > Hi Nicolai, > > let's consider that my project depends on the following dependencies: > com.foo.bar:library:1.0 and com.acme:library:2.3.1, both unnamed. > > I somehow want to have them both as requirements: > module M.N { > requires static library; // com.foo.bar:library > requires library; // com.acme:library > } > > How can I define that the 'requires static library' should be mapped > to com.foo.bar:library:1.0 on the modulepath, while 'requires library' > should be mapped to com.acme:library:2.3.1 > > One ugly solution would be: > requires static library containing com.foo.bar.baz.SomeClass; > requires library containing acme.AnotherClass; > > We should really wonder if ease-of-transition is worth the minefield > we're creating with the introduction of automodules. IMHO all options > we're trying to add to keep automodules will only over-complicate > things, not even being sure if all edges are covered. I think automatic modules are critical to migration, otherwise things move at the pace of the slowest project (which might be 0km/h in case of unmaintained projects). A lot of the discussion here has been on the naming but automatic modules but the other important benefit of automatic modules is that they support bridging to the class path. As regards the example naming clash then these two projects might already get complaints over their poor choice of artifacts, esp. when artifacts for both projects are in same directory (say where someone distributes with all JAR files in a `lib` directory). -Alan From scolebourne at joda.org Fri Feb 3 16:34:11 2017 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 3 Feb 2017 16:34:11 +0000 Subject: Automatic module names - "requires package" proposal Message-ID: On 3 February 2017 at 15:40, Alan Bateman wrote: > I think automatic modules are critical to migration, otherwise things move > at the pace of the slowest project (which might be 0km/h in case of > unmaintained projects). A lot of the discussion here has been on the naming > but automatic modules but the other important benefit of automatic modules > is that they support bridging to the class path. > > As regards the example naming clash then these two projects might already > get complaints over their poor choice of artifacts, esp. when artifacts for > both projects are in same directory (say where someone distributes with all > JAR files in a `lib` directory). We can't close our eyes to this problem. There can be naming clashes as above, naming problems due to having to guess a project's choice of a module name. We need to take the guesswork out, and have something based on Java compilation elements. As such, I'd like to propose an alternative based on packages that could still be feasible in the time available: 1) Have two types of `requires` clause - one for modules and one for packages 2) When requiring a package, that package must be available, either on the classpath or in a module 3) When requiring a package, the package must not be found in a module that is explicitly referenced 4) Fully modularized applications do not have `requires package` - this is a migration feature like `open modules` module com.org.a { // dependency on a module (modular jar) requires module com.org.b; requires module com.org.c; // dependency on packages (modular jar or classpath) requires package com.org.d; requires package com.org.d.x; requires package com.org.d.y; } In the example above, the three explicitly specified packages must not be found in module `com.org.b` or `com.org.c` (rule #3). They must instead be found in a jar on the classpath (each package must be found only in one jar), or in a future module (which could have any name, not just `com.org.d` or `d`). The `requires package` provides the "bridge" to the classpath and older jars that is desired, without the mess of automatic modules. Note that there would be no automatic modules as currently planned in this proposal. (FWIW, in the implementation, I'd imagine that each required package would be created as a separate module, using the same openess/security design as automatic modules today) Stephen From david.lloyd at redhat.com Fri Feb 3 16:42:25 2017 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 3 Feb 2017 10:42:25 -0600 Subject: Automatic module names In-Reply-To: <5ba1ec95-4382-d38f-1e0f-0e5509179c39@redhat.com> References: <55f73bef-657f-8669-4969-0830d5119b72@codefx.org> <54002ec6-be4d-ec33-6e60-8b5e1fb91a33@redhat.com> <5ba1ec95-4382-d38f-1e0f-0e5509179c39@redhat.com> Message-ID: <9acbac2f-21b6-c734-f14e-b42eb875e8e2@redhat.com> On 02/03/2017 08:43 AM, Andrew Dinn wrote: > On 03/02/17 14:29, David M. Lloyd wrote: >> I think one option we should consider is to perhaps disable automatic >> modules for 9 and revisit the idea for 10, as it's late in the day and >> still clearly not settled. > > I don't think this is thinking about the trade-off correctly. > > Automatic modules may not work for some (or maybe many) of the more > complicated cases but those failures can be addressed over time by > adding a module.xml to update releases of jars. > > Automatic modules definitely does work for straightforward cases to > provide an easy way of deploying jars you don't own/can't rewrite as > modules. Sure, but the set of JARs you can't rewrite is really pretty spare. And, in the few cases where it might cause a hypothetical problem (say, it's signed or something, though I doubt that this actually prevents rewriting the descriptor), there is at least one alternative provider that can modularize them cleanly (like ours, for example). Tools like Maven can and probably will easily cover the vast majority of cases more effectively than this mechanism. "It fixes many cases" is necessary but not sufficient for acceptance in my view. "It doesn't bungle other cases" is also a necessary condition. > Much as I admit that there are going to be lots of cases where it will > fail I think those where it just works will still be a large subset. So, > automatic modules will definitely be a big help to a lot of users who > want to get started with Jigsaw. > > And, well, maybe I need to say this -- yes, an easy start is a /big/ > priority. Yes, however there are more ways than one to bake that particular cake. > That's merely 2 cents, gratis. Your mileage may vary, particularly when > it fails for your app. But I don't the mere possibility of the latter as > a reason to poop on someone (everyone?) else's parade. I sympathize, mainly because software generally is a Tough Thing to Do, however "on the ground" I tend to disagree fundamentally with that sentiment, as in my experience this tends to lead immediately to "if the first idea works even a bit, run with it", which in turn means that quality becomes a lowest common denominator, which in turn invariably leads to high costs (of various types). These ideas simply don't scale, and they're the ones that one inevitably looks back at 5 years down the road, saying "gee, I really wish we hadn't done that". Sometimes the right answer is "OK, well that idea had some merit, but not enough to justify it". I don't disagree with the goal of providing a rapid on-ramp for users - quite the opposite - but I think that the automatic modules feature itself is neither necessary nor sufficient in order to meet it. I think tooling can be just as easy and intuitive, and far more effective in terms of use cases covered, flexibility, evolvability, etc. -- - DML From david.lloyd at redhat.com Fri Feb 3 16:54:49 2017 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 3 Feb 2017 10:54:49 -0600 Subject: Automatic module names In-Reply-To: <617664d5-8ea6-1be8-7790-8d7ecd669e96@oracle.com> References: <55f73bef-657f-8669-4969-0830d5119b72@codefx.org> <617664d5-8ea6-1be8-7790-8d7ecd669e96@oracle.com> Message-ID: <1fb07398-3f9d-6508-795b-c48c29856887@redhat.com> On 02/03/2017 09:40 AM, Alan Bateman wrote: > On 03/02/2017 11:44, Robert Scholte wrote: > >> Hi Nicolai, >> >> let's consider that my project depends on the following dependencies: >> com.foo.bar:library:1.0 and com.acme:library:2.3.1, both unnamed. >> >> I somehow want to have them both as requirements: >> module M.N { >> requires static library; // com.foo.bar:library >> requires library; // com.acme:library >> } >> >> How can I define that the 'requires static library' should be mapped >> to com.foo.bar:library:1.0 on the modulepath, while 'requires library' >> should be mapped to com.acme:library:2.3.1 >> >> One ugly solution would be: >> requires static library containing com.foo.bar.baz.SomeClass; >> requires library containing acme.AnotherClass; >> >> We should really wonder if ease-of-transition is worth the minefield >> we're creating with the introduction of automodules. IMHO all options >> we're trying to add to keep automodules will only over-complicate >> things, not even being sure if all edges are covered. > I think automatic modules are critical to migration, otherwise things > move at the pace of the slowest project (which might be 0km/h in case of > unmaintained projects). A lot of the discussion here has been on the > naming but automatic modules but the other important benefit of > automatic modules is that they support bridging to the class path. I still believe this conclusion is based on a false assumption, or rather a pair of them: the assumption that users will generally wish to distribute a module as a direct artifact of their build in any cases but the most proprietary, and the assumption that modularizing a project is something that is done when that project is compiled rather than when it is distributed. All evidence seems to indicate that these assumptions are completely unfounded. Using tooling to migrate to a modularized environment is not only a perfectly reasonable alternative, but is very, *very* likely to be quite close to the standard build/distribute workflow coming out the gate and onward for many years. Maven and Gradle essentially dominate the world of Java project building. They (and their supporting utilities) already take on most if not all distribution tasks: customizing MANIFEST.MF and service files, bundling local and even remote resources, source and bytecode translation, annotation processing, customized packaging, etc. It seems inevitable that such tools will also be used build module distributions, performing resolution and wiring tasks on large groups of artifacts at a time and producing a module set or even an image at output, as a final step before CI and/or distribution. I cannot conceive of any other sane workflow unless as I said your environment is highly proprietary (neither consuming nor producing artifacts that are ever shared with anyone else nor shared across distibution-wide versions) and/or highly constrained (to a very small number of modules or using very rigid (and probably brittle) rules for artifact sharing). Note that in these cases, most if not all of the value proposition of modularity is already lost. > As regards the example naming clash then these two projects might > already get complaints over their poor choice of artifacts, esp. when > artifacts for both projects are in same directory (say where someone > distributes with all JAR files in a `lib` directory). -- - DML From Alan.Bateman at oracle.com Fri Feb 3 17:42:49 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 3 Feb 2017 17:42:49 +0000 Subject: Automatic module names In-Reply-To: <9acbac2f-21b6-c734-f14e-b42eb875e8e2@redhat.com> References: <55f73bef-657f-8669-4969-0830d5119b72@codefx.org> <54002ec6-be4d-ec33-6e60-8b5e1fb91a33@redhat.com> <5ba1ec95-4382-d38f-1e0f-0e5509179c39@redhat.com> <9acbac2f-21b6-c734-f14e-b42eb875e8e2@redhat.com> Message-ID: <58af7789-f927-9112-6835-e4e941a9f1e1@oracle.com> On 03/02/2017 16:42, David M. Lloyd wrote: > : > > Sure, but the set of JARs you can't rewrite is really pretty spare. I've no doubt that many people would be uncomfortable taking responsibility to modularize a component that they don't maintain or have full knowledge of. In the early exploration phase of Project Jigsaw then we have some basic tooling to help with exactly that approach but it has long been left behind. One reason is that potential for anarchy with several people converting the same library to a module. You might not like automatic modules but at least the module descriptors that are derived are very predictable (including the name). -Alan. From jhoeller at pivotal.io Fri Feb 3 18:14:52 2017 From: jhoeller at pivotal.io (Juergen Hoeller) Date: Fri, 3 Feb 2017 19:14:52 +0100 Subject: Optional framework dependencies: requires static vs automatic modules Message-ID: I've been experimenting with a Spring/Hibernate application on Jigsaw again, in particular with respect to including module-info descriptors in our framework jars... as opposed to using the framework jars as automatic modules. Unfortunately, it seems that "requires static" is transitive at compilation time: Compiling an application module against a framework module which in turn declares "requires static" some optional third-party module fails if that optional third-party module is not on the application's compilation module path, even if that module is not needed at all and won't be on the application's runtime module path either. As an example: "spring-context" has a couple of optional dependencies, e.g. on Groovy and Kotlin. If it declares those as "requires static" in its module-info, application modules compiling against it are currently forced to have Groovy and Kotlin on their compilation module path. This case is particularly odd since there will be hardly an application using both of those languages at the same time. The arrangement works fine at runtime in such a typical Spring stack, with the optional modules not present and the JVM not complaining. However, the effect that javac requires application builds to have all of Spring's optional dependencies on the compilation path is clearly a showstopper: We won't ever be able to ship module-info descriptors in our core framework jars that way. Note that we do not have that problem with automatic modules: Those can see optional modules on the module path depending on availability, with the framework reacting to their presence, even decoupled from the specific module names (since we do not have to refer to them anywhere). It seems that automatic modules are semantically a better fit for us for that reason, even long term. However, with automatic modules, we can't transitively expose *required* dependencies: Application modules declaring "requires spring-context" have to explicitly declare "requires spring-beans" and "requires spring-core" etc since many of spring-context's exposed types refer to types from spring-beans and spring-core. Nevertheless, this is the best that we can offer at this point. Was it intentional for "requires static" to work that way? Am I missing something? From my perspective, "requires static" means that the referenced module has to be present when compiling the declaring module... but not when compiling other modules depending on the declaring module. Juergen From jhoeller at pivotal.io Fri Feb 3 18:17:45 2017 From: jhoeller at pivotal.io (Juergen Hoeller) Date: Fri, 3 Feb 2017 19:17:45 +0100 Subject: ClassLoader.getResource("mypackageroot") fails against exploded module Message-ID: Spring's classpath scanning works fine on JDK 9 for classpath resources (archives as well directories) and also for archives on the module path. However, it does not work for an exploded module layout, simply because ClassLoader.getResource("mypackageroot") always returns null in such a scenario. Since ClassLoader.getResource("mypackageroot") works in all other scenarios, including module jars on the module path, I wonder whether this is accidental? Juergen From Alan.Bateman at oracle.com Fri Feb 3 19:07:44 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 3 Feb 2017 19:07:44 +0000 Subject: Optional framework dependencies: requires static vs automatic modules In-Reply-To: References: Message-ID: On 03/02/2017 18:14, Juergen Hoeller wrote: > : > > Was it intentional for "requires static" to work that way? Am I missing > something? From my perspective, "requires static" means that the referenced > module has to be present when compiling the declaring module... but not > when compiling other modules depending on the declaring module. > I suspect what you are seeing isn't specific to `requires static` but rather a long standing issues where javac has needed the transitive closure to be observable when compiling any module. There are changes in jdk9/dev for jdk-9+156 (next week's build) that mostly fix this issue and it will be interesting to see if that addresses your concerns. -Alan From jhoeller at pivotal.io Fri Feb 3 19:16:16 2017 From: jhoeller at pivotal.io (Juergen Hoeller) Date: Fri, 3 Feb 2017 20:16:16 +0100 Subject: Optional framework dependencies: requires static vs automatic modules In-Reply-To: References: Message-ID: For "requires static" specifically, this effect is quite dramatic since it makes the optional runtime dependency feature useless for a large number of target scenarios. Alright, I'll re-test against build 156+ then. Juergen On Fri, Feb 3, 2017 at 8:07 PM, Alan Bateman wrote: > On 03/02/2017 18:14, Juergen Hoeller wrote: > > : >> >> Was it intentional for "requires static" to work that way? Am I missing >> something? From my perspective, "requires static" means that the >> referenced >> module has to be present when compiling the declaring module... but not >> when compiling other modules depending on the declaring module. >> >> I suspect what you are seeing isn't specific to `requires static` but > rather a long standing issues where javac has needed the transitive closure > to be observable when compiling any module. There are changes in jdk9/dev > for jdk-9+156 (next week's build) that mostly fix this issue and it will > be interesting to see if that addresses your concerns. > > -Alan > From Alan.Bateman at oracle.com Fri Feb 3 19:30:27 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 3 Feb 2017 19:30:27 +0000 Subject: ClassLoader.getResource("mypackageroot") fails against exploded module In-Reply-To: References: Message-ID: On 03/02/2017 18:17, Juergen Hoeller wrote: > Spring's classpath scanning works fine on JDK 9 for classpath resources > (archives as well directories) and also for archives on the module path. > > However, it does not work for an exploded module layout, simply > because ClassLoader.getResource("mypackageroot") always returns null in > such a scenario. > > Since ClassLoader.getResource("mypackageroot") works in all other > scenarios, including module jars on the module path, I wonder whether this > is accidental? Sadly, resource names have always been poorly specified. It's very much implementation and class loader specific as to whether you could get a URL to a "directory" like this. However, you are right that there is an inconsistency between exploded and packages modules that we should sort out. -Alan. From mandy.chung at oracle.com Fri Feb 3 21:50:27 2017 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 03 Feb 2017 21:50:27 +0000 Subject: hg: jigsaw/jake/jdk: Add @spec tag on additional APIs for JPMS spec Message-ID: <201702032150.v13LoR0W024678@aojmv0008.oracle.com> Changeset: 5135bbdae96f Author: mchung Date: 2017-02-03 13:50 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5135bbdae96f Add @spec tag on additional APIs for JPMS spec ! src/java.base/share/classes/java/lang/StackTraceElement.java ! src/java.base/share/classes/java/net/URLClassLoader.java ! src/java.base/share/classes/java/security/SecureClassLoader.java ! src/java.instrument/share/classes/java/lang/instrument/ClassFileTransformer.java From peeyush.m at gmail.com Sat Feb 4 04:42:36 2017 From: peeyush.m at gmail.com (Peeyush Maharshi) Date: Sat, 4 Feb 2017 10:12:36 +0530 Subject: Help Unsubscribe me from this chain Message-ID: On Feb 3, 2017 10:04 PM, wrote: Send jigsaw-dev mailing list submissions to jigsaw-dev at openjdk.java.net To subscribe or unsubscribe via the World Wide Web, visit http://mail.openjdk.java.net/mailman/listinfo/jigsaw-dev or, via email, send a message with subject or body 'help' to jigsaw-dev-request at openjdk.java.net You can reach the person managing the list at jigsaw-dev-owner at openjdk.java.net When replying, please edit your Subject line so it is more specific than "Re: Contents of jigsaw-dev digest..." Today's Topics: 1. Re: Automatic module names (Robert Scholte) 2. hg: jigsaw/jake/jdk: 2 new changesets (alan.bateman at oracle.com) 3. Re: Automatic module names (David M. Lloyd) 4. Re: Automatic module names (Andrew Dinn) 5. Re: Automatic module names (Alan Bateman) 6. Re: Automatic module names - "requires package" proposal (Stephen Colebourne) ---------------------------------------------------------------------- Message: 1 Date: Fri, 03 Feb 2017 12:44:38 +0100 From: "Robert Scholte" To: jigsaw-dev at openjdk.java.net Subject: Re: Automatic module names Message-ID: Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes Hi Nicolai, let's consider that my project depends on the following dependencies: com.foo.bar:library:1.0 and com.acme:library:2.3.1, both unnamed. I somehow want to have them both as requirements: module M.N { requires static library; // com.foo.bar:library requires library; // com.acme:library } How can I define that the 'requires static library' should be mapped to com.foo.bar:library:1.0 on the modulepath, while 'requires library' should be mapped to com.acme:library:2.3.1 One ugly solution would be: requires static library containing com.foo.bar.baz.SomeClass; requires library containing acme.AnotherClass; We should really wonder if ease-of-transition is worth the minefield we're creating with the introduction of automodules. IMHO all options we're trying to add to keep automodules will only over-complicate things, not even being sure if all edges are covered. thanks, Robert On Thu, 02 Feb 2017 12:28:13 +0100, Nicolai Parlog wrote: > Hi everyone, > > after thinking about this a little longer, I came to the conclusion that > compile-time/launch-time aliasing might be the only way out of this (at > least the only I could come up with) that keeps automatic modules alive > and does not introduce a conceptual dependency on Maven. > > The idea: > > A command line option, let's say `--alias-modules A=X`, maps module name > A to module name X. Every dependency on either A or X will be resolved > to X, implying that there must a module X in the universe of observable > modules. There can be several aliases for the same module > (`--alias-modules A=X,B=X`; X needs to be observable) and they can be > chained (`--alias-modules A=X,X=Y`; Y needs to be observable) > > Aliasing would of course have to be applied to qualified exports, opens, > and similar mechanisms as well. > > It might be worth adding the rule that no observable module must have an > aliased name. So for `--alias-modules A=X` there must be no observable > module A. This prevents ambiguity and would effectively prevent aliasing > platform modules. That might be a good thing because it looks like > aliasing and upgrading modules has quite some overlap (or is even > identical?) > > Unfortunately I could not come up with a way to limit aliasing to > automatic module names (in case that were desirable) without somehow > marking dependencies on automatic modules, likely in the module > declaration. If changing module declaration syntax is still on the > table, it could be changed so that dependencies on automatic modules > must be phrased as something like `requires automatic`. > > The obvious semantics would be that only such requires clauses can be > fulfilled with automatic modules and that only such dependencies could > be aliased (this might make it prudent to phrase the aliasing option > accordingly, e.g. `--alias-automatic-modules`). > > This could also be used to help developers in keeping their module > declarations clean: The compiler could to emit a warning if a `requires > automatic` clause is fulfilled by a regular module. > > I would love to hear some thoughts on this idea, even if it considered > to be stupid, impractical,etc. :) > > so long ... Nicolai > > > > On 27.01.2017 15:11, Stephen Colebourne wrote: >> Back in October, I raised the issue of modules names generally and for >> automatic modules specifically [1]. The short thread came to no >> conclusion, but recent threads have again raised similar problems. The >> problem is that automatic modules have magical name creation from a >> filename, which is brittle and unlike anything else in Java. >> >> I also recently looked at the Joda-Convert and Joda-Beans libraries, >> to see if I could add module-info in preparation for Java 9. I quickly >> backed away, again because of the same issue. Put simply, I am >> unwilling to write a module-info file that refers to a dependency that >> is not yet a module. And I have to advise all open source projects to >> do the same. Given this, there can be no simple migration to the JPMS >> for open source projects. Each open source project must wait for all >> its dependencies to migrate to JPMS (by adding a module-info and >> publishing to Maven Central). >> >> The issue is clear. If I write this: >> >> module org.joda.convert { >> requires guava; >> } >> >> where guava is an automatic module, I am locking in the name of the >> guava dependency, something that I do not control. The name "guava" is >> just a guess. The guava authors might choose "com.google.guava" or >> something else entirely. >> >> In a closed system of modules, ie. a private application, automatic >> modules are fine, because the requires clause can be changed if it >> turns out the guess was wrong. But once published as an open source >> project to Maven Central or elsewhere, the guess cannot be fixed if it >> is wrong (without releasing a new version of the library, which is not >> an acceptable solution). >> >> I also strongly believe that module names cannot be flat and >> unstructured, such as "joda-convert" or "guava". They must have >> structure, such as the domain name or a Maven-style group name >> "org.joda.convert" or "org.joda:joda-convert". The potential for >> clashes has been shown by the Maven team [2]. >> >> Some brainstormed possible changes: >> >> - Remove the automatic module concept altogether >> >> - Define a clear mapping from Maven Central co-ordinates to module >> name that includes the group, artifact and classifier >> >> - Provide a text file to JPMS that allows incorrect module names to be >> mapped to the correct name >> >> - Publicly advise against using automatic modules for open source >> projects >> >> - Change rules of Maven Central to prevent modular jars being added >> that depend on an automatic module >> >> - Allow requires clauses to have aliases - requires org.guava.guava OR >> guava. >> >> - Allow modules to have aliases - module org.guava.guava AKA guava >> >> >> Given that applications can depend on libraries that haven't been >> released in years, this has the potential to be a critical problem for >> the ecosystem. My preference remains to define a clear mapping from >> the widely adopted Maven Central naming strategy to JPMS modules. >> Ideally, this would be a formal group concept in the JPMS, something >> that I believe is sorely lacking. >> >> Stephen >> >> [1] >> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016- October/009631.html >> [2] >> http://mail.openjdk.java.net/pipermail/jpms-spec-observers/ 2017-January/000707.html >> ------------------------------ Message: 2 Date: Fri, 03 Feb 2017 12:07:09 +0000 From: alan.bateman at oracle.com To: jigsaw-dev at openjdk.java.net Subject: hg: jigsaw/jake/jdk: 2 new changesets Message-ID: <201702031207.v13C79kt021495 at aojmv0008.oracle.com> Changeset: a0a6f078fefe Author: alanb Date: 2017-02-03 12:06 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a0a6f078fefe Tighten up ModuleReader for exploded modules ! src/java.base/share/classes/java/lang/module/ModuleReader.java ! src/java.base/share/classes/jdk/internal/loader/ResourceHelper.java ! test/java/lang/module/ModuleReader/ModuleReaderTest.java Changeset: ee81e3ab4655 Author: alanb Date: 2017-02-03 12:06 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ee81e3ab4655 Minor SL javadoc update ! src/java.base/share/classes/java/util/ServiceLoader.java ------------------------------ Message: 3 Date: Fri, 3 Feb 2017 08:29:02 -0600 From: "David M. Lloyd" To: jigsaw-dev at openjdk.java.net Subject: Re: Automatic module names Message-ID: <54002ec6-be4d-ec33-6e60-8b5e1fb91a33 at redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed I think one option we should consider is to perhaps disable automatic modules for 9 and revisit the idea for 10, as it's late in the day and still clearly not settled. On 02/03/2017 05:44 AM, Robert Scholte wrote: > Hi Nicolai, > > let's consider that my project depends on the following dependencies: > com.foo.bar:library:1.0 and com.acme:library:2.3.1, both unnamed. > > I somehow want to have them both as requirements: > module M.N { > requires static library; // com.foo.bar:library > requires library; // com.acme:library > } > > How can I define that the 'requires static library' should be mapped to > com.foo.bar:library:1.0 on the modulepath, while 'requires library' > should be mapped to com.acme:library:2.3.1 > > One ugly solution would be: > requires static library containing com.foo.bar.baz.SomeClass; > requires library containing acme.AnotherClass; > > We should really wonder if ease-of-transition is worth the minefield > we're creating with the introduction of automodules. IMHO all options > we're trying to add to keep automodules will only over-complicate > things, not even being sure if all edges are covered. > > thanks, > Robert > > On Thu, 02 Feb 2017 12:28:13 +0100, Nicolai Parlog wrote: > >> Hi everyone, >> >> after thinking about this a little longer, I came to the conclusion that >> compile-time/launch-time aliasing might be the only way out of this (at >> least the only I could come up with) that keeps automatic modules alive >> and does not introduce a conceptual dependency on Maven. >> >> The idea: >> >> A command line option, let's say `--alias-modules A=X`, maps module name >> A to module name X. Every dependency on either A or X will be resolved >> to X, implying that there must a module X in the universe of observable >> modules. There can be several aliases for the same module >> (`--alias-modules A=X,B=X`; X needs to be observable) and they can be >> chained (`--alias-modules A=X,X=Y`; Y needs to be observable) >> >> Aliasing would of course have to be applied to qualified exports, opens, >> and similar mechanisms as well. >> >> It might be worth adding the rule that no observable module must have an >> aliased name. So for `--alias-modules A=X` there must be no observable >> module A. This prevents ambiguity and would effectively prevent aliasing >> platform modules. That might be a good thing because it looks like >> aliasing and upgrading modules has quite some overlap (or is even >> identical?) >> >> Unfortunately I could not come up with a way to limit aliasing to >> automatic module names (in case that were desirable) without somehow >> marking dependencies on automatic modules, likely in the module >> declaration. If changing module declaration syntax is still on the >> table, it could be changed so that dependencies on automatic modules >> must be phrased as something like `requires automatic`. >> >> The obvious semantics would be that only such requires clauses can be >> fulfilled with automatic modules and that only such dependencies could >> be aliased (this might make it prudent to phrase the aliasing option >> accordingly, e.g. `--alias-automatic-modules`). >> >> This could also be used to help developers in keeping their module >> declarations clean: The compiler could to emit a warning if a `requires >> automatic` clause is fulfilled by a regular module. >> >> I would love to hear some thoughts on this idea, even if it considered >> to be stupid, impractical,etc. :) >> >> so long ... Nicolai >> >> >> >> On 27.01.2017 15:11, Stephen Colebourne wrote: >>> Back in October, I raised the issue of modules names generally and for >>> automatic modules specifically [1]. The short thread came to no >>> conclusion, but recent threads have again raised similar problems. The >>> problem is that automatic modules have magical name creation from a >>> filename, which is brittle and unlike anything else in Java. >>> >>> I also recently looked at the Joda-Convert and Joda-Beans libraries, >>> to see if I could add module-info in preparation for Java 9. I quickly >>> backed away, again because of the same issue. Put simply, I am >>> unwilling to write a module-info file that refers to a dependency that >>> is not yet a module. And I have to advise all open source projects to >>> do the same. Given this, there can be no simple migration to the JPMS >>> for open source projects. Each open source project must wait for all >>> its dependencies to migrate to JPMS (by adding a module-info and >>> publishing to Maven Central). >>> >>> The issue is clear. If I write this: >>> >>> module org.joda.convert { >>> requires guava; >>> } >>> >>> where guava is an automatic module, I am locking in the name of the >>> guava dependency, something that I do not control. The name "guava" is >>> just a guess. The guava authors might choose "com.google.guava" or >>> something else entirely. >>> >>> In a closed system of modules, ie. a private application, automatic >>> modules are fine, because the requires clause can be changed if it >>> turns out the guess was wrong. But once published as an open source >>> project to Maven Central or elsewhere, the guess cannot be fixed if it >>> is wrong (without releasing a new version of the library, which is not >>> an acceptable solution). >>> >>> I also strongly believe that module names cannot be flat and >>> unstructured, such as "joda-convert" or "guava". They must have >>> structure, such as the domain name or a Maven-style group name >>> "org.joda.convert" or "org.joda:joda-convert". The potential for >>> clashes has been shown by the Maven team [2]. >>> >>> Some brainstormed possible changes: >>> >>> - Remove the automatic module concept altogether >>> >>> - Define a clear mapping from Maven Central co-ordinates to module >>> name that includes the group, artifact and classifier >>> >>> - Provide a text file to JPMS that allows incorrect module names to be >>> mapped to the correct name >>> >>> - Publicly advise against using automatic modules for open source >>> projects >>> >>> - Change rules of Maven Central to prevent modular jars being added >>> that depend on an automatic module >>> >>> - Allow requires clauses to have aliases - requires org.guava.guava >>> OR guava. >>> >>> - Allow modules to have aliases - module org.guava.guava AKA guava >>> >>> >>> Given that applications can depend on libraries that haven't been >>> released in years, this has the potential to be a critical problem for >>> the ecosystem. My preference remains to define a clear mapping from >>> the widely adopted Maven Central naming strategy to JPMS modules. >>> Ideally, this would be a formal group concept in the JPMS, something >>> that I believe is sorely lacking. >>> >>> Stephen >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016- October/009631.html >>> >>> [2] >>> http://mail.openjdk.java.net/pipermail/jpms-spec-observers/ 2017-January/000707.html >>> >>> -- - DML ------------------------------ Message: 4 Date: Fri, 3 Feb 2017 14:43:41 +0000 From: Andrew Dinn To: "David M. Lloyd" , jigsaw-dev at openjdk.java.net Subject: Re: Automatic module names Message-ID: <5ba1ec95-4382-d38f-1e0f-0e5509179c39 at redhat.com> Content-Type: text/plain; charset=utf-8 On 03/02/17 14:29, David M. Lloyd wrote: > I think one option we should consider is to perhaps disable automatic > modules for 9 and revisit the idea for 10, as it's late in the day and > still clearly not settled. I don't think this is thinking about the trade-off correctly. Automatic modules may not work for some (or maybe many) of the more complicated cases but those failures can be addressed over time by adding a module.xml to update releases of jars. Automatic modules definitely does work for straightforward cases to provide an easy way of deploying jars you don't own/can't rewrite as modules. Much as I admit that there are going to be lots of cases where it will fail I think those where it just works will still be a large subset. So, automatic modules will definitely be a big help to a lot of users who want to get started with Jigsaw. And, well, maybe I need to say this -- yes, an easy start is a /big/ priority. That's merely 2 cents, gratis. Your mileage may vary, particularly when it fails for your app. But I don't the mere possibility of the latter as a reason to poop on someone (everyone?) else's parade. regards, Andrew Dinn ----------- ------------------------------ Message: 5 Date: Fri, 3 Feb 2017 15:40:43 +0000 From: Alan Bateman To: Robert Scholte , jigsaw-dev at openjdk.java.net Subject: Re: Automatic module names Message-ID: <617664d5-8ea6-1be8-7790-8d7ecd669e96 at oracle.com> Content-Type: text/plain; charset=iso-8859-15; format=flowed On 03/02/2017 11:44, Robert Scholte wrote: > Hi Nicolai, > > let's consider that my project depends on the following dependencies: > com.foo.bar:library:1.0 and com.acme:library:2.3.1, both unnamed. > > I somehow want to have them both as requirements: > module M.N { > requires static library; // com.foo.bar:library > requires library; // com.acme:library > } > > How can I define that the 'requires static library' should be mapped > to com.foo.bar:library:1.0 on the modulepath, while 'requires library' > should be mapped to com.acme:library:2.3.1 > > One ugly solution would be: > requires static library containing com.foo.bar.baz.SomeClass; > requires library containing acme.AnotherClass; > > We should really wonder if ease-of-transition is worth the minefield > we're creating with the introduction of automodules. IMHO all options > we're trying to add to keep automodules will only over-complicate > things, not even being sure if all edges are covered. I think automatic modules are critical to migration, otherwise things move at the pace of the slowest project (which might be 0km/h in case of unmaintained projects). A lot of the discussion here has been on the naming but automatic modules but the other important benefit of automatic modules is that they support bridging to the class path. As regards the example naming clash then these two projects might already get complaints over their poor choice of artifacts, esp. when artifacts for both projects are in same directory (say where someone distributes with all JAR files in a `lib` directory). -Alan ------------------------------ Message: 6 Date: Fri, 3 Feb 2017 16:34:11 +0000 From: Stephen Colebourne To: jigsaw-dev Subject: Re: Automatic module names - "requires package" proposal Message-ID: Content-Type: text/plain; charset=UTF-8 On 3 February 2017 at 15:40, Alan Bateman wrote: > I think automatic modules are critical to migration, otherwise things move > at the pace of the slowest project (which might be 0km/h in case of > unmaintained projects). A lot of the discussion here has been on the naming > but automatic modules but the other important benefit of automatic modules > is that they support bridging to the class path. > > As regards the example naming clash then these two projects might already > get complaints over their poor choice of artifacts, esp. when artifacts for > both projects are in same directory (say where someone distributes with all > JAR files in a `lib` directory). We can't close our eyes to this problem. There can be naming clashes as above, naming problems due to having to guess a project's choice of a module name. We need to take the guesswork out, and have something based on Java compilation elements. As such, I'd like to propose an alternative based on packages that could still be feasible in the time available: 1) Have two types of `requires` clause - one for modules and one for packages 2) When requiring a package, that package must be available, either on the classpath or in a module 3) When requiring a package, the package must not be found in a module that is explicitly referenced 4) Fully modularized applications do not have `requires package` - this is a migration feature like `open modules` module com.org.a { // dependency on a module (modular jar) requires module com.org.b; requires module com.org.c; // dependency on packages (modular jar or classpath) requires package com.org.d; requires package com.org.d.x; requires package com.org.d.y; } In the example above, the three explicitly specified packages must not be found in module `com.org.b` or `com.org.c` (rule #3). They must instead be found in a jar on the classpath (each package must be found only in one jar), or in a future module (which could have any name, not just `com.org.d` or `d`). The `requires package` provides the "bridge" to the classpath and older jars that is desired, without the mess of automatic modules. Note that there would be no automatic modules as currently planned in this proposal. (FWIW, in the implementation, I'd imagine that each required package would be created as a separate module, using the same openess/security design as automatic modules today) Stephen End of jigsaw-dev Digest, Vol 87, Issue 6 ***************************************** From Alan.Bateman at oracle.com Sat Feb 4 07:02:06 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 4 Feb 2017 07:02:06 +0000 Subject: ClassLoader.getResource("mypackageroot") fails against exploded module In-Reply-To: References: Message-ID: On 03/02/2017 18:17, Juergen Hoeller wrote: > Spring's classpath scanning works fine on JDK 9 for classpath resources > (archives as well directories) and also for archives on the module path. > One API to look at for scanning the module path is ModuleFinder.of(Path...). That will give you the set of packages in each module. If you want to go deeper then you can open the modules to get a ModuleReader and list/find all the resources in the module. -Alan From nipa at codefx.org Sat Feb 4 07:17:31 2017 From: nipa at codefx.org (Nicolai Parlog) Date: Sat, 4 Feb 2017 08:17:31 +0100 Subject: Automatic module names In-Reply-To: <54002ec6-be4d-ec33-6e60-8b5e1fb91a33@redhat.com> References: <55f73bef-657f-8669-4969-0830d5119b72@codefx.org> <54002ec6-be4d-ec33-6e60-8b5e1fb91a33@redhat.com> Message-ID: Hi! > I think one option we should consider is to perhaps disable automatic > modules for 9 and revisit the idea for 10, as it's late in the day and > still clearly not settled. I disagree. The idea that modules should not depend "on the chaos of the class path" seems to be a very good one. This makes the compile and run time behavior of JARs that do have a descriptor much more predictable thatn otherwise. To that end, I like how automatic modules act as a buffer zone between the modularized application and its unmodularized dependencies. Hence my assumption to keep automatic modules working. so long ... Nicolai On 03.02.2017 15:29, David M. Lloyd wrote: > I think one option we should consider is to perhaps disable automatic > modules for 9 and revisit the idea for 10, as it's late in the day and > still clearly not settled. > > On 02/03/2017 05:44 AM, Robert Scholte wrote: >> Hi Nicolai, >> >> let's consider that my project depends on the following dependencies: >> com.foo.bar:library:1.0 and com.acme:library:2.3.1, both unnamed. >> >> I somehow want to have them both as requirements: >> module M.N { >> requires static library; // com.foo.bar:library >> requires library; // com.acme:library >> } >> >> How can I define that the 'requires static library' should be mapped to >> com.foo.bar:library:1.0 on the modulepath, while 'requires library' >> should be mapped to com.acme:library:2.3.1 >> >> One ugly solution would be: >> requires static library containing com.foo.bar.baz.SomeClass; >> requires library containing acme.AnotherClass; >> >> We should really wonder if ease-of-transition is worth the minefield >> we're creating with the introduction of automodules. IMHO all options >> we're trying to add to keep automodules will only over-complicate >> things, not even being sure if all edges are covered. >> >> thanks, >> Robert >> >> On Thu, 02 Feb 2017 12:28:13 +0100, Nicolai Parlog >> wrote: >> >>> Hi everyone, >>> >>> after thinking about this a little longer, I came to the conclusion that >>> compile-time/launch-time aliasing might be the only way out of this (at >>> least the only I could come up with) that keeps automatic modules alive >>> and does not introduce a conceptual dependency on Maven. >>> >>> The idea: >>> >>> A command line option, let's say `--alias-modules A=X`, maps module name >>> A to module name X. Every dependency on either A or X will be resolved >>> to X, implying that there must a module X in the universe of observable >>> modules. There can be several aliases for the same module >>> (`--alias-modules A=X,B=X`; X needs to be observable) and they can be >>> chained (`--alias-modules A=X,X=Y`; Y needs to be observable) >>> >>> Aliasing would of course have to be applied to qualified exports, opens, >>> and similar mechanisms as well. >>> >>> It might be worth adding the rule that no observable module must have an >>> aliased name. So for `--alias-modules A=X` there must be no observable >>> module A. This prevents ambiguity and would effectively prevent aliasing >>> platform modules. That might be a good thing because it looks like >>> aliasing and upgrading modules has quite some overlap (or is even >>> identical?) >>> >>> Unfortunately I could not come up with a way to limit aliasing to >>> automatic module names (in case that were desirable) without somehow >>> marking dependencies on automatic modules, likely in the module >>> declaration. If changing module declaration syntax is still on the >>> table, it could be changed so that dependencies on automatic modules >>> must be phrased as something like `requires automatic`. >>> >>> The obvious semantics would be that only such requires clauses can be >>> fulfilled with automatic modules and that only such dependencies could >>> be aliased (this might make it prudent to phrase the aliasing option >>> accordingly, e.g. `--alias-automatic-modules`). >>> >>> This could also be used to help developers in keeping their module >>> declarations clean: The compiler could to emit a warning if a `requires >>> automatic` clause is fulfilled by a regular module. >>> >>> I would love to hear some thoughts on this idea, even if it considered >>> to be stupid, impractical,etc. :) >>> >>> so long ... Nicolai >>> >>> >>> >>> On 27.01.2017 15:11, Stephen Colebourne wrote: >>>> Back in October, I raised the issue of modules names generally and for >>>> automatic modules specifically [1]. The short thread came to no >>>> conclusion, but recent threads have again raised similar problems. The >>>> problem is that automatic modules have magical name creation from a >>>> filename, which is brittle and unlike anything else in Java. >>>> >>>> I also recently looked at the Joda-Convert and Joda-Beans libraries, >>>> to see if I could add module-info in preparation for Java 9. I quickly >>>> backed away, again because of the same issue. Put simply, I am >>>> unwilling to write a module-info file that refers to a dependency that >>>> is not yet a module. And I have to advise all open source projects to >>>> do the same. Given this, there can be no simple migration to the JPMS >>>> for open source projects. Each open source project must wait for all >>>> its dependencies to migrate to JPMS (by adding a module-info and >>>> publishing to Maven Central). >>>> >>>> The issue is clear. If I write this: >>>> >>>> module org.joda.convert { >>>> requires guava; >>>> } >>>> >>>> where guava is an automatic module, I am locking in the name of the >>>> guava dependency, something that I do not control. The name "guava" is >>>> just a guess. The guava authors might choose "com.google.guava" or >>>> something else entirely. >>>> >>>> In a closed system of modules, ie. a private application, automatic >>>> modules are fine, because the requires clause can be changed if it >>>> turns out the guess was wrong. But once published as an open source >>>> project to Maven Central or elsewhere, the guess cannot be fixed if it >>>> is wrong (without releasing a new version of the library, which is not >>>> an acceptable solution). >>>> >>>> I also strongly believe that module names cannot be flat and >>>> unstructured, such as "joda-convert" or "guava". They must have >>>> structure, such as the domain name or a Maven-style group name >>>> "org.joda.convert" or "org.joda:joda-convert". The potential for >>>> clashes has been shown by the Maven team [2]. >>>> >>>> Some brainstormed possible changes: >>>> >>>> - Remove the automatic module concept altogether >>>> >>>> - Define a clear mapping from Maven Central co-ordinates to module >>>> name that includes the group, artifact and classifier >>>> >>>> - Provide a text file to JPMS that allows incorrect module names to be >>>> mapped to the correct name >>>> >>>> - Publicly advise against using automatic modules for open source >>>> projects >>>> >>>> - Change rules of Maven Central to prevent modular jars being added >>>> that depend on an automatic module >>>> >>>> - Allow requires clauses to have aliases - requires org.guava.guava >>>> OR guava. >>>> >>>> - Allow modules to have aliases - module org.guava.guava AKA guava >>>> >>>> >>>> Given that applications can depend on libraries that haven't been >>>> released in years, this has the potential to be a critical problem for >>>> the ecosystem. My preference remains to define a clear mapping from >>>> the widely adopted Maven Central naming strategy to JPMS modules. >>>> Ideally, this would be a formal group concept in the JPMS, something >>>> that I believe is sorely lacking. >>>> >>>> Stephen >>>> >>>> [1] >>>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-October/009631.html >>>> >>>> >>>> [2] >>>> http://mail.openjdk.java.net/pipermail/jpms-spec-observers/2017-January/000707.html >>>> >>>> >>>> > -- PGP Key: http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509 Web: http://codefx.org a blog about software development https://www.sitepoint.com/java high-quality Java/JVM content http://do-foss.de Free and Open Source Software for the City of Dortmund Twitter: https://twitter.com/nipafx From alan.bateman at oracle.com Sat Feb 4 07:29:29 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 04 Feb 2017 07:29:29 +0000 Subject: hg: jigsaw/jake/hotspot: VerifyMethodHandles can't verify access check without lookup modes when caller is jl.Object Message-ID: <201702040729.v147TTjD002680@aojmv0008.oracle.com> Changeset: cca505877738 Author: alanb Date: 2017-02-04 07:28 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/cca505877738 VerifyMethodHandles can't verify access check without lookup modes when caller is jl.Object ! src/share/vm/prims/methodHandles.cpp From ali.ebrahimi1781 at gmail.com Sat Feb 4 08:13:01 2017 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Sat, 4 Feb 2017 11:43:01 +0330 Subject: Automatic module names In-Reply-To: <58af7789-f927-9112-6835-e4e941a9f1e1@oracle.com> References: <55f73bef-657f-8669-4969-0830d5119b72@codefx.org> <54002ec6-be4d-ec33-6e60-8b5e1fb91a33@redhat.com> <5ba1ec95-4382-d38f-1e0f-0e5509179c39@redhat.com> <9acbac2f-21b6-c734-f14e-b42eb875e8e2@redhat.com> <58af7789-f927-9112-6835-e4e941a9f1e1@oracle.com> Message-ID: Hi, The name clash problems can be easily resolved with an optional module group property for modules As same thing we currently have for classes: FQN class = pkg name + class simple name The same mechanism can work for modules. FQN module = group name + module simple name This solution very nicely fits with maven repository layout and can avoid name clash problems. The group name as with package name is optional for modules. module java:java.base{ //group name = java } module jdk:jdk.jlink{ //group name = jdk } ... module stax :stax { //group name = stax ... } module codehaus-stax: stax { //group name = codehaus-stax ... } module m1{ requires stax :stax; } module m2{ requires codehaus-stax: stax ; } module path layout: $module_path_root/codehaus-stax/stax-1.1.1.jar $module_path_root/stax/stax-1.2.0.jar $module_path_root/m1-1.0.jar $module_path_root/m2-1.0.jar ... (Assuming m1 and m2 valid module names) The format for module path entries is as: [group/]module-*.jar;.... What do you think? Module groups can help wrt overlapping package modules problem. On Fri, Feb 3, 2017 at 9:12 PM, Alan Bateman wrote: > On 03/02/2017 16:42, David M. Lloyd wrote: > > : >> >> Sure, but the set of JARs you can't rewrite is really pretty spare. >> > > I've no doubt that many people would be uncomfortable taking > responsibility to modularize a component that they don't maintain or have > full knowledge of. In the early exploration phase of Project Jigsaw then we > have some basic tooling to help with exactly that approach but it has long > been left behind. One reason is that potential for anarchy with several > people converting the same library to a module. You might not like > automatic modules but at least the module descriptors that are derived are > very predictable (including the name). > > -Alan. > -- Best Regards, Ali Ebrahimi From alan.bateman at oracle.com Sat Feb 4 09:24:35 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 04 Feb 2017 09:24:35 +0000 Subject: hg: jigsaw/jake/hotspot: Temporarily exclude serviceability/jvmti/ModuleAwareAgents/ClassFileLoadHook/MAAClassFileLoadHook.java Message-ID: <201702040924.v149OZmq001769@aojmv0008.oracle.com> Changeset: 1253589518e6 Author: alanb Date: 2017-02-04 09:24 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1253589518e6 Temporarily exclude serviceability/jvmti/ModuleAwareAgents/ClassFileLoadHook/MAAClassFileLoadHook.java ! test/ProblemList.txt From uschindler at apache.org Sat Feb 4 09:50:10 2017 From: uschindler at apache.org (Uwe Schindler) Date: Sat, 04 Feb 2017 09:50:10 +0000 Subject: ClassLoader.getResource("mypackageroot") fails against exploded module In-Reply-To: References: Message-ID: <41EDA908-719D-42BD-A022-7E35FEED4978@apache.org> Hi, Would this somehow also work on the unnamed module? This would be a solution for the long ongoing discussion, how to figure out what classes and resources exist on classpath. Because all of current solutions are hacks and API misuse. E.g., get your own module (which could be unnamed) and then list all packages and resources in them. Uwe Am 4. Februar 2017 08:02:06 MEZ schrieb Alan Bateman : >On 03/02/2017 18:17, Juergen Hoeller wrote: > >> Spring's classpath scanning works fine on JDK 9 for classpath >resources >> (archives as well directories) and also for archives on the module >path. >> >One API to look at for scanning the module path is >ModuleFinder.of(Path...). That will give you the set of packages in >each >module. If you want to go deeper then you can open the modules to get a > >ModuleReader and list/find all the resources in the module. > >-Alan From alan.bateman at oracle.com Sat Feb 4 20:34:55 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 04 Feb 2017 20:34:55 +0000 Subject: hg: jigsaw/jake/hotspot: 8171855: Move package name transformations during module bootstrap into native code Message-ID: <201702042034.v14KYtAl022356@aojmv0008.oracle.com> Changeset: 06ac5be1915a Author: redestad Date: 2017-01-19 11:49 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/06ac5be1915a 8171855: Move package name transformations during module bootstrap into native code Reviewed-by: alanb, acorn, lfoltan, mchung, plevart, hseigel, sspitsyn ! make/symbols/symbols-unix ! src/share/vm/classfile/modules.cpp ! src/share/vm/classfile/modules.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/whitebox.cpp From alan.bateman at oracle.com Sat Feb 4 20:34:58 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 04 Feb 2017 20:34:58 +0000 Subject: hg: jigsaw/jake/jdk: 2 new changesets Message-ID: <201702042034.v14KYwg6022360@aojmv0008.oracle.com> Changeset: 66314bb37612 Author: alanb Date: 2017-02-04 20:20 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/66314bb37612 test/java/io/FilePermission/ReadFileOnPath.java failing ! test/java/io/FilePermission/ReadFileOnPath.java Changeset: 84a53a5ce162 Author: alanb Date: 2017-02-04 20:31 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/84a53a5ce162 Import merge of JDK-8171855 ! src/java.base/share/classes/java/lang/reflect/Module.java ! src/java.base/share/native/include/jvm.h ! src/java.base/share/native/libjava/Module.c From bburd at drew.edu Sat Feb 4 21:57:36 2017 From: bburd at drew.edu (Barry Burd) Date: Sat, 4 Feb 2017 16:57:36 -0500 Subject: Current list of new (contextual) keywords Message-ID: <15bf9254-e8a9-8def-27bd-d8e0027bc416@drew.edu> Is there an up-to-date list of keywords (contextual or otherwise) being added to Java for Project Jigsaw (or for Java 9 in general)? From forax at univ-mlv.fr Sat Feb 4 23:21:05 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 5 Feb 2017 00:21:05 +0100 (CET) Subject: Current list of new (contextual) keywords In-Reply-To: <15bf9254-e8a9-8def-27bd-d8e0027bc416@drew.edu> References: <15bf9254-e8a9-8def-27bd-d8e0027bc416@drew.edu> Message-ID: <1630654997.2689078.1486250465489.JavaMail.zimbra@u-pem.fr> Hi Barry, from http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html#jigsaw-1.1, open, module, requires, exports, to, opens, uses, provides, with, transitive cheers, R?mi ----- Mail original ----- > De: "Barry Burd" > ?: jigsaw-dev at openjdk.java.net > Envoy?: Samedi 4 F?vrier 2017 22:57:36 > Objet: Current list of new (contextual) keywords > Is there an up-to-date list of keywords (contextual or otherwise) being > added to Java for Project Jigsaw (or for Java 9 in general)? From mandy.chung at oracle.com Sat Feb 4 23:41:35 2017 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Sat, 04 Feb 2017 23:41:35 +0000 Subject: hg: jigsaw/jake/jdk: Add AccessibleObject::canAccess and trySetAccessible Message-ID: <201702042341.v14NfZ4S029057@aojmv0008.oracle.com> Changeset: 335657c73d0b Author: mchung Date: 2017-02-04 15:41 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/335657c73d0b Add AccessibleObject::canAccess and trySetAccessible ! src/java.base/share/classes/java/lang/SecurityManager.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java ! src/java.base/share/classes/java/security/Security.java ! src/java.base/share/classes/jdk/internal/misc/JavaLangAccess.java + test/java/lang/reflect/AccessibleObject/CanAccessTest.java + test/java/lang/reflect/AccessibleObject/TrySetAccessibleTest.java From mandy.chung at oracle.com Sun Feb 5 04:39:01 2017 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Sun, 05 Feb 2017 04:39:01 +0000 Subject: hg: jigsaw/jake/jdk: 2 new changesets Message-ID: <201702050439.v154d1vC028464@aojmv0008.oracle.com> Changeset: cd7842eb7d8d Author: mchung Date: 2017-02-04 17:24 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/cd7842eb7d8d Minor cleanup ! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java Changeset: c741bb5b6652 Author: mchung Date: 2017-02-04 20:38 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c741bb5b6652 Add a test to check @CS methods + test/jdk/internal/reflect/CallerSensitive/CheckCSMs.java From alan.bateman at oracle.com Sun Feb 5 18:25:24 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 05 Feb 2017 18:25:24 +0000 Subject: hg: jigsaw/jake/jdk: 3 new changesets Message-ID: <201702051825.v15IPOwL017268@aojmv0008.oracle.com> Changeset: 271f46005c51 Author: alanb Date: 2017-02-05 15:11 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/271f46005c51 Fix inconsistencies with JAR/JMOD readers ! src/java.base/share/classes/java/lang/module/ModuleReader.java ! src/java.base/share/classes/jdk/internal/jmod/JmodFile.java ! src/java.base/share/classes/jdk/internal/module/ModuleReferences.java ! test/java/lang/module/ModuleReader/ModuleReaderTest.java ! test/java/lang/module/MultiReleaseJarTest.java Changeset: a65cbb0aa676 Author: alanb Date: 2017-02-05 15:12 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a65cbb0aa676 More javadoc clean-up ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java ! src/java.base/share/classes/java/util/ServiceLoader.java Changeset: e57166d5ccf5 Author: alanb Date: 2017-02-05 15:29 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e57166d5ccf5 Temporarily exclude sun/tools/jstat/jstatClassloadOutput1.sh ! test/ProblemList.txt From alan.bateman at oracle.com Sun Feb 5 19:57:40 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 05 Feb 2017 19:57:40 +0000 Subject: hg: jigsaw/jake/jdk: @ in summary treated as jtreg tag Message-ID: <201702051957.v15JveoZ007510@aojmv0008.oracle.com> Changeset: 0c2cb8860b14 Author: alanb Date: 2017-02-05 19:57 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0c2cb8860b14 @ in summary treated as jtreg tag ! test/jdk/internal/reflect/CallerSensitive/CheckCSMs.java From gunnar at hibernate.org Mon Feb 6 08:41:56 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Mon, 6 Feb 2017 09:41:56 +0100 Subject: Adding module descriptor to existing JAR file Message-ID: Hi, I'm trying to convert an existing non-modular JAR into a modular JAR. Using jdeps, I was able to generate a module-info.java descriptor for the module-to-be. And the help text of the "jar" command discusses how to add a compiled module descriptor to an existing JAR: jar --update --file foo.jar --main-class com.foo.Main --module-version 1.0 -C foo/ module-info.class I'm struggling though with compiling the module descriptor. I tried with --patch-module and also by providing the existing JAR via --class-path (as it's not a module yet), but javac is complaining about the exported packages from the module-info.java not being found: module-info.java:7: error: package is empty or does not exist: com.foo exports com.foo Is there an example somewhere that shows how to use javac for compiling a module descriptor, given the classes from a non-module JAR? I'm looking for a way without re-compiling that entire JAR, as I don't think that's practical or even possible in some cases. Thanks for any pointers, --Gunnar From Alan.Bateman at oracle.com Mon Feb 6 09:26:44 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 6 Feb 2017 09:26:44 +0000 Subject: Adding module descriptor to existing JAR file In-Reply-To: References: Message-ID: On 06/02/2017 08:41, Gunnar Morling wrote: > Hi, > > I'm trying to convert an existing non-modular JAR into a modular JAR. > > Using jdeps, I was able to generate a module-info.java descriptor for > the module-to-be. And the help text of the "jar" command discusses how > to add a compiled module descriptor to an existing JAR: > > jar --update --file foo.jar --main-class com.foo.Main --module-version 1.0 > -C foo/ module-info.class > > I'm struggling though with compiling the module descriptor. I tried > with --patch-module and also by providing the existing JAR via > --class-path (as it's not a module yet), but javac is complaining > about the exported packages from the module-info.java not being found: > > module-info.java:7: error: package is empty or does not exist: com.foo > exports com.foo > > Is there an example somewhere that shows how to use javac for > compiling a module descriptor, given the classes from a non-module > JAR? I'm looking for a way without re-compiling that entire JAR, as I > don't think that's practical or even possible in some cases. > If the classes in the module are in the output directory then javac should be able to compile the module-info.java. For the foo.jar example then I would expect this should work: mkdir classes (cd classes; jar xf ../foo.jar) javac -p -d classes module-info.java jar uf foo.jar -C classes module-info.class The recipe is similar to what one would do when compiling the classes for an older release and then compiling the module-info.java with a separate javac command. -Alan From webczat_200 at poczta.onet.pl Mon Feb 6 09:40:39 2017 From: webczat_200 at poczta.onet.pl (=?UTF-8?Q?Micha=c5=82_Zegan?=) Date: Mon, 6 Feb 2017 10:40:39 +0100 Subject: jigsaw and accessibility extensions Message-ID: Hello. Will java9 prevent accessibility extensions from working? Specifically, what I mean is the java access bridge enabling screenreaders to read java swing apps, that is along with jaccess.jar installed as an extension currently in jdk8. I also mean any 3'rd party bridge such as a bridge for linux system called java-atk-wrapper. From gunnar at hibernate.org Mon Feb 6 09:54:22 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Mon, 6 Feb 2017 10:54:22 +0100 Subject: Adding module descriptor to existing JAR file In-Reply-To: References: Message-ID: Hi Alan, Thanks for the quick reply. That does the trick. --Gunnar 2017-02-06 10:26 GMT+01:00 Alan Bateman : > On 06/02/2017 08:41, Gunnar Morling wrote: > >> Hi, >> >> I'm trying to convert an existing non-modular JAR into a modular JAR. >> >> Using jdeps, I was able to generate a module-info.java descriptor for >> the module-to-be. And the help text of the "jar" command discusses how >> to add a compiled module descriptor to an existing JAR: >> >> jar --update --file foo.jar --main-class com.foo.Main >> --module-version 1.0 >> -C foo/ module-info.class >> >> I'm struggling though with compiling the module descriptor. I tried >> with --patch-module and also by providing the existing JAR via >> --class-path (as it's not a module yet), but javac is complaining >> about the exported packages from the module-info.java not being found: >> >> module-info.java:7: error: package is empty or does not exist: >> com.foo >> exports com.foo >> >> Is there an example somewhere that shows how to use javac for >> compiling a module descriptor, given the classes from a non-module >> JAR? I'm looking for a way without re-compiling that entire JAR, as I >> don't think that's practical or even possible in some cases. >> > If the classes in the module are in the output directory then javac should > be able to compile the module-info.java. For the foo.jar example then I > would expect this should work: > > mkdir classes > (cd classes; jar xf ../foo.jar) > javac -p -d classes module-info.java > jar uf foo.jar -C classes module-info.class > > The recipe is similar to what one would do when compiling the classes for an > older release and then compiling the module-info.java with a separate javac > command. > > -Alan From Alan.Bateman at oracle.com Mon Feb 6 10:06:52 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 6 Feb 2017 10:06:52 +0000 Subject: jigsaw and accessibility extensions In-Reply-To: References: Message-ID: On 06/02/2017 09:40, Micha? Zegan wrote: > Hello. > > Will java9 prevent accessibility extensions from working? > Specifically, what I mean is the java access bridge enabling > screenreaders to read java swing apps, that is along with jaccess.jar > installed as an extension currently in jdk8. > I also mean any 3'rd party bridge such as a bridge for linux system > called java-atk-wrapper. > If by "extensions" then you mean the extension mechanism where you can drop JAR files into the JDK's "lib/ext" directory then that mechanism has been removed. JEP 220 [1] has more on that. As regards assistive technologies then you probably should check out the new SPI mechanism in javax.accessibility.AccessibilityProvider as that is the way to deploy with alternative or platform specific magnifiers and screen readers. The java.awt.Toolkit.getDefaultToolkit() method has some information on how this is configured. The jdk.accessibility module is probably also of interest as that has the Java Access Bridge. If you have follow-up questions on deploying accessibility providers then it's probably best to follow-up on the awt-dev mailing list. -Alan [1] http://openjdk.java.net/jeps/220 From Alan.Bateman at oracle.com Mon Feb 6 10:37:29 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 6 Feb 2017 10:37:29 +0000 Subject: [9] RFR 8170113: jimage extract to readonly directory causes MissingResourceException In-Reply-To: References: Message-ID: <98894b1b-5e2f-81a4-a7ed-de217560ec94@oracle.com> (cc'ing jigsaw-dev as that is where the jimage tool is maintained). On 06/02/2017 10:27, Denis Kononenko wrote: > Hi, > > Could someone please review this very small fix. > > The class JImageTask (src/jdk.jlink/share/classes/jdk/tools/jimage/JImageTask.java) has references to an info message by 'err.cannot.create.dir' key. Unfortunately the corresponding resource file (src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage.properties) doesn't contain this key. This results in long not user friendly stacktraces in output when jimage cannot create a directory. The fix is very small, I added the missing definition into the resource file. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8170113 > WEBREV: http://cr.openjdk.java.net/~dkononenko/8170113/webrev.00 > This looks okay as a short term fix but I think that extract need to be-implemented to use the new file system API so that the reasons why the directory can be printed too. Also there is an anomaly in errors related to the directory result in an error message whereas any errors extracting to the directory lead to an exception. -Alan From alan.bateman at oracle.com Mon Feb 6 14:47:33 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 06 Feb 2017 14:47:33 +0000 Subject: hg: jigsaw/jake/jdk: More javadoc cleanup Message-ID: <201702061447.v16ElXiB009741@aojmv0008.oracle.com> Changeset: 5b4f1b73efb2 Author: alanb Date: 2017-02-06 14:47 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5b4f1b73efb2 More javadoc cleanup ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java ! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java ! src/java.base/share/classes/java/lang/reflect/Proxy.java From rfscholte at apache.org Mon Feb 6 14:56:37 2017 From: rfscholte at apache.org (Robert Scholte) Date: Mon, 06 Feb 2017 15:56:37 +0100 Subject: Automatic module names In-Reply-To: References: Message-ID: On Fri, 27 Jan 2017 16:54:59 +0100, Robert Scholte wrote: > On Fri, 27 Jan 2017 15:11:14 +0100, Stephen Colebourne > wrote: > >> Back in October, I raised the issue of modules names generally and for >> automatic modules specifically [1]. The short thread came to no >> conclusion, but recent threads have again raised similar problems. The >> problem is that automatic modules have magical name creation from a >> filename, which is brittle and unlike anything else in Java. >> >> I also recently looked at the Joda-Convert and Joda-Beans libraries, >> to see if I could add module-info in preparation for Java 9. I quickly >> backed away, again because of the same issue. Put simply, I am >> unwilling to write a module-info file that refers to a dependency that >> is not yet a module. And I have to advise all open source projects to >> do the same. Given this, there can be no simple migration to the JPMS >> for open source projects. Each open source project must wait for all >> its dependencies to migrate to JPMS (by adding a module-info and >> publishing to Maven Central). >> >> The issue is clear. If I write this: >> >> module org.joda.convert { >> requires guava; >> } >> >> where guava is an automatic module, I am locking in the name of the >> guava dependency, something that I do not control. The name "guava" is >> just a guess. The guava authors might choose "com.google.guava" or >> something else entirely. >> >> In a closed system of modules, ie. a private application, automatic >> modules are fine, because the requires clause can be changed if it >> turns out the guess was wrong. But once published as an open source >> project to Maven Central or elsewhere, the guess cannot be fixed if it >> is wrong (without releasing a new version of the library, which is not >> an acceptable solution). >> >> I also strongly believe that module names cannot be flat and >> unstructured, such as "joda-convert" or "guava". They must have >> structure, such as the domain name or a Maven-style group name >> "org.joda.convert" or "org.joda:joda-convert". The potential for >> clashes has been shown by the Maven team [2]. >> >> Some brainstormed possible changes: >> >> - Remove the automatic module concept altogether > This matches proposal #2 and prevents all side effects of auto modules. > >> >> - Define a clear mapping from Maven Central co-ordinates to module >> name that includes the group, artifact and classifier > Who/where to maintain this? By OpenJDK or by Maven Central? And are > projects in the lead to specify such mapping entries? I have my doubts > if this will work. > >> >> - Provide a text file to JPMS that allows incorrect module names to be >> mapped to the correct name > Such information must be bundled as part of the module-info, otherwise > the next project using this jar as dependency will face the same > problems. > >> >> - Publicly advise against using automatic modules for open source >> projects > With Maven in mind, and especially the maven-compiler-plugin, this makes > sense when a module name cannot be mapped to a dependency, which means > it cannot decide if the jar should be on the classpath or modulepath. > >> >> - Change rules of Maven Central to prevent modular jars being added >> that depend on an automatic module > Quality gateway of Maven Central is a continuous improving set of rules, > I can imagine that analyzing the module-info would become another rule > >> >> - Allow requires clauses to have aliases - requires org.guava.guava OR >> guava. > Keep in mind there can be indirect requirements which names must be > adjusted as well. I don't think you want to add them as new requirements > to your project just to be able to add an alias. > >> >> - Allow modules to have aliases - module org.guava.guava AKA guava > I assume that this means that org.guave.guava is the only official > modulename, 'guava' can only be used in case of automodules. So if there > is another jar with "module guava {}", it does not map. > >> >> >> Given that applications can depend on libraries that haven't been >> released in years, this has the potential to be a critical problem for >> the ecosystem. My preference remains to define a clear mapping from >> the widely adopted Maven Central naming strategy to JPMS modules. >> Ideally, this would be a formal group concept in the JPMS, something >> that I believe is sorely lacking. > > There is a conflict between "ease of transition" and "stability". What I > wonder is: > Is it acceptable to start with: > > module org.joda.convert { > // no module yet: requires guava; > } Let me reply to myself. Mark pointed me to a feature of automodules compared with classpath jars. Classes on the classpath are not visible if you are compiling your modular project. I've done a small test to ensure I did understand it correctly. So my suggestion won't work right now, you need to specify guava, which I consider as a blocker. Developers are forced to refer to unnamed modules, even though nobody can ensure that the suggested name will become the actual name of the module. Developers must have the option to pick their own subset of requirements. And for library builders we want to enforce that they only use named modules. thanks, Robert > > This way at least all projects can start requiring org.joda.convert, and > in time the graph of requirements will automatically grow. Not being > ably to refer to unnamed modules is very well explainable. > > thanks, > Robert > >> >> Stephen >> >> [1] >> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-October/009631.html >> [2] >> http://mail.openjdk.java.net/pipermail/jpms-spec-observers/2017-January/000707.html From alan.bateman at oracle.com Mon Feb 6 16:16:38 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 06 Feb 2017 16:16:38 +0000 Subject: hg: jigsaw/jake/jdk: More startup improvements Message-ID: <201702061616.v16GGcgp029146@aojmv0008.oracle.com> Changeset: 86251453b4f4 Author: alanb Date: 2017-02-06 16:15 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/86251453b4f4 More startup improvements Contributed-by: claes.redestad at oracle.com ! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java ! src/java.base/share/classes/jdk/internal/module/SystemModuleFinder.java From david.lloyd at redhat.com Mon Feb 6 18:25:20 2017 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 6 Feb 2017 12:25:20 -0600 Subject: Automatic module names In-Reply-To: <58af7789-f927-9112-6835-e4e941a9f1e1@oracle.com> References: <55f73bef-657f-8669-4969-0830d5119b72@codefx.org> <54002ec6-be4d-ec33-6e60-8b5e1fb91a33@redhat.com> <5ba1ec95-4382-d38f-1e0f-0e5509179c39@redhat.com> <9acbac2f-21b6-c734-f14e-b42eb875e8e2@redhat.com> <58af7789-f927-9112-6835-e4e941a9f1e1@oracle.com> Message-ID: On 02/03/2017 11:42 AM, Alan Bateman wrote: > On 03/02/2017 16:42, David M. Lloyd wrote: > >> : >> >> Sure, but the set of JARs you can't rewrite is really pretty spare. > > I've no doubt that many people would be uncomfortable taking > responsibility to modularize a component that they don't maintain or > have full knowledge of. I don't think there is really a substantial increase in risk between manually modularizing a library and relying on automatic modules. Any discomfort is purely illusory, as the present automatic module process is a pretty well-defined sequence of steps, and a manual or tool-assisted modularization process would be equally well-defined, even if not exactly equivalent. Anything beyond the facts of the processes themselves would really be wandering into psychology, but I don't see a significant disadvantage with this approach (on the contrary the added flexibility seems like an advantage to me). > In the early exploration phase of Project Jigsaw > then we have some basic tooling to help with exactly that approach but > it has long been left behind. One reason is that potential for anarchy > with several people converting the same library to a module. There's no technical solution for preventing this situation when a single module environment is being assembled by multiple parties. They simply must coordinate, or the result may be inconsistent or incorrect. I don't see how automatic modules provide any sort of general remedy for this. > You might > not like automatic modules but at least the module descriptors that are > derived are very predictable (including the name). I'm not really arguing about what I like, it's purely about comparative quality: in my experience a thing that works for some cases while causing potentially subtle or confusing problems in others should generally be considered unacceptable. In the vast majority of cases, it's better to do nothing than to do something half-baked. -- - DML From Alan.Bateman at oracle.com Mon Feb 6 18:51:52 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 6 Feb 2017 18:51:52 +0000 Subject: Automatic module names In-Reply-To: References: <55f73bef-657f-8669-4969-0830d5119b72@codefx.org> <54002ec6-be4d-ec33-6e60-8b5e1fb91a33@redhat.com> <5ba1ec95-4382-d38f-1e0f-0e5509179c39@redhat.com> <9acbac2f-21b6-c734-f14e-b42eb875e8e2@redhat.com> <58af7789-f927-9112-6835-e4e941a9f1e1@oracle.com> Message-ID: On 06/02/2017 18:25, David M. Lloyd wrote: > > I don't think there is really a substantial increase in risk between > manually modularizing a library and relying on automatic modules. If several projects take on the responsibility to modularize a library that they don't maintain then there is no guarantee that they will end up with equivalent modules. Static analysis (`jdeps --generate-module-info ...`) gets you so far but it often needs a deeper understanding of the library to be confident that the module declaration that they write for the library is complete. Automatic modules take on much of the behavior of a library on the class path so that it's not necessary to synthesize everything that an explicit module would declare. -Alan From alan.bateman at oracle.com Mon Feb 6 18:52:20 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 06 Feb 2017 18:52:20 +0000 Subject: hg: jigsaw/jake/jdk: sun/net/www/protocol/jrt/WithSecurityManager.java failing Message-ID: <201702061852.v16IqK8b003933@aojmv0008.oracle.com> Changeset: d21f2b0f6713 Author: alanb Date: 2017-02-06 18:26 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d21f2b0f6713 sun/net/www/protocol/jrt/WithSecurityManager.java failing ! src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java From gunnar at hibernate.org Mon Feb 6 21:33:36 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Mon, 6 Feb 2017 22:33:36 +0100 Subject: Confusing error message for inner non-public service provider Message-ID: Hi, I have a service provider which is a public static inner class of an outer class with default visibility. As per the ServiceLoader docs, service providers must be public classes, so this provider is rightfully rejected by javac when referenced in module-info.java. But the error message is rather confusing: error: package com.example.internal is not visible provides com.example.SomeService with com.example.internal.Outer.ServiceImpl; ^ (package com.example.internal is declared in module com.example, but module com.example does not read it) error: the service implementation does not have a default constructor: ServiceImpl provides com.example.SomeService with com.example.internal. Outer.ServiceImpl ServiceImpl declares no explicit constructor, so there should be a default constructor. But also the referral to package visibility seems odd. In contrast, if defining the provider in a non-inner class with default visibility, the error message is more what I'd have expected: error: ServiceImpl is not public in com.example.internal; cannot be accessed from outside package provides com.example.SomeService with com.example.internal.ServiceImpl; Surely it's an edge case, but could the error message for the former case be adjusted to look more like in the latter? Thanks, --Gunnar From alex.buckley at oracle.com Mon Feb 6 22:05:14 2017 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 06 Feb 2017 14:05:14 -0800 Subject: Confusing error message for inner non-public service provider In-Reply-To: References: Message-ID: <5898F31A.1010101@oracle.com> On 2/6/2017 1:33 PM, Gunnar Morling wrote: > I have a service provider which is a public static inner class of an > outer class with default visibility. I think you mean public static _nested_ class, since an inner class isn't static by definition. Also I think you mean default (package) access. Visibility is something else -- see the draft JLS changes in the JSR 376 EDR. > As per the ServiceLoader docs, service providers must be public > classes, so this provider is rightfully rejected by javac when > referenced in module-info.java. But the error message is rather > confusing: > > error: package com.example.internal is not visible > provides com.example.SomeService with > com.example.internal.Outer.ServiceImpl; > ^ > (package com.example.internal is declared in module com.example, > but module com.example does not read it) > error: the service implementation does not have a default > constructor: ServiceImpl > provides com.example.SomeService with com.example.internal. > Outer.ServiceImpl > > ServiceImpl declares no explicit constructor, so there should be a > default constructor. Please see http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html#jigsaw-1.1.4 to understand the rules for provider constructors. > But also the referral to package visibility seems odd. It really means visibility, not accessibility. A Java compiler must now effect visibility in a similar way to class loaders. javac is telling you that no compilation units of the package com.example.internal are visible to your module. That is nothing to do with 'public', package access, 'protected', or 'private'. > In contrast, if defining the provider in a non-inner class with > default visibility, the error message is more what I'd have expected: > > error: ServiceImpl is not public in com.example.internal; cannot > be accessed from outside package > provides com.example.SomeService with com.example.internal.ServiceImpl; Again, you mean default (package) access. The error is correct of course. > Surely it's an edge case, but could the error message for the former > case be adjusted to look more like in the latter? The two error messages for the former are "right". The second message could be clarified to set out the requirement for an explicit constructor in lieu of an explicit provider() method. Alex From gunnar at hibernate.org Tue Feb 7 09:11:45 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Tue, 7 Feb 2017 10:11:45 +0100 Subject: Confusing error message for inner non-public service provider In-Reply-To: <5898F31A.1010101@oracle.com> References: <5898F31A.1010101@oracle.com> Message-ID: Hi Alex, Yes, I meant a nested class and default access, sorry for not being precise with the terms. These are the concerned types: --- package com.example; public interface SomeService { public void foo(); } --- package com.example.internal; class Outer { public static class ServiceImpl implements com.example.SomeService { public ServiceImpl() {} public void foo() {} } } --- package com.example.internal; class ServiceImpl implements com.example.SomeService { public ServiceImpl() {} public void foo() {} } --- module com.example { exports com.example; provides com.example.SomeService with com.example.internal.ServiceImpl; provides com.example.SomeService with com.example.internal.Outer.ServiceImpl; } --- Essentially, I'm wondering: * Why Outer.ServiceImpl triggers the error about package visibility while ServiceImpl doesn't (I had a look at the EDR JLS, but I couldn't find an explanation for that, happy about any specific pointers). * Why Outer.ServiceImpl triggers "does not have a default constructor" (ServiceImpl does not). Maybe a hint would be nice that is caused by Outer not having public access. --Gunnar 2017-02-06 23:05 GMT+01:00 Alex Buckley : > On 2/6/2017 1:33 PM, Gunnar Morling wrote: >> >> I have a service provider which is a public static inner class of an >> outer class with default visibility. > > > I think you mean public static _nested_ class, since an inner class isn't > static by definition. > > Also I think you mean default (package) access. Visibility is something else > -- see the draft JLS changes in the JSR 376 EDR. > >> As per the ServiceLoader docs, service providers must be public >> classes, so this provider is rightfully rejected by javac when >> referenced in module-info.java. But the error message is rather >> confusing: >> >> error: package com.example.internal is not visible >> provides com.example.SomeService with >> com.example.internal.Outer.ServiceImpl; >> ^ >> (package com.example.internal is declared in module com.example, >> but module com.example does not read it) >> error: the service implementation does not have a default >> constructor: ServiceImpl >> provides com.example.SomeService with com.example.internal. >> Outer.ServiceImpl >> >> ServiceImpl declares no explicit constructor, so there should be a >> default constructor. > > > Please see > http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html#jigsaw-1.1.4 to > understand the rules for provider constructors. > >> But also the referral to package visibility seems odd. > > > It really means visibility, not accessibility. A Java compiler must now > effect visibility in a similar way to class loaders. javac is telling you > that no compilation units of the package com.example.internal are visible to > your module. That is nothing to do with 'public', package access, > 'protected', or 'private'. > >> In contrast, if defining the provider in a non-inner class with >> default visibility, the error message is more what I'd have expected: >> >> error: ServiceImpl is not public in com.example.internal; cannot >> be accessed from outside package >> provides com.example.SomeService with >> com.example.internal.ServiceImpl; > > > Again, you mean default (package) access. The error is correct of course. > >> Surely it's an edge case, but could the error message for the former >> case be adjusted to look more like in the latter? > > > The two error messages for the former are "right". The second message could > be clarified to set out the requirement for an explicit constructor in lieu > of an explicit provider() method. > > Alex From alan.bateman at oracle.com Tue Feb 7 13:11:25 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 07 Feb 2017 13:11:25 +0000 Subject: hg: jigsaw/jake/jdk: More javadoc cleanup Message-ID: <201702071311.v17DBQZE013422@aojmv0008.oracle.com> Changeset: c76282450dce Author: alanb Date: 2017-02-07 13:11 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c76282450dce More javadoc cleanup ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java ! src/java.base/share/classes/java/lang/module/ModuleReader.java ! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java ! test/java/lang/module/ModuleDescriptorTest.java From brianf at infinity.nu Tue Feb 7 13:20:07 2017 From: brianf at infinity.nu (Brian Fox) Date: Tue, 7 Feb 2017 08:20:07 -0500 Subject: Automatic module names In-Reply-To: <617664d5-8ea6-1be8-7790-8d7ecd669e96@oracle.com> References: <55f73bef-657f-8669-4969-0830d5119b72@codefx.org> <617664d5-8ea6-1be8-7790-8d7ecd669e96@oracle.com> Message-ID: On Fri, Feb 3, 2017 at 10:40 AM, Alan Bateman wrote: > As regards the example naming clash then these two projects might already > get complaints over their poor choice of artifacts, esp. when artifacts for > both projects are in same directory (say where someone distributes with all > JAR files in a `lib` directory). This is an incorrect assumption. At present these artifact names do not conflict, neither in the repository coordinates, nor in the the class package. It's in fact the auto module algorithm which ignores both the project's self chosen full coordinate, as well as any version numbers present in the filename which is solely responsible for introducing the conflict. From Alan.Bateman at oracle.com Tue Feb 7 13:23:49 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 7 Feb 2017 13:23:49 +0000 Subject: 8173393: Module system implementation refresh (2/2017) Message-ID: We've been accumulating changes in the jake forest for the last few weeks and it's time to bring the changes to jdk9/dev, to make jdk-9+157 if possible. JDK 9 is the first phase of rampdown and so this update will need to get approval via the FC-extension process. The changes this time are significantly smaller than previous updates. Much of this update is API and javadoc cleanup. There are a few new methods, and a few methods have been renamed/changed, but it's otherwise small potatoes. The webrevs with the changes are here: http://cr.openjdk.java.net/~alanb/8173393/1/ Note that the webrevs are against jdk-9+155 because that is what jake is currently at. I will re-generate the webrevs later in the week once jdk-9+156 is promoted before eventually merging with jdk9/dev in advance of the eventual push. One other thing to note is that the hotspot+jdk repos have the changes for JDK-8171855, this is only because that change was backed up in jdk9/hs for several weeks and only got to jdk9/dev for jdk-9+156. This means that the only non-test change in the hotspot repo is to methodHandles.cpp. In the langtools repo then most of the changes are mechanical, with the only real update being cleanup to jdeps and the change to javac + javap to use the right values for the requires flags (the issue that R?mi brought up on jigsaw-dev last week when sync'ing up ASM). In the jdk repo then ignore the DEBUG_ADD_OPENS changes in ModuleBootstrap, that is not intended for JDK 9. There are a few small bug fixes, and a few more startup improvements from Claes. There are a small number of tests that aren't in jake yet for this update but they should be before I refresh the webrev later in the week. -Alan From Alan.Bateman at oracle.com Tue Feb 7 13:32:09 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 7 Feb 2017 13:32:09 +0000 Subject: Automatic module names In-Reply-To: References: <55f73bef-657f-8669-4969-0830d5119b72@codefx.org> <617664d5-8ea6-1be8-7790-8d7ecd669e96@oracle.com> Message-ID: On 07/02/2017 13:20, Brian Fox wrote: > : > This is an incorrect assumption. > > At present these artifact names do not conflict, neither in the repository > coordinates, nor in the the class package. It's in fact the auto module > algorithm which ignores both the project's self chosen full coordinate, as > well as any version numbers present in the filename which is solely > responsible for introducing the conflict. Sure, this is because the derivation of the modules names from existing JARs doesn't know anything about these coordinates. In any case, I was pointing out that you can't have two copies of say lib-1.0.jar in the same directory and so anyone unlucky to depend on two projects that use the same artifact name might have issues already. -Alan. From rfscholte at apache.org Tue Feb 7 13:32:50 2017 From: rfscholte at apache.org (Robert Scholte) Date: Tue, 07 Feb 2017 14:32:50 +0100 Subject: Automatic module names In-Reply-To: References: <55f73bef-657f-8669-4969-0830d5119b72@codefx.org> <617664d5-8ea6-1be8-7790-8d7ecd669e96@oracle.com> Message-ID: On Tue, 07 Feb 2017 14:20:07 +0100, Brian Fox wrote: > On Fri, Feb 3, 2017 at 10:40 AM, Alan Bateman > wrote: > >> As regards the example naming clash then these two projects might >> already >> get complaints over their poor choice of artifacts, esp. when artifacts >> for >> both projects are in same directory (say where someone distributes with >> all >> JAR files in a `lib` directory). > > > This is an incorrect assumption. > > At present these artifact names do not conflict, neither in the > repository > coordinates, nor in the the class package. It's in fact the auto module > algorithm which ignores both the project's self chosen full coordinate, > as > well as any version numbers present in the filename which is solely > responsible for introducing the conflict. For Maven, at compile time the absolute paths of the jars in the local repository are used. In case of creating a distribution Maven is capable of detecting filename collisions, in which case the files will be renamed according to a strategy. Most common way is to prefix the name with the groupId, but the renaming strategy is up to the end-user. This also made me aware that this would suddenly change the name of the automodule, unless the module-info is rewritten. Robert From david.lloyd at redhat.com Tue Feb 7 14:03:38 2017 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 7 Feb 2017 08:03:38 -0600 Subject: Automatic module names In-Reply-To: References: <55f73bef-657f-8669-4969-0830d5119b72@codefx.org> <54002ec6-be4d-ec33-6e60-8b5e1fb91a33@redhat.com> <5ba1ec95-4382-d38f-1e0f-0e5509179c39@redhat.com> <9acbac2f-21b6-c734-f14e-b42eb875e8e2@redhat.com> <58af7789-f927-9112-6835-e4e941a9f1e1@oracle.com> Message-ID: <9f965ceb-1b15-4b6f-b6ce-83b9ae0fe4dc@redhat.com> On 02/06/2017 12:51 PM, Alan Bateman wrote: > On 06/02/2017 18:25, David M. Lloyd wrote: > >> >> I don't think there is really a substantial increase in risk between >> manually modularizing a library and relying on automatic modules. > If several projects take on the responsibility to modularize a library > that they don't maintain then there is no guarantee that they will end > up with equivalent modules. Static analysis (`jdeps > --generate-module-info ...`) gets you so far but it often needs a deeper > understanding of the library to be confident that the module declaration > that they write for the library is complete. Automatic modules take on > much of the behavior of a library on the class path so that it's not > necessary to synthesize everything that an explicit module would declare. As could a tool, which has the added advantage that the module information could easily be incrementally narrowed instead of going fully from automatic to fully specified. To do incremental change from automatic to fully specified, you'd need a tool to generate an automatic-equivalent descriptor anyway. -- - DML From david.lloyd at redhat.com Tue Feb 7 14:05:27 2017 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 7 Feb 2017 08:05:27 -0600 Subject: hg: jigsaw/jake/jdk: Add AccessibleObject::canAccess and trySetAccessible In-Reply-To: <201702042341.v14NfZ4S029057@aojmv0008.oracle.com> References: <201702042341.v14NfZ4S029057@aojmv0008.oracle.com> Message-ID: <98f7fceb-591d-e97f-71a5-b9286e513604@redhat.com> I don't recall any corresponding discussion of this, but the change looks like a good idea to me. On 02/04/2017 05:41 PM, mandy.chung at oracle.com wrote: > Changeset: 335657c73d0b > Author: mchung > Date: 2017-02-04 15:41 -0800 > URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/335657c73d0b > > Add AccessibleObject::canAccess and trySetAccessible > > ! src/java.base/share/classes/java/lang/SecurityManager.java > ! src/java.base/share/classes/java/lang/System.java > ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java > ! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java > ! src/java.base/share/classes/java/security/Security.java > ! src/java.base/share/classes/jdk/internal/misc/JavaLangAccess.java > + test/java/lang/reflect/AccessibleObject/CanAccessTest.java > + test/java/lang/reflect/AccessibleObject/TrySetAccessibleTest.java > -- - DML From maurizio.cimadamore at oracle.com Tue Feb 7 14:39:30 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 7 Feb 2017 14:39:30 +0000 Subject: 8173393: Module system implementation refresh (2/2017) In-Reply-To: References: Message-ID: Langtools changes look good to me. Maurizio On 07/02/17 13:23, Alan Bateman wrote: > We've been accumulating changes in the jake forest for the last few > weeks and it's time to bring the changes to jdk9/dev, to make > jdk-9+157 if possible. JDK 9 is the first phase of rampdown and so > this update will need to get approval via the FC-extension process. > > The changes this time are significantly smaller than previous updates. > Much of this update is API and javadoc cleanup. There are a few new > methods, and a few methods have been renamed/changed, but it's > otherwise small potatoes. > > The webrevs with the changes are here: > http://cr.openjdk.java.net/~alanb/8173393/1/ > > Note that the webrevs are against jdk-9+155 because that is what jake > is currently at. I will re-generate the webrevs later in the week once > jdk-9+156 is promoted before eventually merging with jdk9/dev in > advance of the eventual push. > > One other thing to note is that the hotspot+jdk repos have the changes > for JDK-8171855, this is only because that change was backed up in > jdk9/hs for several weeks and only got to jdk9/dev for jdk-9+156. This > means that the only non-test change in the hotspot repo is to > methodHandles.cpp. > > In the langtools repo then most of the changes are mechanical, with > the only real update being cleanup to jdeps and the change to javac + > javap to use the right values for the requires flags (the issue that > R?mi brought up on jigsaw-dev last week when sync'ing up ASM). > > In the jdk repo then ignore the DEBUG_ADD_OPENS changes in > ModuleBootstrap, that is not intended for JDK 9. > > There are a few small bug fixes, and a few more startup improvements > from Claes. There are a small number of tests that aren't in jake yet > for this update but they should be before I refresh the webrev later > in the week. > > -Alan > From daniel.fuchs at oracle.com Tue Feb 7 15:24:38 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 7 Feb 2017 15:24:38 +0000 Subject: 8173393: Module system implementation refresh (2/2017) In-Reply-To: References: Message-ID: <6eb4c3be-7ffb-ac1c-d5db-41878da0b2b4@oracle.com> Hi Alan, jaxp and stack walking class (and test) changes look OK to me. best regards, -- daniel On 07/02/17 13:23, Alan Bateman wrote: > We've been accumulating changes in the jake forest for the last few > weeks and it's time to bring the changes to jdk9/dev, to make jdk-9+157 > if possible. JDK 9 is the first phase of rampdown and so this update > will need to get approval via the FC-extension process. > > The changes this time are significantly smaller than previous updates. > Much of this update is API and javadoc cleanup. There are a few new > methods, and a few methods have been renamed/changed, but it's otherwise > small potatoes. > > The webrevs with the changes are here: > http://cr.openjdk.java.net/~alanb/8173393/1/ > > Note that the webrevs are against jdk-9+155 because that is what jake is > currently at. I will re-generate the webrevs later in the week once > jdk-9+156 is promoted before eventually merging with jdk9/dev in advance > of the eventual push. > > One other thing to note is that the hotspot+jdk repos have the changes > for JDK-8171855, this is only because that change was backed up in > jdk9/hs for several weeks and only got to jdk9/dev for jdk-9+156. This > means that the only non-test change in the hotspot repo is to > methodHandles.cpp. > > In the langtools repo then most of the changes are mechanical, with the > only real update being cleanup to jdeps and the change to javac + javap > to use the right values for the requires flags (the issue that R?mi > brought up on jigsaw-dev last week when sync'ing up ASM). > > In the jdk repo then ignore the DEBUG_ADD_OPENS changes in > ModuleBootstrap, that is not intended for JDK 9. > > There are a few small bug fixes, and a few more startup improvements > from Claes. There are a small number of tests that aren't in jake yet > for this update but they should be before I refresh the webrev later in > the week. > > -Alan > From forax at univ-mlv.fr Tue Feb 7 16:42:06 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 07 Feb 2017 16:42:06 +0000 Subject: Automatic module names In-Reply-To: <9f965ceb-1b15-4b6f-b6ce-83b9ae0fe4dc@redhat.com> References: <55f73bef-657f-8669-4969-0830d5119b72@codefx.org> <54002ec6-be4d-ec33-6e60-8b5e1fb91a33@redhat.com> <5ba1ec95-4382-d38f-1e0f-0e5509179c39@redhat.com> <9acbac2f-21b6-c734-f14e-b42eb875e8e2@redhat.com> <58af7789-f927-9112-6835-e4e941a9f1e1@oracle.com> <9f965ceb-1b15-4b6f-b6ce-83b9ae0fe4dc@redhat.com> Message-ID: I've coded such kind of tool [1] :) It uses Maven (Aether) to download the dependencies then do a simple static analysis on the downloaded jars to calculate the dependencies and inject the module-info.class. Because of the runtime dependencies, annotations, Class.forName etc, you also have to provide additional dependencies by hand so it's not the silver bullet. And you still have the naming problem, which I've solved by asking the user to provide a name for each non modular jars. So in order to automatically generate the module-info.class, you end up writing an additional configuration file which is not very different of a module-info.java :( R?mi [1] https://github.com/forax/pro/blob/master/src/main/java/com.github.forax.pro.plugin.modulefixer/com/github/forax/pro/plugin/modulefixer/ModuleFixerPlugin.java On February 7, 2017 3:03:38 PM GMT+01:00, "David M. Lloyd" wrote: >On 02/06/2017 12:51 PM, Alan Bateman wrote: >> On 06/02/2017 18:25, David M. Lloyd wrote: >> >>> >>> I don't think there is really a substantial increase in risk between >>> manually modularizing a library and relying on automatic modules. >> If several projects take on the responsibility to modularize a >library >> that they don't maintain then there is no guarantee that they will >end >> up with equivalent modules. Static analysis (`jdeps >> --generate-module-info ...`) gets you so far but it often needs a >deeper >> understanding of the library to be confident that the module >declaration >> that they write for the library is complete. Automatic modules take >on >> much of the behavior of a library on the class path so that it's not >> necessary to synthesize everything that an explicit module would >declare. > >As could a tool, which has the added advantage that the module >information could easily be incrementally narrowed instead of going >fully from automatic to fully specified. To do incremental change from > >automatic to fully specified, you'd need a tool to generate an >automatic-equivalent descriptor anyway. > >-- >- DML -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From david.dehaven at oracle.com Tue Feb 7 18:38:07 2017 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 7 Feb 2017 10:38:07 -0800 Subject: [9] Review request: JDK-8170200: Packager Redistributable Module List Unit Test In-Reply-To: <4a49f880-f636-a5b8-4bea-01c11115945c@oracle.com> References: <4a49f880-f636-a5b8-4bea-01c11115945c@oracle.com> Message-ID: <17805F73-52DF-455E-92D0-52F2C80AC26C@oracle.com> > Kevin, Mandy, > > Please review my new unit test for javapackager. It reads redistributable module list from jdk.packager, if a module in the list doesn't exist, then the test fails. > > JIRA: https://bugs.openjdk.java.net/browse/JDK-8170200 > Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8170200/webrev.00/ Just thought of something, what happens if FX is not imported? -DrD- From chris.bensen at oracle.com Tue Feb 7 18:45:37 2017 From: chris.bensen at oracle.com (Chris Bensen) Date: Tue, 7 Feb 2017 10:45:37 -0800 Subject: [9] Review request: JDK-8170200: Packager Redistributable Module List Unit Test In-Reply-To: <17805F73-52DF-455E-92D0-52F2C80AC26C@oracle.com> References: <4a49f880-f636-a5b8-4bea-01c11115945c@oracle.com> <17805F73-52DF-455E-92D0-52F2C80AC26C@oracle.com> Message-ID: <1F7736DB-7BC4-46A7-9AD2-B26279D098C0@oracle.com> It will fail to compile. Is there a way to test if jdk.packager is present before compiling? Chris > On Feb 7, 2017, at 10:38 AM, David DeHaven wrote: > > >> Kevin, Mandy, >> >> Please review my new unit test for javapackager. It reads redistributable module list from jdk.packager, if a module in the list doesn't exist, then the test fails. >> >> JIRA: https://bugs.openjdk.java.net/browse/JDK-8170200 >> Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8170200/webrev.00/ > > Just thought of something, what happens if FX is not imported? > > -DrD- > From mandy.chung at oracle.com Tue Feb 7 19:19:32 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 7 Feb 2017 11:19:32 -0800 Subject: hg: jigsaw/jake/jdk: Add AccessibleObject::canAccess and trySetAccessible In-Reply-To: <98f7fceb-591d-e97f-71a5-b9286e513604@redhat.com> References: <201702042341.v14NfZ4S029057@aojmv0008.oracle.com> <98f7fceb-591d-e97f-71a5-b9286e513604@redhat.com> Message-ID: This is included in the module system refresh discussion [1] to avoid the merge conflict if it were separated from it. Your feedback is welcome and appreciated. Mandy [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-February/011231.html > On Feb 7, 2017, at 6:05 AM, David M. Lloyd wrote: > > I don't recall any corresponding discussion of this, but the change looks like a good idea to me. > > On 02/04/2017 05:41 PM, mandy.chung at oracle.com wrote: >> Changeset: 335657c73d0b >> Author: mchung >> Date: 2017-02-04 15:41 -0800 >> URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/335657c73d0b >> >> Add AccessibleObject::canAccess and trySetAccessible >> >> ! src/java.base/share/classes/java/lang/SecurityManager.java >> ! src/java.base/share/classes/java/lang/System.java >> ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java >> ! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java >> ! src/java.base/share/classes/java/security/Security.java >> ! src/java.base/share/classes/jdk/internal/misc/JavaLangAccess.java >> + test/java/lang/reflect/AccessibleObject/CanAccessTest.java >> + test/java/lang/reflect/AccessibleObject/TrySetAccessibleTest.java >> > > -- > - DML From alex.buckley at oracle.com Tue Feb 7 19:21:41 2017 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 07 Feb 2017 11:21:41 -0800 Subject: Confusing error message for inner non-public service provider In-Reply-To: References: <5898F31A.1010101@oracle.com> Message-ID: <589A1E45.3060604@oracle.com> On 2/7/2017 1:11 AM, Gunnar Morling wrote: > --- > package com.example; > public interface SomeService { > public void foo(); > } > --- > package com.example.internal; > class Outer { > > public static class ServiceImpl implements com.example.SomeService { > public ServiceImpl() {} > public void foo() {} > } > } > --- > package com.example.internal; > class ServiceImpl implements com.example.SomeService { > public ServiceImpl() {} > public void foo() {} > } > --- > module com.example { > exports com.example; > provides com.example.SomeService with com.example.internal.ServiceImpl; > provides com.example.SomeService with > com.example.internal.Outer.ServiceImpl; > } > --- > > Essentially, I'm wondering: > > * Why Outer.ServiceImpl triggers the error about package visibility > while ServiceImpl doesn't (I had a look at the EDR JLS, but I couldn't > find an explanation for that, happy about any specific pointers). > * Why Outer.ServiceImpl triggers "does not have a default constructor" > (ServiceImpl does not). Maybe a hint would be nice that is caused by > Outer not having public access. Thanks for showing the code. Since everything in the same module, package visibility is not relevant and javac shouldn't mention it. I suspect that javac is getting tripped up by the fact that Outer.ServiceImpl is declared 'public' (as the JLS and ServiceLoader both demand) but it isn't widely accessible, even within the com.example module, due to Outer's default (package) access. I believe the JLS and ServiceLoader rules are correct, so it's a javac bug. Alex From mandy.chung at oracle.com Tue Feb 7 19:37:39 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 7 Feb 2017 11:37:39 -0800 Subject: [9] Review request: JDK-8170200: Packager Redistributable Module List Unit Test In-Reply-To: <4a49f880-f636-a5b8-4bea-01c11115945c@oracle.com> References: <4a49f880-f636-a5b8-4bea-01c11115945c@oracle.com> Message-ID: <52080642-C94D-4E33-B8B2-3959CF748073@oracle.com> Should this test be in the FX repo where jdk.packager resides? I would think so. This test should only run with the build with FX modules. Mandy > On Feb 7, 2017, at 10:32 AM, Victor Drozdov wrote: > > Kevin, Mandy, > > Please review my new unit test for javapackager. It reads redistributable module list from jdk.packager, if a module in the list doesn't exist, then the test fails. > > JIRA: https://bugs.openjdk.java.net/browse/JDK-8170200 > Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8170200/webrev.00/ > > --Victor > From chris.bensen at oracle.com Tue Feb 7 19:41:39 2017 From: chris.bensen at oracle.com (Chris Bensen) Date: Tue, 7 Feb 2017 11:41:39 -0800 Subject: [9] Review request: JDK-8170200: Packager Redistributable Module List Unit Test In-Reply-To: <52080642-C94D-4E33-B8B2-3959CF748073@oracle.com> References: <4a49f880-f636-a5b8-4bea-01c11115945c@oracle.com> <52080642-C94D-4E33-B8B2-3959CF748073@oracle.com> Message-ID: It can?t live in FX. FX can be built with an open, closed or custom JDK without FX so this test needs to be in the JDK but it would be best if we can only attempt to run it if FX is imported. Chris > On Feb 7, 2017, at 11:37 AM, Mandy Chung wrote: > > Should this test be in the FX repo where jdk.packager resides? I would think so. This test should only run with the build with FX modules. > > Mandy > >> On Feb 7, 2017, at 10:32 AM, Victor Drozdov wrote: >> >> Kevin, Mandy, >> >> Please review my new unit test for javapackager. It reads redistributable module list from jdk.packager, if a module in the list doesn't exist, then the test fails. >> >> JIRA: https://bugs.openjdk.java.net/browse/JDK-8170200 >> Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8170200/webrev.00/ >> >> --Victor >> > From kevin.rushforth at oracle.com Tue Feb 7 19:51:10 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 07 Feb 2017 11:51:10 -0800 Subject: [9] Review request: JDK-8170200: Packager Redistributable Module List Unit Test In-Reply-To: <52080642-C94D-4E33-B8B2-3959CF748073@oracle.com> References: <4a49f880-f636-a5b8-4bea-01c11115945c@oracle.com> <52080642-C94D-4E33-B8B2-3959CF748073@oracle.com> Message-ID: <589A252E.1010005@oracle.com> If the test is in the FX repo then it wouldn't be able to check the jmod, but would have to check some intermediate data that feeds into the jmod. That might be OK, but is seems easy enough to check for the existence of the jdk.packager module and skip the test if not present. -- Kevin Mandy Chung wrote: > Should this test be in the FX repo where jdk.packager resides? I would think so. This test should only run with the build with FX modules. > > Mandy > > >> On Feb 7, 2017, at 10:32 AM, Victor Drozdov wrote: >> >> Kevin, Mandy, >> >> Please review my new unit test for javapackager. It reads redistributable module list from jdk.packager, if a module in the list doesn't exist, then the test fails. >> >> JIRA: https://bugs.openjdk.java.net/browse/JDK-8170200 >> Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8170200/webrev.00/ >> >> --Victor >> >> > > From mandy.chung at oracle.com Tue Feb 7 20:51:18 2017 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 07 Feb 2017 20:51:18 +0000 Subject: hg: jigsaw/jake/jaxp: Module created dynamically should have synthetic modifier Message-ID: <201702072051.v17KpII8020771@aojmv0008.oracle.com> Changeset: ecce006f9a20 Author: mchung Date: 2017-02-07 12:50 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/ecce006f9a20 Module created dynamically should have synthetic modifier ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java From mandy.chung at oracle.com Tue Feb 7 20:51:24 2017 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 07 Feb 2017 20:51:24 +0000 Subject: hg: jigsaw/jake/jdk: Module created dynamically should have synthetic modifier Message-ID: <201702072051.v17KpPKM020876@aojmv0008.oracle.com> Changeset: 5c4843cc0b4b Author: mchung Date: 2017-02-07 12:50 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5c4843cc0b4b Module created dynamically should have synthetic modifier ! src/java.base/share/classes/java/lang/reflect/Proxy.java ! src/java.management/share/classes/javax/management/remote/rmi/RMIConnector.java From mandy.chung at oracle.com Tue Feb 7 20:51:30 2017 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 07 Feb 2017 20:51:30 +0000 Subject: hg: jigsaw/jake/nashorn: Module created dynamically should have synthetic modifier Message-ID: <201702072051.v17KpUW7020985@aojmv0008.oracle.com> Changeset: 22eecb4b45d7 Author: mchung Date: 2017-02-07 12:51 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/22eecb4b45d7 Module created dynamically should have synthetic modifier ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptLoader.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/StructureLoader.java From lois.foltan at oracle.com Tue Feb 7 22:48:46 2017 From: lois.foltan at oracle.com (Lois Foltan) Date: Tue, 07 Feb 2017 17:48:46 -0500 Subject: 8173393: Module system implementation refresh (2/2017) In-Reply-To: References: Message-ID: <589A4ECE.80308@oracle.com> Hotspot changes look good to me. Lois On 2/7/2017 8:23 AM, Alan Bateman wrote: > We've been accumulating changes in the jake forest for the last few > weeks and it's time to bring the changes to jdk9/dev, to make > jdk-9+157 if possible. JDK 9 is the first phase of rampdown and so > this update will need to get approval via the FC-extension process. > > The changes this time are significantly smaller than previous updates. > Much of this update is API and javadoc cleanup. There are a few new > methods, and a few methods have been renamed/changed, but it's > otherwise small potatoes. > > The webrevs with the changes are here: > http://cr.openjdk.java.net/~alanb/8173393/1/ > > Note that the webrevs are against jdk-9+155 because that is what jake > is currently at. I will re-generate the webrevs later in the week once > jdk-9+156 is promoted before eventually merging with jdk9/dev in > advance of the eventual push. > > One other thing to note is that the hotspot+jdk repos have the changes > for JDK-8171855, this is only because that change was backed up in > jdk9/hs for several weeks and only got to jdk9/dev for jdk-9+156. This > means that the only non-test change in the hotspot repo is to > methodHandles.cpp. > > In the langtools repo then most of the changes are mechanical, with > the only real update being cleanup to jdeps and the change to javac + > javap to use the right values for the requires flags (the issue that > R?mi brought up on jigsaw-dev last week when sync'ing up ASM). > > In the jdk repo then ignore the DEBUG_ADD_OPENS changes in > ModuleBootstrap, that is not intended for JDK 9. > > There are a few small bug fixes, and a few more startup improvements > from Claes. There are a small number of tests that aren't in jake yet > for this update but they should be before I refresh the webrev later > in the week. > > -Alan > From paul.sandoz at oracle.com Wed Feb 8 03:10:53 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 7 Feb 2017 19:10:53 -0800 Subject: 8173393: Module system implementation refresh (2/2017) In-Reply-To: <589A4ECE.80308@oracle.com> References: <589A4ECE.80308@oracle.com> Message-ID: <4389C801-3848-433C-8302-2BBF82546304@oracle.com> Hi, Just minor stuff in the JDK area (i browsed quickly through the tests). Paul. java.lang.module.Configuration ? 321 * @implNote In the implementation then observability of modules may depend s/then/the ModuleDescriptor ? 2662 private static > 2663 int compare(Set s1, Set s2) { 2664 Iterator iterator1 = new TreeSet<>(s1).iterator(); 2665 Iterator iterator2 = new TreeSet<>(s2).iterator(); 2666 while (iterator1.hasNext()) { 2667 if (!iterator2.hasNext()) 2668 return 1; // s1 has more elements 2669 T e1 = iterator1.next(); 2670 T e2 = iterator2.next(); 2671 int c = e1.compareTo(e2); 2672 if (c != 0) 2673 return c; 2674 } 2675 if (iterator2.hasNext()) { 2676 return -1; // s2 has more elements 2677 } else { 2678 return 0; 2679 } 2680 } Potential optimisation. Convert the sets to arrays, sort ?em, then use Arrays.compare. BuiltinClassLoader ? 925 private ModuleReader moduleReaderFor(ModuleReference mref) { 926 return moduleToReader.computeIfAbsent(mref, m -> createModuleReader(m)); 927 } Use this:: createModuleReader jdk.internal.module.Builder ? 279 Set modifiers; 280 if (open || synthetic) { 281 modifiers = new HashSet<>(); 282 if (open) modifiers.add(ModuleDescriptor.Modifier.OPEN); 283 if (synthetic) modifiers.add(ModuleDescriptor.Modifier.SYNTHETIC); 284 modifiers = Collections.unmodifiableSet(modifiers); 285 } else { 286 modifiers = Collections.emptySet(); 287 } It would be nice to use the small collection methods given the sizes. The following might work: Set modifiers; int n = (open ? 1 : 0) + (synthetic ? 1 : 0); if (n > 0) { ModuleDescriptor.Modifier[] ms = new ModuleDescriptor.Modifier[n]; if (open) ms[?n] = ModuleDescriptor.Modifier.OPEN; if (synthetic) ms[?n] = ModuleDescriptor.Modifier.SYNTHETIC; modifiers = Set.of(ms); } else { modifiers = Set.of(); } test/tools/jar/modularJar/Basic.java ? 331 @Test(enabled = false) 332 public void partialUpdateFooMainClass() throws IOException { Just checking if that test still needs to be disabled. ? Separately, we missed the opportunity to add lexicographical comparison and mismatch to List (we added them for arrays). Paul. > On 7 Feb 2017, at 14:48, Lois Foltan wrote: > > Hotspot changes look good to me. > Lois > > On 2/7/2017 8:23 AM, Alan Bateman wrote: >> We've been accumulating changes in the jake forest for the last few weeks and it's time to bring the changes to jdk9/dev, to make jdk-9+157 if possible. JDK 9 is the first phase of rampdown and so this update will need to get approval via the FC-extension process. >> >> The changes this time are significantly smaller than previous updates. Much of this update is API and javadoc cleanup. There are a few new methods, and a few methods have been renamed/changed, but it's otherwise small potatoes. >> >> The webrevs with the changes are here: >> http://cr.openjdk.java.net/~alanb/8173393/1/ >> >> Note that the webrevs are against jdk-9+155 because that is what jake is currently at. I will re-generate the webrevs later in the week once jdk-9+156 is promoted before eventually merging with jdk9/dev in advance of the eventual push. >> >> One other thing to note is that the hotspot+jdk repos have the changes for JDK-8171855, this is only because that change was backed up in jdk9/hs for several weeks and only got to jdk9/dev for jdk-9+156. This means that the only non-test change in the hotspot repo is to methodHandles.cpp. >> >> In the langtools repo then most of the changes are mechanical, with the only real update being cleanup to jdeps and the change to javac + javap to use the right values for the requires flags (the issue that R?mi brought up on jigsaw-dev last week when sync'ing up ASM). >> >> In the jdk repo then ignore the DEBUG_ADD_OPENS changes in ModuleBootstrap, that is not intended for JDK 9. >> >> There are a few small bug fixes, and a few more startup improvements from Claes. There are a small number of tests that aren't in jake yet for this update but they should be before I refresh the webrev later in the week. >> >> -Alan >> > From alan.bateman at oracle.com Wed Feb 8 11:27:21 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 08 Feb 2017 11:27:21 +0000 Subject: hg: jigsaw/jake/jdk: Improve patching with exploded builds Message-ID: <201702081127.v18BRMhH012070@aojmv0008.oracle.com> Changeset: ae537b2d3427 Author: alanb Date: 2017-02-08 11:27 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ae537b2d3427 Improve patching with exploded builds ! src/java.base/share/classes/java/lang/module/ModuleFinder.java ! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java ! src/java.base/share/classes/jdk/internal/module/ModulePath.java ! src/java.base/share/classes/jdk/internal/module/ModuleReferences.java ! src/jdk.jartool/share/classes/sun/tools/jar/GNUStyleOptions.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java ! src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java ! test/java/lang/module/ModuleReader/ModuleReaderTest.java ! test/tools/jmod/hashes/HashesTest.java From Alan.Bateman at oracle.com Wed Feb 8 11:37:48 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 8 Feb 2017 11:37:48 +0000 Subject: 8173393: Module system implementation refresh (2/2017) In-Reply-To: <4389C801-3848-433C-8302-2BBF82546304@oracle.com> References: <589A4ECE.80308@oracle.com> <4389C801-3848-433C-8302-2BBF82546304@oracle.com> Message-ID: <23aa9a34-3742-a720-3796-7051b3490bc3@oracle.com> On 08/02/2017 03:10, Paul Sandoz wrote: > Hi, > > Just minor stuff in the JDK area (i browsed quickly through the tests). Thanks, a few comments below. > > Paul. > > > java.lang.module.Configuration > ? > > 321 * @implNote In the implementation then observability of modules may depend > > s/then/the "then" should be okay, it could also be "then the" (that might be what you mean). > : > > Potential optimisation. Convert the sets to arrays, sort ?em, then use Arrays.compare. Yes, that could work. It's a real corner case to have to do this but we can do better for such cases. > > > BuiltinClassLoader > ? > > 925 private ModuleReader moduleReaderFor(ModuleReference mref) { > 926 return moduleToReader.computeIfAbsent(mref, m -> createModuleReader(m)); > 927 } > > Use this:: createModuleReader I'll defer to Claes on this, mostly because #classes triggered to load here is observable in startup tests. > > > jdk.internal.module.Builder > ? > > 279 Set modifiers; > 280 if (open || synthetic) { > 281 modifiers = new HashSet<>(); > 282 if (open) modifiers.add(ModuleDescriptor.Modifier.OPEN); > 283 if (synthetic) modifiers.add(ModuleDescriptor.Modifier.SYNTHETIC); > 284 modifiers = Collections.unmodifiableSet(modifiers); > 285 } else { > 286 modifiers = Collections.emptySet(); > 287 } > > It would be nice to use the small collection methods given the sizes. The following might work: This is jlink plugin and would be really odd to have modules with the synthetic modifier. There are no open modules in the JDK images but a custom image may include some so point taken, this could be more efficient. > : > > > test/tools/jar/modularJar/Basic.java > ? > > 331 @Test(enabled = false) > 332 public void partialUpdateFooMainClass() throws IOException { > > Just checking if that test still needs to be disabled. There are fixes going into jdk9/dev for the jar tool that should allow us to re-enable this, it all depends on when the changes will meet up. If we have to push with that test disabled then I'll make sure there is a bug. > : > > ? > > Separately, we missed the opportunity to add lexicographical comparison and mismatch to List (we added them for arrays). > Yes. -Alan. From alan.bateman at oracle.com Wed Feb 8 13:44:41 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 08 Feb 2017 13:44:41 +0000 Subject: hg: jigsaw/jake/jdk: More clean-up/comments Message-ID: <201702081344.v18DifkT021476@aojmv0008.oracle.com> Changeset: 0c9a906bada4 Author: alanb Date: 2017-02-08 13:44 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0c9a906bada4 More clean-up/comments ! src/java.base/share/classes/java/lang/module/Configuration.java ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java ! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java ! src/java.base/share/classes/jdk/internal/module/Builder.java ! src/java.base/share/classes/sun/launcher/LauncherHelper.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java From claes.redestad at oracle.com Wed Feb 8 14:49:31 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 8 Feb 2017 15:49:31 +0100 Subject: 8173393: Module system implementation refresh (2/2017) In-Reply-To: <23aa9a34-3742-a720-3796-7051b3490bc3@oracle.com> References: <589A4ECE.80308@oracle.com> <4389C801-3848-433C-8302-2BBF82546304@oracle.com> <23aa9a34-3742-a720-3796-7051b3490bc3@oracle.com> Message-ID: <1d866af6-939f-8767-d772-610f3d63182a@oracle.com> Hi, On 2017-02-08 12:37, Alan Bateman wrote: >> >> >> BuiltinClassLoader >> ? >> >> 925 private ModuleReader moduleReaderFor(ModuleReference mref) { >> 926 return moduleToReader.computeIfAbsent(mref, m -> >> createModuleReader(m)); >> 927 } >> >> Use this:: createModuleReader > I'll defer to Claes on this, mostly because #classes triggered to load > here is observable in startup tests. From a startup perspective all alternatives are more or less equal here, and generally speaking a lambda and a method reference are equal as long as they're both non-capturing. A detail I had missed here, though, is that the createModuleReader method could be made static to ensure the lambda is actually non-capturing (otherwise it'll unnecessarily allocate an object preserving this). So I'd make createModuleReader static and then pick and choose between m -> createModuleReader(m) and BuiltinClassLoader::createModuleReader Thanks! /Claes From Alan.Bateman at oracle.com Wed Feb 8 15:04:05 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 8 Feb 2017 15:04:05 +0000 Subject: 8173393: Module system implementation refresh (2/2017) In-Reply-To: <1d866af6-939f-8767-d772-610f3d63182a@oracle.com> References: <589A4ECE.80308@oracle.com> <4389C801-3848-433C-8302-2BBF82546304@oracle.com> <23aa9a34-3742-a720-3796-7051b3490bc3@oracle.com> <1d866af6-939f-8767-d772-610f3d63182a@oracle.com> Message-ID: <12cb8986-b9f4-55a2-afa9-0a2053328a7a@oracle.com> On 08/02/2017 14:49, Claes Redestad wrote: > > From a startup perspective all alternatives are more or less equal > here, and generally speaking a lambda and a method reference are equal > as long as they're both non-capturing. > > A detail I had missed here, though, is that the createModuleReader > method could be made static to ensure the lambda is actually > non-capturing (otherwise it'll unnecessarily allocate an object > preserving this). Yes, good point, this can of course be static. -Alan From alan.bateman at oracle.com Wed Feb 8 15:45:02 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 08 Feb 2017 15:45:02 +0000 Subject: hg: jigsaw/jake/jdk: createModuleReader can be static Message-ID: <201702081545.v18Fj2ar029148@aojmv0008.oracle.com> Changeset: 15bacfdf9078 Author: alanb Date: 2017-02-08 15:44 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/15bacfdf9078 createModuleReader can be static Contributed-by: claes.redestad at oracle.com ! src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java From paul.sandoz at oracle.com Wed Feb 8 19:39:26 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 8 Feb 2017 11:39:26 -0800 Subject: 8173393: Module system implementation refresh (2/2017) In-Reply-To: <23aa9a34-3742-a720-3796-7051b3490bc3@oracle.com> References: <589A4ECE.80308@oracle.com> <4389C801-3848-433C-8302-2BBF82546304@oracle.com> <23aa9a34-3742-a720-3796-7051b3490bc3@oracle.com> Message-ID: > On 8 Feb 2017, at 03:37, Alan Bateman wrote: > > On 08/02/2017 03:10, Paul Sandoz wrote: > >> Hi, >> >> Just minor stuff in the JDK area (i browsed quickly through the tests). > Thanks, a few comments below. > >> >> Paul. >> >> >> java.lang.module.Configuration >> ? >> >> 321 * @implNote In the implementation then observability of modules may depend >> >> s/then/the > "then" should be okay, it could also be "then the" (that might be what you mean). > Given the way i recall JavaDoc renders impl notes they tend to stand on their own rather as sections than be dependent on the flow of paragraphs previous to them. Paul. From mandy.chung at oracle.com Wed Feb 8 20:46:17 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 8 Feb 2017 12:46:17 -0800 Subject: 8173393: Module system implementation refresh (2/2017) In-Reply-To: References: Message-ID: <6C61972D-F35A-4223-B1C1-2F16A1F7BEE0@oracle.com> I reviewed your updated webrev: http://cr.openjdk.java.net/~alanb/8173393/2 src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Module.java 285 m.descriptor.packages().forEach(builder::opens); This is not needed. I took it out. We probably will do another pass on the APIs to tag with @spec JPMS. IllegalCallerException and the following in MethodHandles don?t have the tag. 667 public static final int UNCONDITIONAL = PACKAGE << 2; 841 public Lookup dropLookupMode(int modeToDrop) { IIRC no specific spec change to ResourceBundle.Control.toBundleName. So @revised and @spec can be dropped. Otherwise looks fine to me. I reviewed changes in jdk.jdeps in langtools and all other repos. Mandy From karen.kinnear at oracle.com Wed Feb 8 20:58:01 2017 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 8 Feb 2017 15:58:01 -0500 Subject: 8173393: Module system implementation refresh (2/2017) In-Reply-To: References: Message-ID: Hotspot changes look good. thanks, Karen > On Feb 7, 2017, at 8:23 AM, Alan Bateman wrote: > > We've been accumulating changes in the jake forest for the last few weeks and it's time to bring the changes to jdk9/dev, to make jdk-9+157 if possible. JDK 9 is the first phase of rampdown and so this update will need to get approval via the FC-extension process. > > The changes this time are significantly smaller than previous updates. Much of this update is API and javadoc cleanup. There are a few new methods, and a few methods have been renamed/changed, but it's otherwise small potatoes. > > The webrevs with the changes are here: > http://cr.openjdk.java.net/~alanb/8173393/1/ > > Note that the webrevs are against jdk-9+155 because that is what jake is currently at. I will re-generate the webrevs later in the week once jdk-9+156 is promoted before eventually merging with jdk9/dev in advance of the eventual push. > > One other thing to note is that the hotspot+jdk repos have the changes for JDK-8171855, this is only because that change was backed up in jdk9/hs for several weeks and only got to jdk9/dev for jdk-9+156. This means that the only non-test change in the hotspot repo is to methodHandles.cpp. > > In the langtools repo then most of the changes are mechanical, with the only real update being cleanup to jdeps and the change to javac + javap to use the right values for the requires flags (the issue that R?mi brought up on jigsaw-dev last week when sync'ing up ASM). > > In the jdk repo then ignore the DEBUG_ADD_OPENS changes in ModuleBootstrap, that is not intended for JDK 9. > > There are a few small bug fixes, and a few more startup improvements from Claes. There are a small number of tests that aren't in jake yet for this update but they should be before I refresh the webrev later in the week. > > -Alan > From mandy.chung at oracle.com Wed Feb 8 22:58:14 2017 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 08 Feb 2017 22:58:14 +0000 Subject: hg: jigsaw/jake/langtools: Minor fix to jdeps per review comment Message-ID: <201702082258.v18MwE5h018452@aojmv0008.oracle.com> Changeset: ada521a422b6 Author: mchung Date: 2017-02-08 14:58 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/ada521a422b6 Minor fix to jdeps per review comment ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Module.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleInfoBuilder.java From s.2016.kay at gmail.com Thu Feb 9 08:18:04 2017 From: s.2016.kay at gmail.com (Ess Kay) Date: Thu, 9 Feb 2017 19:18:04 +1100 Subject: "OpenJDK specific" attribute specifications Message-ID: Remi Forax has explained that the ModuleHashes attribute is "OpenJDK specific" and so is not part of the JMP spec. Is there an up to date specification of OpenJDK specific Java 9 class file changes anywhere? From Alan.Bateman at oracle.com Thu Feb 9 09:12:17 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 9 Feb 2017 09:12:17 +0000 Subject: "OpenJDK specific" attribute specifications In-Reply-To: References: Message-ID: On 09/02/2017 08:18, Ess Kay wrote: > Remi Forax has explained that the ModuleHashes attribute is "OpenJDK > specific" and so is not part of the JMP spec. Is there an up to date > specification of OpenJDK specific Java 9 class file changes anywhere? ModuleHashes and ModuleResolution are JDK-specific. I'm not aware of a document where such class file attributes are specified. For now, ModuleHashes is: * ModuleHashes_attribute { * // index to CONSTANT_utf8_info structure in constant pool representing * // the string "ModuleHashes" * u2 attribute_name_index; * u4 attribute_length; * * // index to CONSTANT_utf8_info structure with algorithm name * u2 algorithm_index; * * // the number of entries in the hashes table * u2 hashes_count; * { u2 module_name_index (index to CONSTANT_Module_info structure) * u2 hash_length; * u1 hash[hash_length]; * } hashes[hashes_count]; * * } -Alan From denis.kononenko at oracle.com Thu Feb 9 10:03:53 2017 From: denis.kononenko at oracle.com (Denis Kononenko) Date: Thu, 9 Feb 2017 02:03:53 -0800 (PST) Subject: [9] RFR 8170113: jimage extract to readonly directory causes MissingResourceException Message-ID: Hi, > > On 06/02/2017 10:27, Denis Kononenko wrote: > > Hi, > > > > Could someone please review this very small fix. > > > > The class JImageTask > (src/jdk.jlink/share/classes/jdk/tools/jimage/JImageTask.java) has > references to an info message by 'err.cannot.create.dir' key. > Unfortunately the corresponding resource file > (src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage.properties) > doesn't contain this key. This results in long not user friendly > stacktraces in output when jimage cannot create a directory. The fix > is very small, I added the missing definition into the resource file. > > > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8170113 > > WEBREV: http://cr.openjdk.java.net/~dkononenko/8170113/webrev.00 > > > This looks okay as a short term fix but I think that extract need to > be-implemented to use the new file system API so that the reasons why > > the directory can be printed too. Also there is an anomaly in errors > related to the directory result in an error message whereas any errors > > extracting to the directory lead to an exception. > > -Alan I think we might have to defer such big change to the next release. If there's no objections I'd propose to deliver this fix AS IS and open a new enhancement request to re-implement 'extract' method. Thank you, Denis. From andrey.x.nazarov at oracle.com Thu Feb 9 15:30:55 2017 From: andrey.x.nazarov at oracle.com (Andrey Nazarov) Date: Thu, 9 Feb 2017 18:30:55 +0300 Subject: [9] RFR 8170113: jimage extract to readonly directory causes MissingResourceException In-Reply-To: References: Message-ID: <46CAA49D-859F-481F-9C33-72968F8E7697@oracle.com> Hi, looks ok for me. Simple and safe fix. ?Andrey > On 9 Feb 2017, at 13:03, Denis Kononenko wrote: > > > Hi, > >> >> On 06/02/2017 10:27, Denis Kononenko wrote: >>> Hi, >>> >>> Could someone please review this very small fix. >>> >>> The class JImageTask >> (src/jdk.jlink/share/classes/jdk/tools/jimage/JImageTask.java) has >> references to an info message by 'err.cannot.create.dir' key. >> Unfortunately the corresponding resource file >> (src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage.properties) >> doesn't contain this key. This results in long not user friendly >> stacktraces in output when jimage cannot create a directory. The fix >> is very small, I added the missing definition into the resource file. >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8170113 >>> WEBREV: http://cr.openjdk.java.net/~dkononenko/8170113/webrev.00 >>> >> This looks okay as a short term fix but I think that extract need to >> be-implemented to use the new file system API so that the reasons why >> >> the directory can be printed too. Also there is an anomaly in errors >> related to the directory result in an error message whereas any errors >> >> extracting to the directory lead to an exception. >> >> -Alan > > > I think we might have to defer such big change to the next release. If there's no objections I'd propose to deliver this fix AS IS and open a new enhancement request to re-implement 'extract' method. > > Thank you, > Denis. From Alan.Bateman at oracle.com Thu Feb 9 15:55:52 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 9 Feb 2017 15:55:52 +0000 Subject: [9] RFR 8170113: jimage extract to readonly directory causes MissingResourceException In-Reply-To: References: Message-ID: On 09/02/2017 10:03, Denis Kononenko wrote: > : > > I think we might have to defer such big change to the next release. If there's no objections I'd propose to deliver this fix AS IS and open a new enhancement request to re-implement 'extract' method. > Okay but can you create a bug in JBS so that it's not forgotten? -Alan From alan.bateman at oracle.com Thu Feb 9 16:15:56 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 09 Feb 2017 16:15:56 +0000 Subject: hg: jigsaw/jake/jdk: 3 new changesets Message-ID: <201702091615.v19GFuAV022258@aojmv0008.oracle.com> Changeset: 01d8583c6ecd Author: alanb Date: 2017-02-09 11:25 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/01d8583c6ecd Add missing @JPMS tags, minor javadoc updates ! src/java.base/share/classes/java/lang/IllegalCallerException.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java ! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java ! test/java/lang/module/ModuleDescriptorTest.java Changeset: ed5e88027114 Author: alanb Date: 2017-02-09 15:38 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ed5e88027114 More tests for jlr.Module::addXXX + test/java/lang/reflect/Module/addXXX/Driver.java + test/java/lang/reflect/Module/addXXX/m1/module-info.java + test/java/lang/reflect/Module/addXXX/m1/p1/C.java + test/java/lang/reflect/Module/addXXX/m2/module-info.java + test/java/lang/reflect/Module/addXXX/m2/p2/C.java + test/java/lang/reflect/Module/addXXX/m2/p2/internal/C.java + test/java/lang/reflect/Module/addXXX/m3/module-info.java + test/java/lang/reflect/Module/addXXX/m3/p3/C.java + test/java/lang/reflect/Module/addXXX/m4/module-info.java + test/java/lang/reflect/Module/addXXX/m4/p4/C.java + test/java/lang/reflect/Module/addXXX/test/module-info.java + test/java/lang/reflect/Module/addXXX/test/test/C.java + test/java/lang/reflect/Module/addXXX/test/test/Main.java + test/java/lang/reflect/Module/addXXX/test/test/Service.java Changeset: ee4732b0e6e0 Author: alanb Date: 2017-02-09 15:50 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ee4732b0e6e0 Remove @revised/@spec from RB.Control.toBundleName ! src/java.base/share/classes/java/util/ResourceBundle.java From denis.kononenko at oracle.com Thu Feb 9 18:27:30 2017 From: denis.kononenko at oracle.com (Denis Kononenko) Date: Thu, 9 Feb 2017 10:27:30 -0800 (PST) Subject: [9] RFR: 8169715: jimage fails with IAE when attempts to inspect an empty file Message-ID: <7666a451-ff4f-4850-a373-9c878b77a51f@default> Hi, Could please someone review the fix for JDK-8169715. The problem occurs when jimage tool is attempting to read an empty or incomplete image. The current implementation works with ByteBuffer and always relies on that there's enough data to inspect the image. This results in IAE inside of BasicImageReader.slice method when the buffer is smaller then it's expected. I added a few checks to avoid IAE and throw IOException with a more descriptive text. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8169715 WEBREV: http://cr.openjdk.java.net/~dkononenko/8169715/webrev.01 Thank you, Denis. From james.connors at oracle.com Thu Feb 9 18:42:54 2017 From: james.connors at oracle.com (Jim Connors) Date: Thu, 9 Feb 2017 13:42:54 -0500 Subject: jlink RuntimeException: descriptor returns inconsistent package set Message-ID: <0ee41ff8-6682-fe7c-7ecc-315f430c8a09@oracle.com> Trying to create JDK9 runtime image that includes only the necessary modules to run a JavaFX program called Scoreboard. It has been converted to a JDK9 module called Scoreboard and has dependencies on system modules as well as another module called com.jtconnors.socket. More details below, this program runs fine when invoked with jdk9-ea+155 as follows (Scoreboard.jar and com.jtconnors.socket.jar are in the current directory): C:\tmp\scratch>java --module-path . -m Scoreboard However when attempting to create the jlink image as follows, this error message appears: C:\tmp\scratch>jlink --module-path .;\Users\jtconnor\jdk-9\jmods --add-modules S coreboard --output reducedImage --compress=2 --strip-debug Error: java.lang.RuntimeException: Module Scoreboard's descriptor returns incons istent package set Here are step-by-step details, First thing shown here is what worked: Example 1: create was a reduced Jdk9 runtime image that includes just the com.jtconnors.socket module with all it's dependencies. Here's what the module-info.java file for com.jtconnors.socket looks like: module com.jtconnors.socket { requires java.base; requires java.logging; exports com.jtconnors.socket; exports com.jtconnors.socket.test; } Here's my PATH: C:\tmp\scratch>echo %PATH% C:\users\jtconnor\jdk-9\bin;C:\ProgramData\Oracle\Java\javapath;D:\Oracle\jdk8\b in;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\W indowsPowerShell\v1.0\;C:\Program Files\nodejs\;D:\Oracle\mysql-5.7.16-winx64\bi n\;C:\Users\jtconnor\jdk-9\bin;C:\Users\jtconnor\AppData\Roaming\npm And here's what java -version says: C:\tmp\scratch>java -version java version "9-ea" Java(TM) SE Runtime Environment (build 9-ea+155) Java HotSpot(TM) 64-Bit Server VM (build 9-ea+155, mixed mode) The com.jtconnors.socket.jar file is in the C:\tmp\scratch directory: C:\tmp\scratch>dir Volume in drive C has no label. Volume Serial Number is 5C29-8814 Directory of C:\tmp\scratch 02/08/2017 07:39 PM . 02/08/2017 07:39 PM .. 02/08/2017 07:03 PM 60,051 com.jtconnors.socket.jar 1 File(s) 60,051 bytes 2 Dir(s) 299,772,723,200 bytes free jdeps output for com.jtconnors.socket: C:\tmp\scratch>jdeps -s com.jtconnors.socket.jar com.jtconnors.socket -> java.base com.jtconnors.socket -> java.logging Created a runtime image as follows: C:\tmp\scratch>jlink --module-path .;\users\jtconnor\jdk-9\jmods --add-modules com.jtconnors.socket --output reducedImage --compress=2 --strip-debub Run java -version with thereducedImage runtime C:\tmp\scratch>reducedImage\bin\java -version java version "9-ea" Java(TM) SE Runtime Environment (build 9-ea+155) Java HotSpot(TM) 64-Bit Server VM (build 9-ea+155, mixed mode) List the modules in the reducedImage runtime: C:\tmp\scratch>reducedImage\bin\java --list-modules com.jtconnors.socket java.base at 9-ea java.logging at 9-ea Run test program that comes with the com.jtconnors.socket module: C:\tmp\scratch>reducedImage\bin\java -m com.jtconnors.socket/com.jtconnors.socke t.test.SocketServerReceiver Feb 08, 2017 7:48:32 PM com.jtconnors.socket.test.SocketServerReceiver initSocke tConnection INFO: Waiting for connection Example 2: Trying to create a jlink image for the Scoreboard application, this is where jlink produces a RuntimeException Here's what Scoreboard's module-info.java file looks like: module Scoreboard { requires java.base; requires com.jtconnors.socket; requires java.logging; requires java.xml; requires javafx.base; requires javafx.controls; requires javafx.graphics; requires javafx.media; exports scoreboard.fx2; } jdeps output for Scoreboard.jar: C:\tmp\scratch>jdeps --module-path . -s Scoreboard.jar Scoreboard -> com.jtconnors.socket Scoreboard -> java.base Scoreboard -> java.logging Scoreboard -> java.xml Scoreboard -> javafx.base Scoreboard -> javafx.controls Scoreboard -> javafx.graphics Scoreboard -> javafx.media Attempted to create a runtime image as follows and got this output: C:\tmp\scratch>jlink --module-path .;\Users\jtconnor\jdk-9\jmods --add-modules S coreboard --output reducedImage --compress=2 --strip-debug Error: java.lang.RuntimeException: Module Scoreboard's descriptor returns incons istent package set From bob.vandette at oracle.com Thu Feb 9 19:51:52 2017 From: bob.vandette at oracle.com (Bob Vandette) Date: Thu, 9 Feb 2017 14:51:52 -0500 Subject: Fwd: libjvm.so, jmods and --with-native-debug-symbols=internal References: <20170209174109.GC2814@redhat.com> Message-ID: <9DC3341C-30FF-4FF7-826A-8137FC4E7CA6@oracle.com> My assumption is that this was intentional. Forwarding to the jigsaw team for clarification. The native libraries associated with java.base are needed in the jmod file in order to allow developers to run jlink to produce custom Java runtimes. So, independent of having debug information, delivering a JDK with jmods provides the additional benefit of allowing custom runtimes to be produces but comes with an increased distribution cost. I suppose we could store stripped shared libraries, but this would result in a loss of information and capability when generating custom Java runtimes with jlink. Bob. > Begin forwarded message: > > From: Omair Majid > Subject: libjvm.so, jmods and --with-native-debug-symbols=internal > Date: February 9, 2017 at 12:41:09 PM EST > To: build-dev > > Hi, > > I have been working on building preview versions of OpenJDK 9 for > Fedora. You can see the latest build here: > https://copr.fedorainfracloud.org/coprs/omajid/openjdk9/build/509314/ > > One thing that I just realized is that we build OpenJDK 9 using the > configure option --with-native-debug-symbols=internal. As far as I > understand the build, this is what happens: > > 1. libjvm.so is built > 2. libjvm.so is not stripped of any debug information > 3. a jmod - java.base.jmod - containing libjvm.so is created > 4. the jmod containing libjvm.so is extracted to create images/jdk/ (and > images/jre/) > > Then the linux packaging tools (rpmbuild in my case) take over and do > the following: > > 5. strip libjvm.so in images/jdk/, put stripped symbols in a separate > location > 6. Package up images/jdk/ into the distribution package > 7. make a -debuginfo package (or -dbg in case of Debian) that contains > the stripped symbols from libjvm.so > > So now users get a libjvm.so in the default package that's stripped and > less than 20MB. They also get an optional -debuginfo (or -dbg) package > that contains just the debug symbols. This lets them use the small > package containing libjvm and but also lets them download a large > package to debug libjvm.so if they wish. This is all great so far and > works like it should. > > One new change that happened with OpenJDK 9 only is that the jmod > (java.base.jmod here) contains the original and unstripped libjvm.so. > This jmod also gets included into the images/jdk/. This bumps up the > images/jdk/jmods directory size to hundreds of megabytes. Anyone who now > wants to use jmods now ends up installing all the unstripped debuginfo, > unintentionally, eating up disk space. > > Is this intentional or an unintended side-effect of various changes? Is > it a known issue? > > Thanks, > Omair > > -- > PGP Key: 66484681 (http://pgp.mit.edu/) > Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From alan.bateman at oracle.com Thu Feb 9 20:53:41 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 09 Feb 2017 20:53:41 +0000 Subject: hg: jigsaw/jake/corba: 2 new changesets Message-ID: <201702092053.v19KrfOj003584@aojmv0008.oracle.com> Changeset: e81838a0d0ff Author: lana Date: 2017-02-09 17:21 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/e81838a0d0ff Added tag jdk-9+156 for changeset 907c26240cd4 ! .hgtags Changeset: 4c5b0c240dcf Author: alanb Date: 2017-02-09 20:53 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/4c5b0c240dcf Merge ! .hgtags From alan.bateman at oracle.com Thu Feb 9 20:53:39 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 09 Feb 2017 20:53:39 +0000 Subject: hg: jigsaw/jake/jaxws: 3 new changesets Message-ID: <201702092053.v19Krdsn003476@aojmv0008.oracle.com> Changeset: 7c829eba7814 Author: lancea Date: 2017-02-04 14:03 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/7c829eba7814 8173604: Rename module 8173604 java.annotations.common to java.xml.ws.annoations Reviewed-by: dfuchs, alanb, psandoz, mchung - src/java.annotations.common/share/classes/javax/annotation/Generated.java - src/java.annotations.common/share/classes/javax/annotation/PostConstruct.java - src/java.annotations.common/share/classes/javax/annotation/PreDestroy.java - src/java.annotations.common/share/classes/javax/annotation/Resource.java - src/java.annotations.common/share/classes/javax/annotation/Resources.java - src/java.annotations.common/share/classes/module-info.java + src/java.xml.ws.annotation/share/classes/javax/annotation/Generated.java + src/java.xml.ws.annotation/share/classes/javax/annotation/PostConstruct.java + src/java.xml.ws.annotation/share/classes/javax/annotation/PreDestroy.java + src/java.xml.ws.annotation/share/classes/javax/annotation/Resource.java + src/java.xml.ws.annotation/share/classes/javax/annotation/Resources.java + src/java.xml.ws.annotation/share/classes/module-info.java ! src/java.xml.ws/share/classes/module-info.java Changeset: 78a7ade93491 Author: lana Date: 2017-02-09 17:21 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/78a7ade93491 Added tag jdk-9+156 for changeset 7c829eba7814 ! .hgtags Changeset: 09abcf67bf67 Author: alanb Date: 2017-02-09 20:53 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/09abcf67bf67 Merge ! .hgtags - src/java.annotations.common/share/classes/javax/annotation/Generated.java - src/java.annotations.common/share/classes/javax/annotation/PostConstruct.java - src/java.annotations.common/share/classes/javax/annotation/PreDestroy.java - src/java.annotations.common/share/classes/javax/annotation/Resource.java - src/java.annotations.common/share/classes/javax/annotation/Resources.java - src/java.annotations.common/share/classes/module-info.java + src/java.xml.ws.annotation/share/classes/module-info.java ! src/java.xml.ws/share/classes/module-info.java From alan.bateman at oracle.com Thu Feb 9 20:53:42 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 09 Feb 2017 20:53:42 +0000 Subject: hg: jigsaw/jake/jaxp: 3 new changesets Message-ID: <201702092053.v19Krg1r003642@aojmv0008.oracle.com> Changeset: e930c373aaa4 Author: clanger Date: 2017-02-06 11:03 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/e930c373aaa4 8173602: JAXP: TESTBUG: javax/xml/jaxp/unittest/transform/TransformerTest.java needs refactoring Reviewed-by: dfuchs ! test/javax/xml/jaxp/unittest/transform/TransformerTest.java + test/javax/xml/jaxp/unittest/transform/util/TransformerTestTemplate.java Changeset: d488b3eda964 Author: lana Date: 2017-02-09 17:21 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/d488b3eda964 Added tag jdk-9+156 for changeset e930c373aaa4 ! .hgtags Changeset: ef8daebf2401 Author: alanb Date: 2017-02-09 20:53 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/ef8daebf2401 Merge ! .hgtags From alan.bateman at oracle.com Thu Feb 9 20:53:42 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 09 Feb 2017 20:53:42 +0000 Subject: hg: jigsaw/jake: 19 new changesets Message-ID: <201702092053.v19KrgWv003628@aojmv0008.oracle.com> Changeset: 7254856d7081 Author: mchung Date: 2017-01-31 20:06 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/7254856d7081 8173608: Separate JDK management agent from java.management module Reviewed-by: dfuchs, dholmes, erikj ! common/bin/unshuffle_list.txt ! make/common/Modules.gmk Changeset: 1588d044d709 Author: ihse Date: 2017-02-02 12:05 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/1588d044d709 8173107: Fix autoconf/spec.gmk mismatches Reviewed-by: erikj, dholmes ! common/autoconf/basics.m4 ! common/autoconf/boot-jdk.m4 ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/hotspot.m4 ! common/autoconf/jdk-options.m4 ! common/autoconf/lib-bundled.m4 ! common/autoconf/platform.m4 ! common/autoconf/spec.gmk.in Changeset: 7f45dad2b358 Author: dfuchs Date: 2017-02-02 16:50 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/7f45dad2b358 8173607: JMX RMI connector should be in its own module Summary: The JMX RMI connector is moved to a new java.management.rmi module. Reviewed-by: mchung, erikj ! common/bin/unshuffle_list.txt ! make/CompileJavaModules.gmk ! make/Images.gmk ! make/common/Modules.gmk Changeset: 747de1af8677 Author: lana Date: 2017-02-02 21:55 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/747de1af8677 Merge Changeset: 399e657450f7 Author: ihse Date: 2017-02-03 14:32 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/399e657450f7 8172912: JTReg concurrency value must be limited Reviewed-by: erikj ! test/Makefile Changeset: 96a95d5c0a08 Author: ihse Date: 2017-02-03 14:34 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/96a95d5c0a08 8059000: hgforest: pass options to serve command Reviewed-by: erikj Contributed-by: Michael Duigou ! common/bin/hgforest.sh Changeset: 192d08d80725 Author: ihse Date: 2017-02-03 15:19 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/192d08d80725 8004842: Unify values of boolean make variables set in configure to true/false Reviewed-by: erikj ! common/autoconf/build-performance.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 ! common/autoconf/spec.gmk.in ! make/common/NativeCompilation.gmk Changeset: 65a40732289f Author: bmoloden Date: 2016-12-21 14:41 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/65a40732289f 8170918: Remove shell script from test/compiler/c2/cr7200264/TestIntVect.java Reviewed-by: kvn ! test/jtreg-ext/requires/VMProps.java Changeset: 06f04261fc85 Author: jwilhelm Date: 2016-12-27 22:34 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/06f04261fc85 Merge Changeset: 8aa52f222681 Author: iignatyev Date: 2016-12-28 18:37 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/8aa52f222681 8172094: 8171433 changes in generated-configure should be restored Reviewed-by: erikj, kzhaldyb ! common/autoconf/generated-configure.sh Changeset: 5e9026997790 Author: jwilhelm Date: 2017-01-09 17:10 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/5e9026997790 Merge ! common/autoconf/generated-configure.sh Changeset: 2cbdf0b3aa54 Author: jwilhelm Date: 2017-01-13 18:26 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/2cbdf0b3aa54 Merge ! common/autoconf/generated-configure.sh Changeset: d660c00d91bf Author: jcm Date: 2017-01-17 21:39 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/d660c00d91bf 8166002: Emulate client build on platforms with reduced virtual address space Summary: The default VM ergonomics on Windows/x86 (32-bit) are changed to client like. Reviewed-by: kvn, iveresov ! test/jtreg-ext/requires/VMProps.java ! test/lib/jdk/test/lib/Platform.java Changeset: 80194979fde3 Author: gtriantafill Date: 2017-01-19 10:55 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/80194979fde3 8152206: Simplify jvmstat modules Reviewed-by: alanb, mchung, hseigel ! common/bin/unshuffle_list.txt ! make/CompileJavaModules.gmk Changeset: bb5dc9acb43b Author: jwilhelm Date: 2017-01-24 00:30 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/bb5dc9acb43b Merge ! common/autoconf/generated-configure.sh ! make/CompileJavaModules.gmk Changeset: 6f4d9e237e78 Author: jwilhelm Date: 2017-02-04 03:29 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/6f4d9e237e78 Merge ! common/autoconf/generated-configure.sh ! common/bin/unshuffle_list.txt ! make/CompileJavaModules.gmk Changeset: 783ec7542cf7 Author: lancea Date: 2017-02-04 14:02 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/783ec7542cf7 8173604: Rename module 8173604 java.annotations.common to java.xml.ws.annoations Reviewed-by: dfuchs, alanb, psandoz, mchung ! common/bin/unshuffle_list.txt ! make/common/Modules.gmk Changeset: 2b376ad027b6 Author: lana Date: 2017-02-09 17:21 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/2b376ad027b6 Added tag jdk-9+156 for changeset 783ec7542cf7 ! .hgtags Changeset: 66442ef5e460 Author: alanb Date: 2017-02-09 20:53 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/66442ef5e460 Merge ! .hgtags ! common/autoconf/basics.m4 ! common/autoconf/boot-jdk.m4 ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/hotspot.m4 ! common/autoconf/jdk-options.m4 ! common/autoconf/platform.m4 ! common/autoconf/spec.gmk.in ! common/bin/hgforest.sh ! make/CompileJavaModules.gmk ! make/Images.gmk ! make/common/Modules.gmk ! make/common/NativeCompilation.gmk From alan.bateman at oracle.com Thu Feb 9 20:53:42 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 09 Feb 2017 20:53:42 +0000 Subject: hg: jigsaw/jake/langtools: 30 new changesets Message-ID: <201702092053.v19KrhoE003648@aojmv0008.oracle.com> Changeset: 1eb97b415d28 Author: rfield Date: 2017-01-31 17:01 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/1eb97b415d28 8173652: jshell tool: store history on fatal exit Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java Changeset: f38d10d479c1 Author: jlahoda Date: 2017-02-01 15:03 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/f38d10d479c1 8171294: Slow compilation with long classpaths under JDK 9 Summary: Precompute packages contained in jars, to quickly determine at the lookup time whether a jar contains the given package Reviewed-by: jjg Contributed-by: maurizio.cimadamore at oracle.com ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java Changeset: ca18223ce9ee Author: rfield Date: 2017-02-01 09:10 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/ca18223ce9ee 8173577: JShell tests: Some testng tests check nothing Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/jdk/jshell/execution/FailOverExecutionControlProvider.java ! src/jdk.jshell/share/classes/jdk/jshell/execution/JdiDefaultExecutionControl.java ! test/jdk/jshell/ExecutionControlTestBase.java ! test/jdk/jshell/FailOverDirectExecutionControlTest.java ! test/jdk/jshell/FailOverExecutionControlDyingLaunchTest.java Changeset: ec4be8a26914 Author: darcy Date: 2017-02-01 11:25 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/ec4be8a26914 8173676: Improvements to javax.annotation.processing and javax.lang.model doc Reviewed-by: anazarov ! src/java.compiler/share/classes/javax/annotation/processing/Filer.java ! src/java.compiler/share/classes/javax/annotation/processing/FilerException.java ! src/java.compiler/share/classes/javax/annotation/processing/Processor.java ! src/java.compiler/share/classes/javax/annotation/processing/RoundEnvironment.java ! src/java.compiler/share/classes/javax/lang/model/AnnotatedConstruct.java ! src/java.compiler/share/classes/javax/lang/model/UnknownEntityException.java ! src/java.compiler/share/classes/javax/lang/model/element/Element.java ! src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java ! src/java.compiler/share/classes/javax/lang/model/element/NestingKind.java ! src/java.compiler/share/classes/javax/lang/model/element/PackageElement.java ! src/java.compiler/share/classes/javax/lang/model/element/Parameterizable.java ! src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java ! src/java.compiler/share/classes/javax/lang/model/element/UnknownAnnotationValueException.java ! src/java.compiler/share/classes/javax/lang/model/element/UnknownElementException.java ! src/java.compiler/share/classes/javax/lang/model/element/package-info.java ! src/java.compiler/share/classes/javax/lang/model/type/IntersectionType.java ! src/java.compiler/share/classes/javax/lang/model/type/UnionType.java ! src/java.compiler/share/classes/javax/lang/model/type/UnknownTypeException.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementFilter.java ! src/java.compiler/share/classes/javax/lang/model/util/Elements.java Changeset: 3163200b0279 Author: ksrini Date: 2017-01-27 10:08 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/3163200b0279 8048628: javadoc strips HTML incorrectly; causes invalid generated HTML files Reviewed-by: jjg ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java + test/com/sun/javadoc/testNonInlineHtmlTagRemoval/C.java + test/com/sun/javadoc/testNonInlineHtmlTagRemoval/TestNonInlineHtmlTagRemoval.java + test/jdk/javadoc/doclet/testNonInlineHtmlTagRemoval/C.java + test/jdk/javadoc/doclet/testNonInlineHtmlTagRemoval/TestNonInlineHtmlTagRemoval.java Changeset: b44fd58920e0 Author: jjg Date: 2017-02-01 14:38 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/b44fd58920e0 8173789: Fix broken test header Reviewed-by: darcy ! test/tools/javac/modules/ModulesAndModuleSourcePathTest.java Changeset: e9135022bef8 Author: bpatel Date: 2017-02-01 15:16 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/e9135022bef8 8169813: The index pages are sorted in a confusing manner Reviewed-by: jjg, ksrini ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java ! test/jdk/javadoc/doclet/testOrdering/TestOrdering.java Changeset: 23f90afa1006 Author: darcy Date: 2017-02-01 17:04 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/23f90afa1006 8173776: More javax.lang.model improvements to support modules Reviewed-by: jjg, jlahoda ! src/java.compiler/share/classes/javax/lang/model/element/Element.java ! src/java.compiler/share/classes/javax/lang/model/element/PackageElement.java ! src/java.compiler/share/classes/javax/lang/model/type/NoType.java ! src/java.compiler/share/classes/javax/lang/model/util/Elements.java ! test/tools/javac/processing/model/element/TestPackageElement.java Changeset: fed0944bb38a Author: darcy Date: 2017-02-01 19:48 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/fed0944bb38a 8173798: Tests for printing modules Reviewed-by: darcy Contributed-by: bsrbnd at gmail.com + test/tools/javac/processing/model/util/printing/module-info.java + test/tools/javac/processing/model/util/printing/module-info.out + test/tools/javac/processing/model/util/printing/p/P.java Changeset: 1fee6f0b43ba Author: bpatel Date: 2017-02-01 20:14 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/1fee6f0b43ba 8172528: problem generating JavaFX docs Reviewed-by: ksrini Contributed-by: jonathan.gibbons at oracle.com ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PropertyWriterImpl.java ! test/jdk/javadoc/doclet/testJavaFX/TestJavaFX.java Changeset: dc59890c8a7e Author: jjg Date: 2017-02-02 11:40 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/dc59890c8a7e 8166675: Latent bug in jar file handling during module path processing. Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java ! test/tools/javac/file/LimitedImage.java Changeset: b281bea7ebe9 Author: ksrini Date: 2017-02-02 10:50 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/b281bea7ebe9 8173667: Update command line help for -public -protected -package -private options Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/resources/javadoc.properties Changeset: 0206870ea5af Author: lana Date: 2017-02-02 21:55 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/0206870ea5af Merge Changeset: fa6d7795efcd Author: jjg Date: 2017-02-02 14:34 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/fa6d7795efcd 8172807: Javac doesn't report errors on duplicate provides with different service implementations Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.jshell/share/classes/module-info.java ! test/tools/javac/diags/examples/DuplicateProvides/module-info.java + test/tools/javac/diags/examples/RepeatedProvidesForService/RepeatedProvides.java + test/tools/javac/diags/examples/RepeatedProvidesForService/modulesourcepath/m/module-info.java + test/tools/javac/diags/examples/RepeatedProvidesForService/modulesourcepath/m/p/A.java + test/tools/javac/diags/examples/RepeatedProvidesForService/modulesourcepath/m/p/B.java + test/tools/javac/diags/examples/RepeatedProvidesForService/modulesourcepath/m/p/I.java ! test/tools/javac/modules/ProvidesTest.java Changeset: 356966a1eed9 Author: bpatel Date: 2017-02-02 14:55 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/356966a1eed9 8173707: Javadoc generated pages should default to no-frames view Reviewed-by: jjg, ksrini ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/FrameOutputWriter.java ! test/jdk/javadoc/doclet/testFramesNoFrames/TestFramesNoFrames.java ! test/jdk/javadoc/doclet/testHtmlVersion/TestHtmlVersion.java Changeset: 7bb9b0d10b22 Author: vromero Date: 2017-02-03 08:16 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/7bb9b0d10b22 8172240: javac should not need the transitive closure to compile a module Reviewed-by: jjg Contributed-by: jan.lahoda at oracle.com ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java + test/tools/javac/modules/MissingModuleTest.java Changeset: 693a87020034 Author: darcy Date: 2017-02-03 22:09 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/693a87020034 8173305: Trial reversion of langtools test changes for limited win32 address space Reviewed-by: jjg, amlu ! test/tools/javac/lambda/intersection/IntersectionTargetTypeTest.java ! test/tools/javac/tree/JavacTreeScannerTest.java ! test/tools/javac/tree/SourceTreeScannerTest.java ! test/tools/javac/tree/TreePosTest.java ! test/tools/javac/varargs/7043922/T7043922.java Changeset: 31f3cfd70930 Author: lancea Date: 2017-02-04 14:05 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/31f3cfd70930 8173604: Rename module 8173604 java.annotations.common to java.xml.ws.annoations Reviewed-by: dfuchs, alanb, psandoz, mchung ! test/tools/javac/modules/AddLimitMods.java ! test/tools/jdeps/modules/SplitPackage.java Changeset: a9477dca2b57 Author: sadayapalam Date: 2017-02-06 13:12 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/a9477dca2b57 8173456: com.sun.tools.javac.util.Assert.error during code compilation Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/lambda/MethodReferenceNoThisTest.java + test/tools/javac/lambda/MethodReferenceNoThisTest.out Changeset: d22a3e726157 Author: jlahoda Date: 2017-02-06 11:11 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/d22a3e726157 8173653: jshell tool: ctrl-C when in external editor aborts jshell -- history lost Summary: Disable Ctrl-C while running external editors. Reviewed-by: rfield ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java Changeset: ceeaf4cf083f Author: sadayapalam Date: 2017-02-06 18:14 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/ceeaf4cf083f 8166420: Confusing error message when reading bad module declaration Reviewed-by: jlahoda ! 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/parser/ParserFactory.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.jshell/share/classes/jdk/jshell/ReplParserFactory.java + test/tools/javac/diags/examples/UnexpectedTokenInModuleInfo/module-info.java + test/tools/javac/modules/UnexpectedTokenInModuleInfoTest.java ! test/tools/javac/parser/extend/TrialParserFactory.java Changeset: dee2b0b32d77 Author: jlahoda Date: 2017-02-06 15:57 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/dee2b0b32d77 8173636: Results from Processor.getSupportedAnnotationTypes should be intepreted strictly Reviewed-by: darcy, jjg Contributed-by: joe.darcy at oracle.com, jan.lahoda at oracle.com ! src/java.compiler/share/classes/javax/annotation/processing/AbstractProcessor.java ! src/java.compiler/share/classes/javax/annotation/processing/Processor.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! test/tools/javac/modules/AnnotationProcessing.java Changeset: eb374ab43848 Author: rfield Date: 2017-02-06 09:00 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/eb374ab43848 8173848: JShell: less-than causes: reached end of file while parsing Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/jdk/jshell/CompletenessAnalyzer.java ! src/jdk.jshell/share/classes/jdk/jshell/Eval.java ! src/jdk.jshell/share/classes/jdk/jshell/ReplParser.java ! src/jdk.jshell/share/classes/jdk/jshell/ReplParserFactory.java ! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java ! src/jdk.jshell/share/classes/jdk/jshell/TaskFactory.java ! test/jdk/jshell/SimpleRegressionTest.java ! test/jdk/jshell/ToolSimpleTest.java Changeset: e03fdd8cad0c Author: rfield Date: 2017-02-06 09:25 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/e03fdd8cad0c 8173807: JShell: control characters should be escaped in String values Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/jdk/jshell/execution/DirectExecutionControl.java ! test/jdk/jshell/SimpleRegressionTest.java Changeset: 25c52a7a2ef0 Author: jjg Date: 2017-02-06 12:35 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/25c52a7a2ef0 8172901: javac: 'opens' statement cannot specify non observable package Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.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 - test/tools/javac/diags/examples/PackageEmptyOrNotFound/PackageEmptyOrNotFound.java - test/tools/javac/diags/examples/PackageEmptyOrNotFound/modulesourcepath/m1x/module-info.java + test/tools/javac/diags/examples/PackageEmptyOrNotFoundError/PackageEmptyOrNotFound.java + test/tools/javac/diags/examples/PackageEmptyOrNotFoundError/modulesourcepath/m1x/module-info.java + test/tools/javac/diags/examples/PackageEmptyOrNotFoundWarning/PackageEmptyOrNotFound.java + test/tools/javac/diags/examples/PackageEmptyOrNotFoundWarning/modulesourcepath/m1x/module-info.java ! test/tools/javac/modules/ReportNonExistentPackageTest.java Changeset: a32aa9e380e5 Author: darcy Date: 2017-02-06 16:32 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/a32aa9e380e5 8173944: Reference Origin.MANDATED in getEnclosedElements specs Reviewed-by: jlahoda ! src/java.compiler/share/classes/javax/lang/model/element/Element.java ! src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java ! src/java.compiler/share/classes/javax/lang/model/util/Elements.java Changeset: 9a966d7c4708 Author: jjg Date: 2017-02-06 17:51 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/9a966d7c4708 8174051: fix terminology in javadoc comment Reviewed-by: darcy ! src/jdk.compiler/share/classes/com/sun/source/tree/ImportTree.java Changeset: 6f91e41163bc Author: cushon Date: 2017-02-06 17:19 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/6f91e41163bc 6388543: improve accuracy of source positions for AnnotationValue param of Messager.printMessage Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/model/JavacElements.java ! test/tools/javac/processing/messager/6362067/T6362067.out + test/tools/javac/processing/messager/6388543/T6388543.java + test/tools/javac/processing/messager/6388543/T6388543.out Changeset: b5314160b084 Author: lana Date: 2017-02-09 17:21 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/b5314160b084 Added tag jdk-9+156 for changeset 6f91e41163bc ! .hgtags Changeset: 487f4f434f62 Author: alanb Date: 2017-02-09 20:53 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/487f4f434f62 Merge ! .hgtags ! src/java.compiler/share/classes/javax/lang/model/element/Element.java ! src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java ! src/java.compiler/share/classes/javax/lang/model/element/PackageElement.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementFilter.java ! src/java.compiler/share/classes/javax/lang/model/util/Elements.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/model/JavacElements.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/resources/javadoc.properties ! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java ! src/jdk.jshell/share/classes/jdk/jshell/TaskFactory.java ! src/jdk.jshell/share/classes/module-info.java ! test/jdk/javadoc/doclet/testHtmlVersion/TestHtmlVersion.java ! test/jdk/javadoc/doclet/testJavaFX/TestJavaFX.java - test/tools/javac/diags/examples/PackageEmptyOrNotFound/PackageEmptyOrNotFound.java - test/tools/javac/diags/examples/PackageEmptyOrNotFound/modulesourcepath/m1x/module-info.java + test/tools/javac/diags/examples/PackageEmptyOrNotFoundError/modulesourcepath/m1x/module-info.java + test/tools/javac/diags/examples/PackageEmptyOrNotFoundWarning/modulesourcepath/m1x/module-info.java ! test/tools/javac/modules/AddLimitMods.java ! test/tools/javac/modules/AnnotationProcessing.java ! test/tools/javac/modules/ProvidesTest.java ! test/tools/javac/modules/ReportNonExistentPackageTest.java ! test/tools/jdeps/modules/SplitPackage.java From alan.bateman at oracle.com Thu Feb 9 20:53:44 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 09 Feb 2017 20:53:44 +0000 Subject: hg: jigsaw/jake/nashorn: 8 new changesets Message-ID: <201702092053.v19KriX7003657@aojmv0008.oracle.com> Changeset: ea1d4ecf5862 Author: hannesw Date: 2017-02-02 18:23 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/ea1d4ecf5862 8169481: StackOverflowError on start when parsing PAC file to autodetect Proxy settings Reviewed-by: jlaskey, sundar ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/WeighNodes.java ! test/script/basic/JDK-8030182_2.js + test/script/basic/JDK-8169481.js Changeset: e0aab84ee442 Author: hannesw Date: 2017-02-02 22:24 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/e0aab84ee442 8173851: JDK-8008448.js fails to parse test for JDK-8169481 Reviewed-by: jlaskey ! test/script/basic/JDK-8008448.js Changeset: 6a951429deb8 Author: lana Date: 2017-02-02 21:56 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/6a951429deb8 Merge Changeset: 0d99a6f2bf82 Author: amlu Date: 2017-02-03 17:32 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/0d99a6f2bf82 8173864: Problem list src/jdk/nashorn/api/tree/test/ParseAPITest.java for some platforms Reviewed-by: hannesw, sundar ! test/ProblemList.txt Changeset: 7562a97451bb Author: ihse Date: 2017-02-03 13:02 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/7562a97451bb 8173822: Remove dead code in BuildNashorn.gmk Reviewed-by: erikj ! make/BuildNashorn.gmk Changeset: d577398d3111 Author: hannesw Date: 2017-02-03 13:28 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/d577398d3111 8173888: Test for JDK-8169481 causes stack overflows in parser tests Reviewed-by: jlaskey, sundar ! test/ProblemList.txt ! test/script/basic/JDK-8008448.js - test/script/basic/JDK-8169481.js Changeset: c5b9b87b1742 Author: lana Date: 2017-02-09 17:21 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/c5b9b87b1742 Added tag jdk-9+156 for changeset d577398d3111 ! .hgtags Changeset: 98ed919f97b1 Author: alanb Date: 2017-02-09 20:53 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/98ed919f97b1 Merge ! .hgtags ! make/BuildNashorn.gmk From alan.bateman at oracle.com Thu Feb 9 20:53:53 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 09 Feb 2017 20:53:53 +0000 Subject: hg: jigsaw/jake/hotspot: 94 new changesets Message-ID: <201702092053.v19KrsQg003673@aojmv0008.oracle.com> Changeset: c1540251d1b7 Author: mchung Date: 2017-01-31 20:06 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c1540251d1b7 8173608: Separate JDK management agent from java.management module Reviewed-by: dfuchs, dholmes, erikj ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/management.cpp Changeset: 437734e70572 Author: lana Date: 2017-02-02 21:56 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/437734e70572 Merge Changeset: 34706140c7ff Author: ihse Date: 2017-02-03 15:20 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/34706140c7ff 8004842: Unify values of boolean make variables set in configure to true/false Reviewed-by: erikj ! make/lib/CompileJvm.gmk ! src/share/vm/precompiled/precompiled.hpp Changeset: b552b596203f Author: dfazunen Date: 2016-12-22 10:17 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b552b596203f 8170860: Get rid of the humanReadableByteCount() method in openjdk/hotspot Reviewed-by: mgerdin, mchernov ! test/gc/g1/TestHumongousShrinkHeap.java ! test/gc/g1/TestShrinkDefragmentedHeap.java ! test/gc/parallel/TestDynShrinkHeap.java ! test/gc/testlibrary/Helpers.java Changeset: adac66a3f770 Author: lucy Date: 2016-12-22 15:01 -0600 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/adac66a3f770 8170981: Possible access to char array with negative index Summary: Check arithmetic before trying to access array by index. Reviewed-by: rprotacio, dholmes, gziemski ! src/share/vm/runtime/globals.cpp Changeset: 5fa1aab53b6c Author: iveresov Date: 2016-12-22 17:26 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5fa1aab53b6c 8168792: [AOT] problems in MethodHandle with aot-compiled java.base Summary: Properly support assertions in AOT Reviewed-by: kvn ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/BinaryContainer.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/AOTBackend.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/Main.java ! src/jdk.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotNodePlugin.java ! src/share/vm/aot/aotCodeHeap.cpp ! src/share/vm/aot/aotCodeHeap.hpp Changeset: 5e3570b00a30 Author: gtriantafill Date: 2016-12-22 11:37 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5e3570b00a30 8171318: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java fails latest Jigsaw integration Reviewed-by: sspitsyn, dholmes ! test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapProc.java ! test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java Changeset: a5c9b33c4fc1 Author: goetz Date: 2016-12-22 16:51 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a5c9b33c4fc1 8171924: Use SIZE_FORMAT to print size_t values. Reviewed-by: dholmes, tschatzl, coleenp, goetz Contributed-by: arno.zeller at sap.com ! src/share/vm/code/codeCache.cpp ! src/share/vm/gc/g1/g1BiasedArray.hpp ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jvmtiEnter.xsl ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/utilities/copy.cpp Changeset: 9cd4389354c0 Author: coleenp Date: 2016-12-23 15:09 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9cd4389354c0 Merge Changeset: 231847e0ffcd Author: mchernov Date: 2016-12-23 20:44 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/231847e0ffcd 8171045: gc/stress/TestStressG1Humongous.java fails to allocate the heap Reviewed-by: tschatzl, kzhaldyb ! test/ProblemList.txt ! test/gc/stress/TestStressG1Humongous.java Changeset: 330f4178b190 Author: iklam Date: 2016-12-15 19:26 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/330f4178b190 8171809: Remove unused CDS code from JDK 9 Reviewed-by: jiangli, ccheung, mseledtsov ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/classfile/systemDictionaryShared.hpp ! src/share/vm/memory/metaspaceShared.cpp Changeset: 2577c6ced18e Author: bmoloden Date: 2016-12-21 15:01 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2577c6ced18e 8170918: Remove shell script from test/compiler/c2/cr7200264/TestIntVect.java Reviewed-by: kvn ! test/TEST.ROOT - test/compiler/c2/cr7200264/Test7200264.sh + test/compiler/c2/cr7200264/TestDriver.java ! test/compiler/c2/cr7200264/TestIntVect.java + test/compiler/c2/cr7200264/TestSSE2IntVect.java + test/compiler/c2/cr7200264/TestSSE4IntVect.java Changeset: f92932a08d08 Author: iignatyev Date: 2016-12-23 22:28 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f92932a08d08 Merge Changeset: 012eb4e91cf7 Author: jwilhelm Date: 2016-12-27 22:34 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/012eb4e91cf7 Merge - test/compiler/c2/cr7200264/Test7200264.sh Changeset: 1a1893998a0a Author: iignatyev Date: 2016-12-30 20:11 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1a1893998a0a 8172149: CTW library should call System::exit Reviewed-by: vlivanov ! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/CompileTheWorld.java ! test/testlibrary_tests/ctw/ClassesDirTest.java ! test/testlibrary_tests/ctw/ClassesListTest.java ! test/testlibrary_tests/ctw/CtwTest.java ! test/testlibrary_tests/ctw/JarDirTest.java ! test/testlibrary_tests/ctw/JarsTest.java Changeset: 8d23544aa002 Author: rraghavan Date: 2017-01-02 00:26 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/8d23544aa002 8156762: test/compiler/ciReplay/TestVMNoCompLevel.java fails with - 'Unexpected exit code for negative case: [-client]: expected 0 to not equal 0' Summary: Corrected CLIENT_VM_AVAILABLE case Reviewed-by: dpochepk, zmajo ! test/compiler/ciReplay/TestVMNoCompLevel.java Changeset: b20c6bf7938a Author: rbackman Date: 2017-01-03 08:54 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b20c6bf7938a 8171082: [AOT] AOT'd SystemModules.modules() fails to load when too large Reviewed-by: kvn, redestad ! src/share/vm/aot/aotCodeHeap.cpp ! src/share/vm/jvmci/jvmciCodeInstaller.cpp ! src/share/vm/jvmci/jvmciCodeInstaller.hpp Changeset: 48e8af011dd5 Author: mlarsson Date: 2017-01-03 12:24 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/48e8af011dd5 8170855: Example for -Xlog:help do not contain one with multiple tags Reviewed-by: dholmes ! src/share/vm/logging/logConfiguration.cpp Changeset: acb3d6fa119b Author: mlarsson Date: 2017-01-03 12:25 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/acb3d6fa119b 8170857: Typo in -Xlog:help output Reviewed-by: dholmes ! src/share/vm/logging/logConfiguration.cpp Changeset: 9102f200c421 Author: mdoerr Date: 2017-01-03 11:22 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9102f200c421 8172145: C2: anti dependence missed because store hidden by membar Reviewed-by: kvn ! src/share/vm/adlc/formssel.cpp Changeset: 0c6ed760800c Author: goetz Date: 2016-12-27 16:10 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0c6ed760800c 8172049: [s390] Implement "JEP 270: Reserved Stack Areas for Critical Sections". Reviewed-by: mdoerr ! src/cpu/s390/vm/c1_LIRAssembler_s390.cpp ! src/cpu/s390/vm/globalDefinitions_s390.hpp ! src/cpu/s390/vm/globals_s390.hpp ! src/cpu/s390/vm/interp_masm_s390.cpp ! src/cpu/s390/vm/macroAssembler_s390.cpp ! src/cpu/s390/vm/macroAssembler_s390.hpp ! src/cpu/s390/vm/s390.ad ! src/cpu/s390/vm/stubGenerator_s390.cpp ! src/cpu/s390/vm/templateInterpreterGenerator_s390.cpp ! src/os_cpu/linux_s390/vm/os_linux_s390.cpp ! test/runtime/ReservedStack/ReservedStackTest.java Changeset: 96db752884e3 Author: mdoerr Date: 2017-01-03 17:17 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/96db752884e3 8172199: s390: Use same get_key_start_from_aescrypt_object implementation as PPC64 Reviewed-by: kvn ! src/share/vm/opto/library_call.cpp Changeset: dcb26b8ad997 Author: redestad Date: 2017-01-03 21:36 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/dcb26b8ad997 8172169: Re-examine String field optionality Reviewed-by: kvn, thartmann ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/javaClasses.inline.hpp ! src/share/vm/opto/graphKit.cpp Changeset: 8e139e328150 Author: vdeshpande Date: 2017-01-03 14:56 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/8e139e328150 8171974: Fix for R10 Register clobbering with usage of ExternalAddress Reviewed-by: kvn, rbackman ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86_sha.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp Changeset: c743d0025694 Author: ctornqvi Date: 2017-01-04 10:57 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c743d0025694 8168137: import-hotspot build target not removed from hotspot-ide-project Reviewed-by: erikj ! make/ide/CreateVSProject.gmk ! make/src/classes/build/tools/projectcreator/WinGammaPlatformVC10.java Changeset: 0b7902758a32 Author: kvn Date: 2017-01-04 11:44 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0b7902758a32 8172054: Aot tests should include Java assertions into AOT compiled code Reviewed-by: iveresov ! src/share/vm/aot/aotCodeHeap.cpp ! test/compiler/aot/AotCompiler.java ! test/compiler/aot/cli/jaotc/JaotcTestHelper.java Changeset: f99f3a34981a Author: coleenp Date: 2017-01-04 21:13 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f99f3a34981a 8172246: [TESTBUG] runtime/RedefineTests/RedefinePreviousVersions.java 'Class unloading: has_previous_versions = true' missing from stdout/stderr Summary: add boolean to gate redefinition start Reviewed-by: sspitsyn, dholmes ! test/runtime/RedefineTests/RedefinePreviousVersions.java Changeset: 57d199c7daa9 Author: thartmann Date: 2017-01-05 09:25 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/57d199c7daa9 8172010: [AOT] RecompilationTest.java fails with "expected compilation level after compilation to be no less than 1" Summary: Disabled probabilistic profiling to ensure recompilation of AOT compiled method. Reviewed-by: kvn, iveresov ! test/compiler/aot/RecompilationTest.java Changeset: 695f6ed18723 Author: gromero Date: 2016-12-15 08:56 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/695f6ed18723 8171266: PPC64: Add support to -XX:RTMSpinLoopCount=0 Reviewed-by: mdoerr, dholmes ! src/cpu/ppc/vm/macroAssembler_ppc.cpp ! src/cpu/ppc/vm/vm_version_ppc.cpp Changeset: 9ce93a5a916e Author: thartmann Date: 2017-01-06 10:55 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9ce93a5a916e 8171435: "assert(is_single_cpu() && !is_virtual()) failed: type check" with -XX:+PatchALot on SPARC Summary: Fixed several issues with PatchALot or unaligned accesses on SPARC. Reviewed-by: kvn ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! test/compiler/c1/CanonicalizeArrayLength.java Changeset: 522c8ddbaa67 Author: iklam Date: 2017-01-08 10:39 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/522c8ddbaa67 8170959: unloading archived shared class caused crash Reviewed-by: coleenp, sspitsyn, mockner ! src/share/vm/oops/instanceKlass.cpp Changeset: 019ee3b02acc Author: kzhaldyb Date: 2016-12-28 19:13 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/019ee3b02acc 8172098: A lot of gtests uses TEST instead of TEST_VM Reviewed-by: iignatyev ! test/native/code/test_dependencyContext.cpp ! test/native/gc/g1/test_workerDataArray.cpp ! test/native/logging/test_log.cpp ! test/native/logging/test_logConfiguration.cpp ! test/native/logging/test_logMessageTest.cpp ! test/native/logging/test_logTagSetDescriptions.cpp Changeset: 56d83ae0b1af Author: jwilhelm Date: 2017-01-09 15:10 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/56d83ae0b1af Merge - test/compiler/c2/cr7200264/Test7200264.sh Changeset: 026ff073b5ad Author: davleopo Date: 2017-01-09 19:36 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/026ff073b5ad 8166125: [JVMCI] Missing JVMCI flag default values Reviewed-by: twisti, kvn ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp Changeset: 0d7ed565fe00 Author: dpochepk Date: 2017-01-10 20:45 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0d7ed565fe00 8166374: compiler/loopopts/UseCountedLoopSafepointsTest.java fails with "Safepoint not found" Reviewed-by: thartmann ! test/compiler/loopopts/UseCountedLoopSafepointsTest.java Changeset: b12bf3e848db Author: iveresov Date: 2017-01-10 21:39 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b12bf3e848db 8172310: [AOT] Fix unverified entry point Summary: Fix AOT code for the unverified entry point Reviewed-by: kvn ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/BinaryContainer.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/AOTCompiledClass.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MarkId.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MarkProcessor.java ! src/jdk.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64HotSpotBackend.java ! src/jdk.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64HotSpotMove.java ! src/jdk.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java ! src/share/vm/aot/aotCodeHeap.cpp ! src/share/vm/jvmci/jvmciCodeInstaller.cpp ! src/share/vm/jvmci/jvmciCodeInstaller.hpp ! src/share/vm/jvmci/vmStructs_jvmci.cpp Changeset: 4fa55e1b3668 Author: iveresov Date: 2017-01-10 18:48 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4fa55e1b3668 Merge Changeset: f954b0ae2862 Author: zmajo Date: 2017-01-11 09:40 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f954b0ae2862 8168926: C2: Bytecode escape analyzer crashes due to stack overflow Summary: Whether current call site needs an appendix is determined only based on the target method and the current bytecode instruction. Reviewed-by: kvn, thartmann ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/ciMethod.hpp Changeset: 8ae77838f86c Author: rehn Date: 2017-01-11 12:47 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/8ae77838f86c 8079441: Intermittent failures on Windows with "Unexpected exit from test [exit code: 1080890248]" (0x406d1388) Summary: Do not raise (windows thread name) exception 0x406d1388 when no debugger is attached. Reviewed-by: iklam, stuefe ! src/os/windows/vm/os_windows.cpp Changeset: ccbd743a62e3 Author: aph Date: 2017-01-11 15:09 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ccbd743a62e3 8172144: AArch64: Implement "JEP 270: Reserved Stack Areas for Critical Sections" Reviewed-by: fparain ! src/cpu/aarch64/vm/aarch64.ad ! src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp ! src/cpu/aarch64/vm/frame_aarch64.cpp ! src/cpu/aarch64/vm/frame_aarch64.hpp ! src/cpu/aarch64/vm/globalDefinitions_aarch64.hpp ! src/cpu/aarch64/vm/globals_aarch64.hpp ! src/cpu/aarch64/vm/interp_masm_aarch64.cpp ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/aarch64/vm/macroAssembler_aarch64.hpp ! src/cpu/aarch64/vm/stubGenerator_aarch64.cpp ! src/os_cpu/linux_aarch64/vm/os_linux_aarch64.cpp ! test/runtime/ReservedStack/ReservedStackTest.java Changeset: 5dc504e3e344 Author: iignatyev Date: 2017-01-11 17:43 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5dc504e3e344 8172557: quarantine ctw/JarDirTest Reviewed-by: ctornqvi ! test/ProblemList.txt Changeset: 5d25d00f0238 Author: dfazunen Date: 2017-01-12 09:53 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5d25d00f0238 8169643: [TESTBUG] GCBasher test fails with G1, CMS and Serial. Reviewed-by: tschatzl, iignatyev, mchernov ! test/gc/stress/gcbasher/TestGCBasherWithCMS.java ! test/gc/stress/gcbasher/TestGCBasherWithG1.java ! test/gc/stress/gcbasher/TestGCBasherWithSerial.java Changeset: cd012f7106a0 Author: dfazunen Date: 2017-01-12 10:31 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/cd012f7106a0 Merge Changeset: 2503995d745e Author: aph Date: 2017-01-12 16:27 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2503995d745e 8172721: Fix for 8172144 breaks AArch64 build Reviewed-by: dsamersoff ! src/os_cpu/linux_aarch64/vm/os_linux_aarch64.cpp Changeset: 9fb820614ff8 Author: rprotacio Date: 2017-01-12 14:04 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9fb820614ff8 8170821: Ensure access checks result in consistent answers Summary: Added jtreg test to verify consistent access check results even when access is added between checks Reviewed-by: hseigel, lfoltan + test/runtime/modules/AccessCheck/AccessExportTwice.java + test/runtime/modules/AccessCheck/AccessReadTwice.java + test/runtime/modules/AccessCheck/p4/c4.java Changeset: 7496eb00dee0 Author: rprotacio Date: 2017-01-12 19:34 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7496eb00dee0 Merge Changeset: ebcd23d638c4 Author: hseigel Date: 2017-01-13 07:19 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ebcd23d638c4 8172288: Fix Jigsaw related module/package error messages and throw correct exceptions Summary: Reword error messages and throw IllegalStateExceptions where appropriate Reviewed-by: alanb, acorn, lfoltan, gtriantafill ! src/share/vm/classfile/modules.cpp ! test/runtime/modules/JVMAddModulePackage.java ! test/runtime/modules/JVMDefineModule.java Changeset: 35800aa5909b Author: jwilhelm Date: 2017-01-13 18:26 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/35800aa5909b Merge - test/compiler/c2/cr7200264/Test7200264.sh Changeset: 1204af3ffd62 Author: jwilhelm Date: 2017-01-16 16:18 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1204af3ffd62 Merge Changeset: 74cd588213de Author: aharlap Date: 2017-01-13 12:27 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/74cd588213de 8140588: Internal Error: gc/g1/ptrQueue.hpp:126 assert(_index == _sz) failed: invariant: queues are empty when activated Summary: Re-check queue active state before updating Reviewed-by: pliden, kbarrett, mdoerr ! src/cpu/aarch64/vm/c1_Runtime1_aarch64.cpp ! src/cpu/arm/vm/c1_Runtime1_arm.cpp ! src/cpu/ppc/vm/c1_Runtime1_ppc.cpp ! src/cpu/s390/vm/c1_Runtime1_s390.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp Changeset: ad7a20139831 Author: thartmann Date: 2017-01-17 08:53 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ad7a20139831 8172731: runtime/Thread/TooSmallStackSize.java fails on solaris-x64 with product build Summary: The C2 compiler threads require a large stack with the Solaris Studio C++ compiler version 5.13 and product VM build. Reviewed-by: sspitsyn, dcubed, goetz, dholmes ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp Changeset: ff97ab44141e Author: rprotacio Date: 2017-01-13 16:49 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ff97ab44141e 8170827: Correct errant "java.base" string to macro Summary: used JAVA_BASE_NAME instead of "java.base" string in one location Reviewed-by: coleenp, jiangli ! src/share/vm/runtime/os.cpp Changeset: e2d6ab2f3165 Author: rprotacio Date: 2017-01-17 15:27 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e2d6ab2f3165 Merge Changeset: 254d5e3a021f Author: mgronlun Date: 2017-01-17 16:18 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/254d5e3a021f 8171960: Event-based tracing needs separate flag representation for Method Reviewed-by: hseigel, gtriantafill, dholmes ! src/jdk.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java ! src/share/vm/jvmci/vmStructs_jvmci.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/trace/traceMacros.hpp Changeset: 3cb570932811 Author: mgronlun Date: 2017-01-17 17:00 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3cb570932811 Merge Changeset: 0fc4f7547c84 Author: jcm Date: 2017-01-17 21:38 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0fc4f7547c84 8166002: Emulate client build on platforms with reduced virtual address space Summary: The default VM ergonomics on Windows/x86 (32-bit) are changed to client like. Reviewed-by: kvn, iveresov ! src/share/vm/compiler/compilerDefinitions.cpp ! src/share/vm/compiler/compilerDefinitions.hpp ! src/share/vm/compiler/compilerDirectives.cpp ! src/share/vm/gc/shared/collectedHeap.cpp ! src/share/vm/gc/shared/genCollectedHeap.cpp ! src/share/vm/gc/shared/referenceProcessor.cpp ! src/share/vm/gc/shared/threadLocalAllocBuffer.cpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/compilationPolicy.cpp ! src/share/vm/runtime/vm_version.cpp ! test/TEST.ROOT ! test/compiler/arraycopy/TestArrayCopyNoInitDeopt.java ! test/compiler/c2/cr7200264/TestSSE2IntVect.java ! test/compiler/c2/cr7200264/TestSSE4IntVect.java ! test/compiler/codecache/stress/OverloadCompileQueueTest.java ! test/compiler/cpuflags/TestAESIntrinsicsOnSupportedConfig.java ! test/compiler/intrinsics/IntrinsicAvailableTest.java ! test/compiler/intrinsics/IntrinsicDisabledTest.java ! test/compiler/intrinsics/bigInteger/MontgomeryMultiplyTest.java ! test/compiler/intrinsics/bmi/verifycode/AndnTestI.java ! test/compiler/intrinsics/bmi/verifycode/AndnTestL.java ! test/compiler/intrinsics/bmi/verifycode/BlsiTestI.java ! test/compiler/intrinsics/bmi/verifycode/BlsiTestL.java ! test/compiler/intrinsics/bmi/verifycode/BlsmskTestI.java ! test/compiler/intrinsics/bmi/verifycode/BlsmskTestL.java ! test/compiler/intrinsics/bmi/verifycode/BlsrTestI.java ! test/compiler/intrinsics/bmi/verifycode/BlsrTestL.java ! test/compiler/intrinsics/bmi/verifycode/BmiIntrinsicBase.java ! test/compiler/intrinsics/bmi/verifycode/LZcntTestI.java ! test/compiler/intrinsics/bmi/verifycode/LZcntTestL.java ! test/compiler/intrinsics/bmi/verifycode/TZcntTestI.java ! test/compiler/intrinsics/bmi/verifycode/TZcntTestL.java ! test/compiler/intrinsics/klass/CastNullCheckDroppingsTest.java ! test/compiler/intrinsics/mathexact/sanity/IntrinsicBase.java ! test/compiler/loopopts/TestCountedLoopSafepointBackedge.java ! test/compiler/loopopts/UseCountedLoopSafepointsTest.java ! test/compiler/rangechecks/TestExplicitRangeChecks.java ! test/compiler/testlibrary/CompilerUtils.java ! test/compiler/testlibrary/sha/predicate/IntrinsicPredicates.java ! test/compiler/tiered/NonTieredLevelsTest.java ! test/compiler/types/correctness/CorrectnessTest.java ! test/compiler/uncommontrap/TestUnstableIfTrap.java ! test/compiler/unsafe/UnsafeGetConstantField.java ! test/compiler/unsafe/UnsafeGetStableArrayElement.java ! test/compiler/whitebox/IsMethodCompilableTest.java ! test/gc/stress/gcbasher/TestGCBasherWithCMS.java ! test/gc/stress/gcbasher/TestGCBasherWithG1.java ! test/gc/stress/gcbasher/TestGCBasherWithParallel.java ! test/gc/stress/gcbasher/TestGCBasherWithSerial.java ! test/runtime/CDSCompressedKPtrs/XShareAuto.java ! test/runtime/ReservedStack/ReservedStackTestCompiler.java ! test/serviceability/dcmd/compiler/CompilerDirectivesDCMDTest.java ! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/Utils.java ! test/testlibrary_tests/TestMutuallyExclusivePlatformPredicates.java Changeset: 152d10166ff8 Author: thartmann Date: 2017-01-18 08:54 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/152d10166ff8 8172884: TraceOptoPipelining and TraceOptoOutput are broken Summary: Compiler Control code needs not set the default values for the directive according to the flag value. Reviewed-by: neliasso, redestad ! src/share/vm/compiler/compilerDirectives.hpp ! src/share/vm/opto/compile.cpp Changeset: 47db1274b75e Author: thartmann Date: 2017-01-18 08:30 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/47db1274b75e Merge Changeset: 6c1e79a99176 Author: coleenp Date: 2017-01-18 10:30 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6c1e79a99176 8144518: ClassVerboseTest crashes on Windows Summary: simplify Bytecode_tableswitch code so windows doesn't generate bad code for it. Reviewed-by: ctornqvi, dholmes ! src/share/vm/interpreter/bytecode.cpp ! src/share/vm/interpreter/bytecode.hpp Changeset: f9616b130c3c Author: kvn Date: 2017-01-18 14:36 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f9616b130c3c 8172990: [AOT] Missing GC scan of _metaspace_got array containing Klass* Summary: added back _metaspace_got array scan. Reviewed-by: dlong ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/CallSiteRelocationSymbol.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/JavaCallSiteRelocationSymbol.java ! src/share/vm/aot/aotCodeHeap.cpp ! src/share/vm/aot/aotCompiledMethod.cpp ! src/share/vm/aot/aotCompiledMethod.hpp ! src/share/vm/runtime/deoptimization.cpp Changeset: 5af250af8e33 Author: dholmes Date: 2017-01-18 19:54 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5af250af8e33 8172261: [JVMTI] Specification for early VM start event needs to lower expectations in relation class loading Reviewed-by: dcubed, sspitsyn, alanb ! src/share/vm/prims/jvmti.xml Changeset: 1a62b9d61766 Author: kvn Date: 2017-01-18 19:37 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1a62b9d61766 8173019: Backout JDK-8172990 changes Reviewed-by: dlong ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/CallSiteRelocationSymbol.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/JavaCallSiteRelocationSymbol.java ! src/share/vm/aot/aotCodeHeap.cpp ! src/share/vm/aot/aotCompiledMethod.cpp ! src/share/vm/aot/aotCompiledMethod.hpp ! src/share/vm/runtime/deoptimization.cpp Changeset: 26c20ac1e247 Author: thartmann Date: 2017-01-19 08:10 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/26c20ac1e247 8172751: OSR compilation at unreachable bci causes C1 crash Summary: Bailout if OSR entry is unreachable. Reviewed-by: thartmann Contributed-by: Andreas Woess ! src/share/vm/c1/c1_GraphBuilder.cpp + test/compiler/c1/Test8172751.java Changeset: 12ba9033442d Author: stuefe Date: 2017-01-19 10:30 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/12ba9033442d 8172964: [aix] AIX VM should not handle SIGDANGER Reviewed-by: simonis, clanger ! src/os/aix/vm/os_aix.cpp ! src/os_cpu/aix_ppc/vm/os_aix_ppc.cpp Changeset: 75a0852323f6 Author: rbackman Date: 2017-01-05 08:37 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/75a0852323f6 8169588: [AOT] jaotc --classpath option is confusing Reviewed-by: kvn, dlong + src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/LoadedClass.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/Main.java - src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/collect/ClassCollector.java + src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/collect/ClassSearch.java + src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/collect/ClassSource.java + src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/collect/FileSupport.java + src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/collect/FileSystemFinder.java + src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/collect/SearchFor.java + src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/collect/SearchPath.java + src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/collect/SourceProvider.java + src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/collect/classname/ClassNameSource.java + src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/collect/classname/ClassNameSourceProvider.java + src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/collect/directory/DirectorySource.java + src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/collect/directory/DirectorySourceProvider.java + src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/collect/jar/JarFileSource.java + src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/collect/jar/JarSourceProvider.java + src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/collect/module/ModuleSource.java + src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/collect/module/ModuleSourceProvider.java ! test/compiler/aot/AotCompiler.java - test/compiler/aot/cli/jaotc/ClasspathOptionTest.java ! test/compiler/aot/cli/jaotc/ClasspathOptionUnknownClassTest.java ! test/compiler/aot/cli/jaotc/CompileClassTest.java ! test/compiler/aot/cli/jaotc/CompileDirectoryTest.java ! test/compiler/aot/cli/jaotc/CompileJarTest.java ! test/compiler/aot/cli/jaotc/JaotcTestHelper.java ! test/compiler/aot/cli/jaotc/ListOptionNotExistingTest.java ! test/compiler/aot/cli/jaotc/ListOptionTest.java ! test/compiler/aot/cli/jaotc/ListOptionWrongFileTest.java + test/compiler/aot/jdk.tools.jaotc.test/src/jdk/tools/jaotc/test/collect/ClassSearchTest.java + test/compiler/aot/jdk.tools.jaotc.test/src/jdk/tools/jaotc/test/collect/ClassSourceTest.java + test/compiler/aot/jdk.tools.jaotc.test/src/jdk/tools/jaotc/test/collect/FakeFileSupport.java + test/compiler/aot/jdk.tools.jaotc.test/src/jdk/tools/jaotc/test/collect/FakeSearchPath.java + test/compiler/aot/jdk.tools.jaotc.test/src/jdk/tools/jaotc/test/collect/SearchPathTest.java + test/compiler/aot/jdk.tools.jaotc.test/src/jdk/tools/jaotc/test/collect/Utils.java + test/compiler/aot/jdk.tools.jaotc.test/src/jdk/tools/jaotc/test/collect/directory/DirectorySourceProviderTest.java + test/compiler/aot/jdk.tools.jaotc.test/src/jdk/tools/jaotc/test/collect/jar/JarSourceProviderTest.java + test/compiler/aot/jdk.tools.jaotc.test/src/jdk/tools/jaotc/test/collect/module/ModuleSourceProviderTest.java ! test/compiler/aot/verification/ClassAndLibraryNotMatchTest.java ! test/compiler/aot/verification/vmflags/BasicFlagsChange.java Changeset: dcd35a6b8883 Author: rbackman Date: 2017-01-19 11:10 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/dcd35a6b8883 Merge - src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/collect/ClassCollector.java - test/compiler/aot/cli/jaotc/ClasspathOptionTest.java Changeset: fdd79a4370d6 Author: redestad Date: 2017-01-19 11:49 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/fdd79a4370d6 8171855: Move package name transformations during module bootstrap into native code Reviewed-by: alanb, acorn, lfoltan, mchung, plevart, hseigel, sspitsyn ! make/symbols/symbols-unix ! src/share/vm/classfile/modules.cpp ! src/share/vm/classfile/modules.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/whitebox.cpp Changeset: d63a92d90bf3 Author: gtriantafill Date: 2017-01-19 10:56 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d63a92d90bf3 8152206: Simplify jvmstat modules Reviewed-by: alanb, mchung, hseigel ! test/compiler/c2/cr6589834/Test_ia32.java ! test/compiler/codecache/cli/TestSegmentedCodeCacheOption.java ! test/compiler/codecache/cli/codeheapsize/TestCodeHeapSizeOptions.java ! test/compiler/codecache/cli/printcodecache/TestPrintCodeCacheOption.java ! test/compiler/uncommontrap/TestUnstableIfTrap.java ! test/gc/metaspace/TestMetaspacePerfCounters.java ! test/gc/metaspace/TestPerfCountersAndMemoryPools.java ! test/gc/whitebox/TestConcMarkCycleWB.java ! test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java ! test/runtime/ErrorHandling/CreateCoredumpOnCrash.java ! test/runtime/ErrorHandling/ProblematicFrameTest.java ! test/runtime/SharedArchiveFile/BootAppendTests.java ! test/serviceability/attach/AttachSetGetFlag.java ! test/serviceability/dcmd/compiler/CodeCacheTest.java ! test/serviceability/dcmd/compiler/CodelistTest.java ! test/serviceability/dcmd/compiler/CompilerQueueTest.java ! test/serviceability/dcmd/framework/HelpTest.java ! test/serviceability/dcmd/framework/InvalidCommandTest.java ! test/serviceability/dcmd/framework/VMVersionTest.java ! test/serviceability/dcmd/gc/ClassHistogramAllTest.java ! test/serviceability/dcmd/gc/ClassHistogramTest.java ! test/serviceability/dcmd/gc/HeapDumpAllTest.java ! test/serviceability/dcmd/gc/HeapDumpTest.java ! test/serviceability/dcmd/gc/RunFinalizationTest.java ! test/serviceability/dcmd/gc/RunGCTest.java ! test/serviceability/dcmd/jvmti/LoadAgentDcmdTest.java ! test/serviceability/dcmd/thread/PrintConcurrentLocksTest.java ! test/serviceability/dcmd/thread/PrintTest.java ! test/serviceability/dcmd/vm/ClassHierarchyTest.java ! test/serviceability/dcmd/vm/ClassLoaderStatsTest.java ! test/serviceability/dcmd/vm/CommandLineTest.java ! test/serviceability/dcmd/vm/DynLibsTest.java ! test/serviceability/dcmd/vm/FlagsTest.java ! test/serviceability/dcmd/vm/SystemPropertiesTest.java ! test/serviceability/dcmd/vm/UptimeTest.java ! test/serviceability/jvmti/GetObjectSizeClass.java ! test/serviceability/jvmti/GetObjectSizeOverflow.java ! test/serviceability/jvmti/TestRedefineWithUnresolvedClass.java ! test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java ! test/testlibrary_tests/ctw/JarDirTest.java ! test/testlibrary_tests/ctw/JarsTest.java ! test/testlibrary_tests/whitebox/vm_flags/BooleanTest.java Changeset: fde92370dce4 Author: dholmes Date: 2017-01-19 18:52 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/fde92370dce4 8172972: Add gc/g1/logging/TestG1LoggingFailure.java to the ProblemList Reviewed-by: kbarrett ! test/ProblemList.txt Changeset: f38cfd21a95a Author: dcubed Date: 2017-01-19 18:16 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f38cfd21a95a 8173081: VM no longer prints "Picked up _JAVA_OPTONS: " message Summary: Restore lost line from JDK-8061999. Reviewed-by: hseigel, mchung, dholmes ! src/share/vm/runtime/arguments.cpp Changeset: 2754f53df69b Author: jcm Date: 2017-01-19 21:52 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2754f53df69b 8173038: [TESTBUG] compiler/loopopts/UseCountedLoopSafepointsTest.java fails with TESTBUG: Not server mode Summary: remove wrong extra check that got added as part of JDK-8166002 emulated client on win32. Reviewed-by: kvn ! test/compiler/loopopts/UseCountedLoopSafepointsTest.java Changeset: 76bc5f4eef8b Author: hseigel Date: 2017-01-20 16:09 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/76bc5f4eef8b 8171971: Fix timing bug in JVM management of package export lists Summary: Reduce the number of fields that maintain export state and use Module_lock to access these fields Reviewed-by: acorn, sspitsyn, lfoltan ! src/share/vm/classfile/modules.cpp ! src/share/vm/classfile/packageEntry.cpp ! src/share/vm/classfile/packageEntry.hpp ! src/share/vm/runtime/reflection.cpp Changeset: 283d05ba6692 Author: kvn Date: 2017-01-21 15:08 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/283d05ba6692 8173135: compiler/aot/fingerprint/SelfChangedCDS.java fails with: Unrecognized VM option 'UnlockCommercialFeatures' Summary: Move aot/fingerprint tests to closed since they use commercial feature. Reviewed-by: iveresov - test/compiler/aot/fingerprint/CDSDumper.java - test/compiler/aot/fingerprint/CDSRunner.java - test/compiler/aot/fingerprint/SelfChanged.java - test/compiler/aot/fingerprint/SelfChangedCDS.java - test/compiler/aot/fingerprint/SuperChanged.java Changeset: f5776d683ae5 Author: jcm Date: 2017-01-22 22:18 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f5776d683ae5 8173037: V [jvm.dll+0x2343fc] GraphBuilder::args_list_for_profiling+0x8c Summary: Disabled WB Compilaton at unsupported levels. Reviewed-by: kvn ! src/share/vm/compiler/compilerDefinitions.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/arguments.cpp Changeset: c576bd949a9d Author: zmajo Date: 2017-01-23 09:53 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c576bd949a9d 8172844: Assert fails in deoptimization due to original PC at the end of code section Summary: Change assert to accept end of code section as well. Reviewed-by: rbackman, kvn, dlong ! src/cpu/aarch64/vm/frame_aarch64.cpp ! src/cpu/aarch64/vm/frame_aarch64.inline.hpp ! src/cpu/arm/vm/frame_arm.cpp ! src/cpu/arm/vm/frame_arm.inline.hpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/share/vm/code/compiledMethod.hpp Changeset: 3c57e5f8dfca Author: iveresov Date: 2017-01-23 23:49 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3c57e5f8dfca 8173054: [AOT] Avoid zero-shift for compressed oops Summary: AOT compiler should be pessimistic about heap size Reviewed-by: kvn ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/BinaryContainer.java + src/jdk.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/AOTGraalHotSpotVMConfig.java ! src/jdk.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java ! src/jdk.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotGraalRuntime.java Changeset: 84b87a6130f9 Author: dnsimon Date: 2017-01-22 21:40 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/84b87a6130f9 8172733: [JVMCI] add ResolvedJavaMethod.hasNeverInlineDirective Reviewed-by: kvn ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/CompilerToVM.java ! 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.meta/src/jdk/vm/ci/meta/ResolvedJavaMethod.java ! src/share/vm/jvmci/jvmciCompilerToVM.cpp ! test/compiler/jvmci/common/patches/jdk.vm.ci/jdk/vm/ci/hotspot/CompilerToVMHelper.java - test/compiler/jvmci/compilerToVM/CanInlineMethodTest.java ! test/compiler/jvmci/compilerToVM/DoNotInlineOrCompileTest.java + test/compiler/jvmci/compilerToVM/HasNeverInlineDirectiveTest.java + test/compiler/jvmci/compilerToVM/IsCompilableTest.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaMethod.java Changeset: f7c895cf8b14 Author: dnsimon Date: 2017-01-23 23:01 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f7c895cf8b14 Merge Changeset: 9e0a7b1cbdef Author: never Date: 2017-01-24 08:51 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9e0a7b1cbdef 8171173: EXCEPTION_ACCESS_VIOLATION running VirtualObjectDebugInfoTest.java Reviewed-by: kvn ! test/compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/DebugInfoTest.java ! test/compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/TestAssembler.java ! test/compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/VirtualObjectDebugInfoTest.java Changeset: 84632483ee9d Author: kvn Date: 2017-01-24 17:19 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/84632483ee9d 8173158: [AOT] fix typo in jaotc --help output Reviewed-by: rbackman ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/Main.java ! test/compiler/aot/AotCompiler.java ! test/compiler/aot/cli/jaotc/ClasspathOptionUnknownClassTest.java ! test/compiler/aot/cli/jaotc/CompileClassTest.java ! test/compiler/aot/cli/jaotc/ListOptionNotExistingTest.java ! test/compiler/aot/cli/jaotc/ListOptionTest.java ! test/compiler/aot/cli/jaotc/ListOptionWrongFileTest.java Changeset: 784fe0364e70 Author: jcm Date: 2017-01-24 20:47 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/784fe0364e70 8173300: [TESTBUG]compiler/tiered/NonTieredLevelsTest.java fails with compiler.whitebox.SimpleTestCaseHelper(int) must be compiled Summary: Corrected available compilation levels for client builds. Reviewed-by: kvn ! test/compiler/tiered/NonTieredLevelsTest.java Changeset: 366758481af1 Author: thartmann Date: 2017-01-25 07:03 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/366758481af1 8173195: [BACKOUT] 8087341: C2 doesn't optimize redundant memory operations with G1 Summary: Backing out 8087341 due to 8172850. Will be re-implemented with 8173196. Reviewed-by: kvn ! src/cpu/aarch64/vm/aarch64.ad ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp Changeset: 6bf44f4e2a1e Author: thartmann Date: 2017-01-25 07:05 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6bf44f4e2a1e 8172850: Anti-dependency on membar causes crash in register allocator due to invalid instruction scheduling Summary: Regression test and additional asserts. The problem is fixed by 8087341. Reviewed-by: kvn ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/coalesce.cpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/matcher.cpp + test/compiler/gcbarriers/TestMembarDependencies.java Changeset: 2caaacd39df2 Author: roland Date: 2017-01-24 09:40 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2caaacd39df2 8173147: [ctw] fails during compilation of sun.security.krb5.internal.crypto.RsaMd5DesCksumType::calculateKeyedChecksum with " graph should be schedulable" Summary: Loads generated at uncommon trap from eliminated arraycopy have incorrect memory state Reviewed-by: thartmann ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/macro.hpp + test/compiler/arraycopy/TestArrayCopyUNCBadMem.java Changeset: 93c26db91a75 Author: never Date: 2017-01-25 19:18 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/93c26db91a75 8173309: jvmtiDeferredLocalVariableSet may update the wrong frame Reviewed-by: kvn ! src/share/vm/runtime/vframe_hp.cpp ! src/share/vm/runtime/vframe_hp.hpp Changeset: e52bb34724fb Author: jwilhelm Date: 2017-01-24 00:30 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e52bb34724fb Merge Changeset: 2e57e84e9978 Author: gdub Date: 2017-01-24 13:40 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2e57e84e9978 8167519: [AOT] Failed compilation: java.math.MutableBigInteger.divide3n2n Reviewed-by: never, davleopo ! src/jdk.vm.compiler/.mx.graal/suite.py ! src/jdk.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/Debug.java ! src/jdk.vm.compiler/share/classes/org.graalvm.compiler.java/src/org/graalvm/compiler/java/BytecodeParser.java ! src/jdk.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/SimplifyingGraphDecoder.java ! src/jdk.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/StructuredGraph.java ! src/jdk.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/util/GraphUtil.java ! src/jdk.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/CanonicalizerPhase.java Changeset: 82ad3019b78e Author: rbackman Date: 2017-01-26 08:35 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/82ad3019b78e Merge Changeset: bfa8e4b0d4e2 Author: njian Date: 2017-01-22 16:33 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/bfa8e4b0d4e2 8172881: AArch64: assertion failure: the int pressure is incorrect Summary: Change the dst register type of get_and_setI/L/N/P from any register to non-special register. Reviewed-by: aph Contributed-by: yang.zhang at linaro.org ! src/cpu/aarch64/vm/aarch64.ad Changeset: 217615fcbfdf Author: dnsimon Date: 2017-01-26 05:53 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/217615fcbfdf 8173278: [JVMCI] query_update_method_data might write outside _trap_hist array Reviewed-by: kvn ! src/share/vm/oops/methodData.hpp Changeset: bb5efb0bc34a Author: ccheung Date: 2017-01-26 10:17 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/bb5efb0bc34a 8173163: searching for a versioned entry in a multi-release jar in hotspot is inconsistent with java code Summary: use the highest versioned entry if the specified version is higher than the current jdk version Reviewed-by: iklam, sspitsyn, jiangli ! src/share/vm/classfile/classLoader.cpp Changeset: 43139c588ea4 Author: jwilhelm Date: 2017-02-04 03:29 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/43139c588ea4 Merge ! src/cpu/aarch64/vm/globals_aarch64.hpp - src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/collect/ClassCollector.java ! src/os_cpu/linux_aarch64/vm/os_linux_aarch64.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/services/diagnosticCommand.cpp - test/compiler/aot/cli/jaotc/ClasspathOptionTest.java - test/compiler/aot/fingerprint/CDSDumper.java - test/compiler/aot/fingerprint/CDSRunner.java - test/compiler/aot/fingerprint/SelfChanged.java - test/compiler/aot/fingerprint/SelfChangedCDS.java - test/compiler/aot/fingerprint/SuperChanged.java - test/compiler/c2/cr7200264/Test7200264.sh - test/compiler/jvmci/compilerToVM/CanInlineMethodTest.java Changeset: c22bf83dad09 Author: lana Date: 2017-02-09 17:21 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c22bf83dad09 Added tag jdk-9+156 for changeset 43139c588ea4 ! .hgtags Changeset: 2752d489b98e Author: alanb Date: 2017-02-09 20:53 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2752d489b98e Merge ! .hgtags ! make/symbols/symbols-unix - src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/collect/ClassCollector.java ! src/os/aix/vm/os_aix.cpp ! src/os/windows/vm/os_windows.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/javaClasses.hpp ! src/share/vm/classfile/javaClasses.inline.hpp ! src/share/vm/classfile/modules.cpp ! src/share/vm/classfile/modules.hpp ! src/share/vm/classfile/packageEntry.cpp ! src/share/vm/classfile/packageEntry.hpp ! src/share/vm/classfile/systemDictionaryShared.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/memory/metaspaceShared.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/precompiled/precompiled.hpp ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/jvmti.xml ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/management.cpp ! src/share/vm/trace/traceMacros.hpp ! test/ProblemList.txt ! test/TEST.ROOT - test/compiler/aot/cli/jaotc/ClasspathOptionTest.java - test/compiler/aot/fingerprint/CDSDumper.java - test/compiler/aot/fingerprint/CDSRunner.java - test/compiler/aot/fingerprint/SelfChanged.java - test/compiler/aot/fingerprint/SelfChangedCDS.java - test/compiler/aot/fingerprint/SuperChanged.java - test/compiler/c2/cr7200264/Test7200264.sh ! test/compiler/intrinsics/bigInteger/MontgomeryMultiplyTest.java ! test/compiler/intrinsics/klass/CastNullCheckDroppingsTest.java ! test/compiler/jvmci/common/patches/jdk.vm.ci/jdk/vm/ci/hotspot/CompilerToVMHelper.java - test/compiler/jvmci/compilerToVM/CanInlineMethodTest.java ! test/compiler/jvmci/compilerToVM/DoNotInlineOrCompileTest.java + test/compiler/jvmci/compilerToVM/HasNeverInlineDirectiveTest.java ! test/compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/VirtualObjectDebugInfoTest.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaMethod.java ! test/compiler/rangechecks/TestExplicitRangeChecks.java ! test/compiler/uncommontrap/TestUnstableIfTrap.java ! test/compiler/unsafe/UnsafeGetConstantField.java ! test/gc/g1/TestHumongousShrinkHeap.java ! test/gc/g1/TestShrinkDefragmentedHeap.java ! test/gc/metaspace/TestMetaspacePerfCounters.java ! test/gc/metaspace/TestPerfCountersAndMemoryPools.java ! test/gc/parallel/TestDynShrinkHeap.java ! test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java ! test/runtime/ErrorHandling/CreateCoredumpOnCrash.java ! test/runtime/ErrorHandling/ProblematicFrameTest.java ! test/runtime/ReservedStack/ReservedStackTest.java ! test/runtime/SharedArchiveFile/BootAppendTests.java + test/runtime/modules/AccessCheck/AccessExportTwice.java + test/runtime/modules/AccessCheck/AccessReadTwice.java ! test/runtime/modules/JVMAddModulePackage.java ! test/runtime/modules/JVMDefineModule.java ! test/serviceability/attach/AttachSetGetFlag.java ! test/serviceability/dcmd/compiler/CodeCacheTest.java ! test/serviceability/dcmd/compiler/CodelistTest.java ! test/serviceability/dcmd/compiler/CompilerQueueTest.java ! test/serviceability/dcmd/gc/HeapDumpAllTest.java ! test/serviceability/dcmd/gc/HeapDumpTest.java ! test/serviceability/jvmti/TestRedefineWithUnresolvedClass.java ! test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.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 ! test/testlibrary_tests/whitebox/vm_flags/BooleanTest.java From alan.bateman at oracle.com Thu Feb 9 20:53:56 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 09 Feb 2017 20:53:56 +0000 Subject: hg: jigsaw/jake/jdk: 54 new changesets Message-ID: <201702092053.v19KrwtK003682@aojmv0008.oracle.com> Changeset: 7bd7a7ffa84b Author: mchung Date: 2017-01-31 20:06 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7bd7a7ffa84b 8173608: Separate JDK management agent from java.management module Reviewed-by: dfuchs, dholmes, erikj - make/copy/Copy-java.management.gmk + make/copy/Copy-jdk.management.agent.gmk - make/gensrc/Gensrc-java.management.gmk + make/gensrc/Gensrc-jdk.management.agent.gmk ! make/lib/Lib-java.management.gmk + make/lib/Lib-jdk.management.agent.gmk ! make/mapfiles/libmanagement/mapfile-vers + make/mapfiles/libmanagement_rmi/mapfile-vers ! src/java.base/share/classes/module-info.java ! src/java.management/share/classes/com/sun/jmx/remote/security/FileLoginModule.java ! src/java.management/share/classes/module-info.java - src/java.management/share/classes/sun/management/Agent.java - src/java.management/share/classes/sun/management/AgentConfigurationError.java - src/java.management/share/classes/sun/management/ConnectorAddressLink.java - src/java.management/share/classes/sun/management/FileSystem.java - src/java.management/share/classes/sun/management/jdp/JdpBroadcaster.java - src/java.management/share/classes/sun/management/jdp/JdpController.java - src/java.management/share/classes/sun/management/jdp/JdpException.java - src/java.management/share/classes/sun/management/jdp/JdpGenericPacket.java - src/java.management/share/classes/sun/management/jdp/JdpJmxPacket.java - src/java.management/share/classes/sun/management/jdp/JdpPacket.java - src/java.management/share/classes/sun/management/jdp/JdpPacketReader.java - src/java.management/share/classes/sun/management/jdp/JdpPacketWriter.java - src/java.management/share/classes/sun/management/jdp/package-info.java - src/java.management/share/classes/sun/management/jmxremote/ConnectorBootstrap.java - src/java.management/share/classes/sun/management/jmxremote/LocalRMIServerSocketFactory.java - src/java.management/share/classes/sun/management/jmxremote/SingleEntryRegistry.java - src/java.management/share/classes/sun/management/jmxremote/package.html - src/java.management/share/classes/sun/management/resources/agent.properties - src/java.management/share/classes/sun/management/resources/agent_de.properties - src/java.management/share/classes/sun/management/resources/agent_es.properties - src/java.management/share/classes/sun/management/resources/agent_fr.properties - src/java.management/share/classes/sun/management/resources/agent_it.properties - src/java.management/share/classes/sun/management/resources/agent_ja.properties - src/java.management/share/classes/sun/management/resources/agent_ko.properties - src/java.management/share/classes/sun/management/resources/agent_pt_BR.properties - src/java.management/share/classes/sun/management/resources/agent_sv.properties - src/java.management/share/classes/sun/management/resources/agent_zh_CN.properties - src/java.management/share/classes/sun/management/resources/agent_zh_TW.properties - src/java.management/share/classes/sun/management/spi/AgentProvider.java - src/java.management/share/conf/jmxremote.access - src/java.management/share/conf/jmxremote.password.template - src/java.management/share/conf/management.properties - src/java.management/share/conf/snmp.acl.template - src/java.management/unix/classes/sun/management/FileSystemImpl.java - src/java.management/unix/native/libmanagement/FileSystemImpl.c - src/java.management/windows/classes/sun/management/FileSystemImpl.java - src/java.management/windows/native/libmanagement/FileSystemImpl.c ! src/java.rmi/share/classes/module-info.java ! src/jdk.jconsole/share/classes/module-info.java ! src/jdk.jconsole/share/classes/sun/tools/jconsole/LocalVirtualMachine.java + src/jdk.management.agent/share/classes/jdk/internal/agent/Agent.java + src/jdk.management.agent/share/classes/jdk/internal/agent/AgentConfigurationError.java + src/jdk.management.agent/share/classes/jdk/internal/agent/ConnectorAddressLink.java + src/jdk.management.agent/share/classes/jdk/internal/agent/FileSystem.java + src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent.properties + src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_de.properties + src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_es.properties + src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_fr.properties + src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_it.properties + src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_ja.properties + src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_ko.properties + src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_pt_BR.properties + src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_sv.properties + src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_zh_CN.properties + src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_zh_TW.properties + src/jdk.management.agent/share/classes/jdk/internal/agent/spi/AgentProvider.java + src/jdk.management.agent/share/classes/module-info.java + src/jdk.management.agent/share/classes/sun/management/jdp/JdpBroadcaster.java + src/jdk.management.agent/share/classes/sun/management/jdp/JdpController.java + src/jdk.management.agent/share/classes/sun/management/jdp/JdpException.java + src/jdk.management.agent/share/classes/sun/management/jdp/JdpGenericPacket.java + src/jdk.management.agent/share/classes/sun/management/jdp/JdpJmxPacket.java + src/jdk.management.agent/share/classes/sun/management/jdp/JdpPacket.java + src/jdk.management.agent/share/classes/sun/management/jdp/JdpPacketReader.java + src/jdk.management.agent/share/classes/sun/management/jdp/JdpPacketWriter.java + src/jdk.management.agent/share/classes/sun/management/jdp/package-info.java + src/jdk.management.agent/share/classes/sun/management/jmxremote/ConnectorBootstrap.java + src/jdk.management.agent/share/classes/sun/management/jmxremote/LocalRMIServerSocketFactory.java + src/jdk.management.agent/share/classes/sun/management/jmxremote/SingleEntryRegistry.java + src/jdk.management.agent/share/classes/sun/management/jmxremote/package.html + src/jdk.management.agent/share/conf/jmxremote.access + src/jdk.management.agent/share/conf/jmxremote.password.template + src/jdk.management.agent/share/conf/management.properties + src/jdk.management.agent/unix/classes/jdk/internal/agent/FileSystemImpl.java + src/jdk.management.agent/unix/native/libmanagement_rmi/FileSystemImpl.c + src/jdk.management.agent/windows/classes/jdk/internal/agent/FileSystemImpl.java + src/jdk.management.agent/windows/native/libmanagement_rmi/FileSystemImpl.c ! test/com/sun/tools/attach/StartManagementAgent.java + test/jdk/internal/agent/AgentCMETest.java + test/jdk/internal/agent/AgentCheckTest.java - test/sun/management/AgentCMETest.java - test/sun/management/AgentCheckTest.java ! test/sun/management/jdp/JdpDefaultsTest.java ! test/sun/management/jdp/JdpOffTest.java ! test/sun/management/jdp/JdpSpecificAddressTest.java ! test/sun/management/jmxremote/LocalRMIServerSocketFactoryTest.java ! test/sun/management/jmxremote/bootstrap/CustomLauncherTest.java ! test/sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java ! test/sun/management/jmxremote/bootstrap/JvmstatCountersTest.java ! test/sun/management/jmxremote/bootstrap/LocalManagementTest.java ! test/sun/management/jmxremote/bootstrap/PasswordFilePermissionTest.java ! test/sun/management/jmxremote/bootstrap/RmiBootstrapTest.java ! test/sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh ! test/sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java ! test/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh ! test/sun/management/jmxremote/bootstrap/RmiSslNoKeyStoreTest.java ! test/sun/management/jmxremote/bootstrap/RmiSslNoKeyStoreTest.sh ! test/sun/management/jmxremote/bootstrap/SSLConfigFilePermissionTest.java ! test/sun/management/jmxremote/bootstrap/TestManager.java ! test/sun/management/jmxremote/startstop/JMXStartStopTest.java ! test/sun/management/jmxremote/startstop/JMXStatusPerfCountersTest.java ! test/sun/management/jmxremote/startstop/JMXStatusTest.java ! test/sun/management/jmxremote/startstop/ManagementAgentJcmd.java Changeset: 8613f82fab04 Author: sundar Date: 2017-02-01 15:12 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8613f82fab04 8173717: jlink --help fails with missing "plugin.opt.plugin-module-path" key in resource bundle Reviewed-by: mchung, alanb ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties ! test/tools/jlink/JLinkTest.java Changeset: c5a48effbe68 Author: rpatil Date: 2017-02-01 18:18 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c5a48effbe68 8167063: spurious message "A JNI error has occurred" if start-class cannot be initialized Reviewed-by: alanb, ksrini ! src/java.base/share/classes/sun/launcher/LauncherHelper.java ! src/java.base/share/classes/sun/launcher/resources/launcher.properties + test/tools/launcher/LauncherMessageTest.java Changeset: 9c0802c92d6b Author: skovalev Date: 2017-02-01 16:31 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9c0802c92d6b 8173475: java/net/HttpURLConnection/SetAuthenticator tests have undeclared dependency on java.logging module Reviewed-by: dfuchs ! test/java/net/HttpURLConnection/SetAuthenticator/HTTPSetAuthenticatorTest.java ! test/java/net/HttpURLConnection/SetAuthenticator/HTTPTest.java Changeset: 397d1eb78030 Author: henryjen Date: 2017-02-01 09:52 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/397d1eb78030 8173758: tools/javac/Paths/wcMineField.sh failing with java.lang.ClassNotFoundException Reviewed-by: ksrini ! src/java.base/share/native/libjli/java.c Changeset: 0e2935453091 Author: henryjen Date: 2017-02-01 11:05 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0e2935453091 8171524: jar --help doesn't provide information that stdout and stdin can be used as output and input for tool Reviewed-by: sherman ! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties Changeset: a88d76c088c7 Author: anazarov Date: 2017-02-01 23:33 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a88d76c088c7 8075616: Create tests to check schemagen work with multi-version jar 8075617: Create tests to check wsgen work with multi-version jar Reviewed-by: alanb, lancea + test/tools/schemagen/MultiReleaseJarTest.java + test/tools/schemagen/data/mr/base/schemagen/Person.java + test/tools/schemagen/data/mr/v10/schemagen/Person.java + test/tools/schemagen/data/mr/v9/schemagen/Person.java + test/tools/wsgen/MultiReleaseJarTest.java + test/tools/wsgen/data/mr/base/wsgen/TestServer.java + test/tools/wsgen/data/mr/v10/wsgen/TestServer.java + test/tools/wsgen/data/mr/v9/wsgen/TestServer.java Changeset: 949799faf431 Author: clanger Date: 2017-02-02 10:28 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/949799faf431 8170868: DefaultProxySelector should use system defaults on Windows, MacOS and Gnome Reviewed-by: chegar, simonis, clanger, stuefe, erikj Contributed-by: arno.zeller at sap.com ! make/lib/NetworkingLibraries.gmk ! make/mapfiles/libnet/mapfile-vers + src/java.base/macosx/native/libnet/DefaultProxySelector.c ! src/java.base/share/classes/java/net/doc-files/net-properties.html ! src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java + src/java.base/share/native/libnet/proxy_util.c + src/java.base/share/native/libnet/proxy_util.h ! src/java.base/unix/native/libnet/DefaultProxySelector.c ! src/java.base/windows/native/libnet/DefaultProxySelector.c ! test/java/net/ProxySelector/SystemProxies.java Changeset: 63f7055a2240 Author: redestad Date: 2017-02-02 12:28 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/63f7055a2240 8160302: Reduce number of lambdas created when loading java.util.regex.Pattern Reviewed-by: sherman, martin ! src/java.base/share/classes/java/util/regex/CharPredicates.java ! src/java.base/share/classes/java/util/regex/Pattern.java ! src/java.base/share/classes/java/util/regex/PrintPattern.java Changeset: db6e995edd0a Author: dfuchs Date: 2017-02-02 16:50 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/db6e995edd0a 8173607: JMX RMI connector should be in its own module Summary: The JMX RMI connector is moved to a new java.management.rmi module. Reviewed-by: mchung, erikj - make/rmic/Rmic-java.management.gmk + make/rmic/Rmic-java.management.rmi.gmk ! src/java.base/share/classes/module-info.java + src/java.management.rmi/share/classes/com/sun/jmx/remote/internal/rmi/ProxyRef.java + src/java.management.rmi/share/classes/com/sun/jmx/remote/internal/rmi/RMIExporter.java + src/java.management.rmi/share/classes/com/sun/jmx/remote/internal/rmi/Unmarshal.java + src/java.management.rmi/share/classes/com/sun/jmx/remote/protocol/rmi/ClientProvider.java + src/java.management.rmi/share/classes/com/sun/jmx/remote/protocol/rmi/ServerProvider.java + src/java.management.rmi/share/classes/javax/management/remote/rmi/NoCallStackClassLoader.java + src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java + src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java + src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnector.java + src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectorServer.java + src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIIIOPServerImpl.java + src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIJRMPServerImpl.java + src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIServer.java + src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIServerImpl.java + src/java.management.rmi/share/classes/javax/management/remote/rmi/package.html + src/java.management.rmi/share/classes/module-info.java ! src/java.management/share/classes/com/sun/jmx/remote/internal/ClientNotifForwarder.java - src/java.management/share/classes/com/sun/jmx/remote/internal/ProxyRef.java - src/java.management/share/classes/com/sun/jmx/remote/internal/RMIExporter.java - src/java.management/share/classes/com/sun/jmx/remote/internal/Unmarshal.java - src/java.management/share/classes/com/sun/jmx/remote/protocol/rmi/ClientProvider.java - src/java.management/share/classes/com/sun/jmx/remote/protocol/rmi/ServerProvider.java ! src/java.management/share/classes/javax/management/remote/JMXConnectorFactory.java ! src/java.management/share/classes/javax/management/remote/JMXConnectorServerFactory.java - src/java.management/share/classes/javax/management/remote/rmi/NoCallStackClassLoader.java - src/java.management/share/classes/javax/management/remote/rmi/RMIConnection.java - src/java.management/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java - src/java.management/share/classes/javax/management/remote/rmi/RMIConnector.java - src/java.management/share/classes/javax/management/remote/rmi/RMIConnectorServer.java - src/java.management/share/classes/javax/management/remote/rmi/RMIIIOPServerImpl.java - src/java.management/share/classes/javax/management/remote/rmi/RMIJRMPServerImpl.java - src/java.management/share/classes/javax/management/remote/rmi/RMIServer.java - src/java.management/share/classes/javax/management/remote/rmi/RMIServerImpl.java - src/java.management/share/classes/javax/management/remote/rmi/package.html ! src/java.management/share/classes/module-info.java ! src/java.rmi/share/classes/module-info.java ! src/java.se/share/classes/module-info.java ! src/jdk.jconsole/share/classes/module-info.java ! src/jdk.management.agent/share/classes/module-info.java ! src/jdk.management.agent/share/classes/sun/management/jmxremote/ConnectorBootstrap.java ! test/javax/management/MBeanInfo/NotificationInfoTest.java ! test/javax/management/MBeanServer/ExceptionTest.java ! test/javax/management/MBeanServer/OldMBeanServerTest.java ! test/javax/management/modelmbean/UnserializableTargetObjectTest.java ! test/javax/management/mxbean/GenericArrayTypeTest.java ! test/javax/management/mxbean/MXBeanExceptionHandlingTest.java ! test/javax/management/mxbean/MXBeanInteropTest1.java ! test/javax/management/mxbean/MXBeanInteropTest2.java ! test/javax/management/mxbean/MXBeanNotifTest.java ! test/javax/management/mxbean/MXBeanTest.java ! test/javax/management/mxbean/MXBeanWeirdParamTest.java ! test/javax/management/query/SupportedQueryTypesTest.java ! test/javax/management/remote/mandatory/connection/AddressableTest.java ! test/javax/management/remote/mandatory/connection/BrokenConnectionTest.java ! test/javax/management/remote/mandatory/connection/CloseableTest.java ! test/javax/management/remote/mandatory/connection/ConnectionListenerNullTest.java ! test/javax/management/remote/mandatory/connection/ConnectionTest.java ! test/javax/management/remote/mandatory/connection/DaemonRMIExporterTest.java ! test/javax/management/remote/mandatory/connection/GetConnectionTest.java ! test/javax/management/remote/mandatory/connection/IIOPURLTest.java ! test/javax/management/remote/mandatory/connection/IdleTimeoutTest.java ! test/javax/management/remote/mandatory/connection/MultiThreadDeadLockTest.java ! test/javax/management/remote/mandatory/connection/ObjectInputStreamWithLoaderNullCheckTest.java ! test/javax/management/remote/mandatory/connection/RMIConnectorInternalMapTest.java ! test/javax/management/remote/mandatory/connection/RMIConnectorNullSubjectConnTest.java ! test/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java ! test/javax/management/remote/mandatory/connection/RMIExitTest.java ! test/javax/management/remote/mandatory/connection/RMISerializeTest.java ! test/javax/management/remote/mandatory/connectorServer/ConnectorStopDeadlockTest.java ! test/javax/management/remote/mandatory/connectorServer/JNDIFailureTest.java ! test/javax/management/remote/mandatory/connectorServer/MBSFPreStartPostStartTest.java ! test/javax/management/remote/mandatory/connectorServer/RMIExporterTest.java ! test/javax/management/remote/mandatory/connectorServer/SetMBeanServerForwarder.java ! test/javax/management/remote/mandatory/loading/DeserializeEncodedURLTest.java ! test/javax/management/remote/mandatory/loading/MissingClassTest.java ! test/javax/management/remote/mandatory/loading/RMIDownloadTest.java ! test/javax/management/remote/mandatory/loading/TargetMBeanTest.java ! test/javax/management/remote/mandatory/notif/ConcurrentModificationTest.java ! test/javax/management/remote/mandatory/notif/DeadListenerTest.java ! test/javax/management/remote/mandatory/notif/EmptyDomainNotificationTest.java ! test/javax/management/remote/mandatory/notif/ListenerScaleTest.java ! test/javax/management/remote/mandatory/notif/NotSerializableNotifTest.java ! test/javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java ! test/javax/management/remote/mandatory/notif/NotificationAccessControllerTest.java ! test/javax/management/remote/mandatory/notif/NotificationBufferCreationTest.java ! test/javax/management/remote/mandatory/notif/NotificationEmissionTest.java ! test/javax/management/remote/mandatory/notif/RMINotifTest.java ! test/javax/management/remote/mandatory/notif/ServerNotifs.java ! test/javax/management/remote/mandatory/notif/UnexpectedNotifTest.java ! test/javax/management/remote/mandatory/passwordAccessFile/NonJMXPrincipalsTest.java ! test/javax/management/remote/mandatory/passwordAccessFile/PasswordAccessFileTest.java ! test/javax/management/remote/mandatory/passwordAuthenticator/RMIAltAuthTest.java ! test/javax/management/remote/mandatory/passwordAuthenticator/RMIPasswdAuthTest.java ! test/javax/management/remote/mandatory/provider/ProviderTest.java ! test/javax/management/remote/mandatory/serverError/JMXServerErrorTest.java ! test/javax/management/remote/mandatory/socketFactories/RMISocketFactoriesTest.java ! test/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java ! test/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation2Test.java ! test/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation3Test.java ! test/javax/management/remote/mandatory/util/MapNullValuesTest.java ! test/javax/management/security/AuthorizationTest.java ! test/javax/management/security/SecurityTest.java ! test/sun/management/jmxremote/bootstrap/TestManager.java ! test/tools/launcher/modules/listmods/ListModsTest.java Changeset: 0fab063574be Author: dfuchs Date: 2017-02-02 19:09 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0fab063574be 8173821: com.sun.jmx.remote.internal.Unmarshal should be removed. Summary: com.sun.jmx.remote.internal.Unmarshal remove as it was no longer actively used since JDK 5. Reviewed-by: alanb - src/java.management.rmi/share/classes/com/sun/jmx/remote/internal/rmi/Unmarshal.java Changeset: 2306d5e4191f Author: skovalev Date: 2017-02-02 15:53 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2306d5e4191f 8173763: Two security tests fail with message: "java.security.NoSuchAlgorithmException: EC KeyFactory not available" Reviewed-by: mullan ! test/sun/net/www/protocol/https/HttpsClient/ProxyAuthTest.java ! test/sun/security/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java Changeset: 74d62786d29f Author: mullan Date: 2017-02-02 15:54 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/74d62786d29f Merge - src/java.management.rmi/share/classes/com/sun/jmx/remote/internal/rmi/Unmarshal.java Changeset: a652ba198354 Author: lana Date: 2017-02-02 21:55 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a652ba198354 Merge - make/copy/Copy-java.management.gmk - make/gensrc/Gensrc-java.management.gmk - make/rmic/Rmic-java.management.gmk - src/java.management/share/classes/com/sun/jmx/remote/internal/ProxyRef.java - src/java.management/share/classes/com/sun/jmx/remote/internal/RMIExporter.java - src/java.management/share/classes/com/sun/jmx/remote/internal/Unmarshal.java - src/java.management/share/classes/com/sun/jmx/remote/protocol/rmi/ClientProvider.java - src/java.management/share/classes/com/sun/jmx/remote/protocol/rmi/ServerProvider.java - src/java.management/share/classes/javax/management/remote/rmi/NoCallStackClassLoader.java - src/java.management/share/classes/javax/management/remote/rmi/RMIConnection.java - src/java.management/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java - src/java.management/share/classes/javax/management/remote/rmi/RMIConnector.java - src/java.management/share/classes/javax/management/remote/rmi/RMIConnectorServer.java - src/java.management/share/classes/javax/management/remote/rmi/RMIIIOPServerImpl.java - src/java.management/share/classes/javax/management/remote/rmi/RMIJRMPServerImpl.java - src/java.management/share/classes/javax/management/remote/rmi/RMIServer.java - src/java.management/share/classes/javax/management/remote/rmi/RMIServerImpl.java - src/java.management/share/classes/javax/management/remote/rmi/package.html - src/java.management/share/classes/sun/management/Agent.java - src/java.management/share/classes/sun/management/AgentConfigurationError.java - src/java.management/share/classes/sun/management/ConnectorAddressLink.java - src/java.management/share/classes/sun/management/FileSystem.java - src/java.management/share/classes/sun/management/jdp/JdpBroadcaster.java - src/java.management/share/classes/sun/management/jdp/JdpController.java - src/java.management/share/classes/sun/management/jdp/JdpException.java - src/java.management/share/classes/sun/management/jdp/JdpGenericPacket.java - src/java.management/share/classes/sun/management/jdp/JdpJmxPacket.java - src/java.management/share/classes/sun/management/jdp/JdpPacket.java - src/java.management/share/classes/sun/management/jdp/JdpPacketReader.java - src/java.management/share/classes/sun/management/jdp/JdpPacketWriter.java - src/java.management/share/classes/sun/management/jdp/package-info.java - src/java.management/share/classes/sun/management/jmxremote/ConnectorBootstrap.java - src/java.management/share/classes/sun/management/jmxremote/LocalRMIServerSocketFactory.java - src/java.management/share/classes/sun/management/jmxremote/SingleEntryRegistry.java - src/java.management/share/classes/sun/management/jmxremote/package.html - src/java.management/share/classes/sun/management/resources/agent.properties - src/java.management/share/classes/sun/management/resources/agent_de.properties - src/java.management/share/classes/sun/management/resources/agent_es.properties - src/java.management/share/classes/sun/management/resources/agent_fr.properties - src/java.management/share/classes/sun/management/resources/agent_it.properties - src/java.management/share/classes/sun/management/resources/agent_ja.properties - src/java.management/share/classes/sun/management/resources/agent_ko.properties - src/java.management/share/classes/sun/management/resources/agent_pt_BR.properties - src/java.management/share/classes/sun/management/resources/agent_sv.properties - src/java.management/share/classes/sun/management/resources/agent_zh_CN.properties - src/java.management/share/classes/sun/management/resources/agent_zh_TW.properties - src/java.management/share/classes/sun/management/spi/AgentProvider.java - src/java.management/share/conf/jmxremote.access - src/java.management/share/conf/jmxremote.password.template - src/java.management/share/conf/management.properties - src/java.management/share/conf/snmp.acl.template - src/java.management/unix/classes/sun/management/FileSystemImpl.java - src/java.management/unix/native/libmanagement/FileSystemImpl.c - src/java.management/windows/classes/sun/management/FileSystemImpl.java - src/java.management/windows/native/libmanagement/FileSystemImpl.c - test/sun/management/AgentCMETest.java - test/sun/management/AgentCheckTest.java Changeset: 0f297e75d32d Author: dfuchs Date: 2017-02-03 11:29 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0f297e75d32d 8173315: java/net/HttpURLConnection/SetAuthenticator/HTTPSetAuthenticatorTest.java fails intermittently Summary: Ensure that each test case creates a new server with a new local port number to preserve test isolation. Reviewed-by: michaelm ! test/java/net/HttpURLConnection/SetAuthenticator/HTTPTestServer.java Changeset: a329ff201a7d Author: ihse Date: 2017-02-03 13:04 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a329ff201a7d 8172548: unpack200 fails linking with new update of SS12u4 Reviewed-by: erikj Contributed-by: Stefan Anzinger ! make/mapfiles/libunpack/mapfile-vers-unpack200-solaris-sparc Changeset: 1700e2d1d46f Author: ihse Date: 2017-02-03 15:20 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1700e2d1d46f 8004842: Unify values of boolean make variables set in configure to true/false Reviewed-by: erikj ! make/lib/Lib-java.security.jgss.gmk ! make/lib/Lib-jdk.crypto.ec.gmk Changeset: 625b698c3cbe Author: mchung Date: 2017-02-03 08:54 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/625b698c3cbe 8173858: Rename libmanagement_rmi to libmanagement_agent Reviewed-by: alanb, dfuchs, dholmes, erikj ! make/lib/Lib-jdk.management.agent.gmk + make/mapfiles/libmanagement_agent/mapfile-vers - make/mapfiles/libmanagement_rmi/mapfile-vers ! src/java.base/share/classes/module-info.java ! src/jdk.management.agent/unix/classes/jdk/internal/agent/FileSystemImpl.java + src/jdk.management.agent/unix/native/libmanagement_agent/FileSystemImpl.c - src/jdk.management.agent/unix/native/libmanagement_rmi/FileSystemImpl.c ! src/jdk.management.agent/windows/classes/jdk/internal/agent/FileSystemImpl.java + src/jdk.management.agent/windows/native/libmanagement_agent/FileSystemImpl.c - src/jdk.management.agent/windows/native/libmanagement_rmi/FileSystemImpl.c Changeset: 0804989e2399 Author: henryjen Date: 2017-02-03 09:48 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0804989e2399 8171522: Jar prints error message with old (non gnu-style options). Reviewed-by: sherman ! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties Changeset: b873867cc8b8 Author: dmarkov Date: 2017-01-24 18:44 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b873867cc8b8 8163889: [macosx] Can't print from browser on Mac OS X Reviewed-by: prr, psadhukhan ! src/java.desktop/macosx/classes/sun/java2d/OSXOffScreenSurfaceData.java ! src/java.desktop/macosx/native/libawt_lwawt/awt/ImageSurfaceData.m + test/java/awt/print/PrinterJob/PrintCrashTest.java Changeset: 2ec14b8cdc25 Author: prr Date: 2017-01-26 09:19 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2ec14b8cdc25 Merge - make/copy/Copy-jdk.crypto.token.gmk - make/lib/Lib-jdk.crypto.token.gmk - src/jdk.crypto.token/share/classes/module-info.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/Config.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/KeyCache.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/P11Cipher.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/P11DHKeyFactory.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/P11DSAKeyFactory.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/P11Digest.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/P11ECDHKeyAgreement.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/P11ECKeyFactory.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/P11Key.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/P11KeyAgreement.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/P11KeyFactory.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/P11KeyGenerator.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/P11KeyPairGenerator.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/P11KeyStore.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/P11Mac.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/P11RSACipher.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/P11RSAKeyFactory.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/P11SecureRandom.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/P11Signature.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/P11TlsKeyMaterialGenerator.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/P11TlsMasterSecretGenerator.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/P11TlsPrfGenerator.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/P11TlsRsaPremasterSecretGenerator.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/P11Util.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/Secmod.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/Session.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/SessionManager.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/SunPKCS11.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/TemplateManager.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/Token.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_AES_CTR_PARAMS.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_ATTRIBUTE.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_CREATEMUTEX.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_C_INITIALIZE_ARGS.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_DATE.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_DESTROYMUTEX.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_ECDH1_DERIVE_PARAMS.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_ECDH2_DERIVE_PARAMS.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_INFO.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_LOCKMUTEX.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM_INFO.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_NOTIFY.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_PBE_PARAMS.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_RSA_PKCS_OAEP_PARAMS.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_RSA_PKCS_PSS_PARAMS.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_SESSION_INFO.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_SLOT_INFO.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_SSL3_KEY_MAT_OUT.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_SSL3_KEY_MAT_PARAMS.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_SSL3_MASTER_KEY_DERIVE_PARAMS.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_SSL3_RANDOM_DATA.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_TLS_PRF_PARAMS.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_TOKEN_INFO.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_UNLOCKMUTEX.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_VERSION.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH1_DERIVE_PARAMS.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH2_DERIVE_PARAMS.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/Constants.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/Functions.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/PKCS11.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/PKCS11Exception.java - src/jdk.crypto.token/share/classes/sun/security/pkcs11/wrapper/PKCS11RuntimeException.java - src/jdk.crypto.token/share/legal/pkcs11cryptotoken.md - src/jdk.crypto.token/share/legal/pkcs11wrapper.md - src/jdk.crypto.token/share/native/libj2pkcs11/j2secmod.c - src/jdk.crypto.token/share/native/libj2pkcs11/j2secmod.h - src/jdk.crypto.token/share/native/libj2pkcs11/p11_convert.c - src/jdk.crypto.token/share/native/libj2pkcs11/p11_crypt.c - src/jdk.crypto.token/share/native/libj2pkcs11/p11_digest.c - src/jdk.crypto.token/share/native/libj2pkcs11/p11_dual.c - src/jdk.crypto.token/share/native/libj2pkcs11/p11_general.c - src/jdk.crypto.token/share/native/libj2pkcs11/p11_keymgmt.c - src/jdk.crypto.token/share/native/libj2pkcs11/p11_mutex.c - src/jdk.crypto.token/share/native/libj2pkcs11/p11_objmgmt.c - src/jdk.crypto.token/share/native/libj2pkcs11/p11_sessmgmt.c - src/jdk.crypto.token/share/native/libj2pkcs11/p11_sign.c - src/jdk.crypto.token/share/native/libj2pkcs11/p11_util.c - src/jdk.crypto.token/share/native/libj2pkcs11/pkcs-11v2-20a3.h - src/jdk.crypto.token/share/native/libj2pkcs11/pkcs11.h - src/jdk.crypto.token/share/native/libj2pkcs11/pkcs11f.h - src/jdk.crypto.token/share/native/libj2pkcs11/pkcs11t.h - src/jdk.crypto.token/share/native/libj2pkcs11/pkcs11wrapper.h - src/jdk.crypto.token/solaris/conf/security/sunpkcs11-solaris.cfg - src/jdk.crypto.token/unix/native/libj2pkcs11/j2secmod_md.c - src/jdk.crypto.token/unix/native/libj2pkcs11/j2secmod_md.h - src/jdk.crypto.token/unix/native/libj2pkcs11/p11_md.c - src/jdk.crypto.token/unix/native/libj2pkcs11/p11_md.h - src/jdk.crypto.token/windows/native/libj2pkcs11/j2secmod_md.c - src/jdk.crypto.token/windows/native/libj2pkcs11/j2secmod_md.h - src/jdk.crypto.token/windows/native/libj2pkcs11/p11_md.c - src/jdk.crypto.token/windows/native/libj2pkcs11/p11_md.h Changeset: 89cafca458bf Author: jdv Date: 2017-01-27 12:16 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/89cafca458bf 8152561: Is it allowed to have zero value for count in TIFFField.createArrayForType() for the rationals Reviewed-by: psadhukhan, bpb, prr ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/TIFFField.java + test/javax/imageio/plugins/tiff/TIFFCreateArrayForTypeTest.java Changeset: f1d109bc09fe Author: psadhukhan Date: 2017-01-27 15:37 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f1d109bc09fe 7190595: Nimbus: Test6657026 fails Reviewed-by: yan, jdv ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthSplitPaneUI.java ! test/javax/swing/plaf/basic/BasicSplitPaneUI/Test6657026.java Changeset: b85ea2af6b5d Author: pnarayanan Date: 2017-01-30 16:32 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b85ea2af6b5d 8167278: ArrayIndexOutOfBoundsException when calling ImageIO.read(InputStream) with RLE4 BMP Reviewed-by: prr, bpb, jdv ! src/java.desktop/share/classes/com/sun/imageio/plugins/bmp/BMPImageReader.java Changeset: ba7ede80cea4 Author: ddehaven Date: 2017-01-30 12:04 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ba7ede80cea4 Merge - test/tools/jlink/CustomPluginTest.java - test/tools/jlink/customplugin/module-info.java - test/tools/jlink/customplugin/plugin/CustomPlugin.java - test/tools/jlink/customplugin/plugin/HelloPlugin.java - test/tools/jlink/customplugin/plugin/RogueAdderPlugin.java - test/tools/jlink/customplugin/plugin/RogueFilterPlugin.java Changeset: b48677ae75b4 Author: ddehaven Date: 2017-02-03 08:15 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b48677ae75b4 Merge Changeset: 622cc51a38ce Author: dl Date: 2017-02-03 13:24 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/622cc51a38ce 8173706: Is able to set a negative j.u.Vector size in JDK9 b151 Reviewed-by: martin, psandoz, smarks ! src/java.base/share/classes/java/util/Vector.java ! test/java/util/concurrent/tck/VectorTest.java Changeset: 06bdfec766f4 Author: dl Date: 2017-02-03 13:24 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/06bdfec766f4 8169748: LinkedTransferQueue bulk remove is O(n^2) 8172023: Concurrent spliterators fail to handle exhaustion properly Reviewed-by: martin, psandoz, smarks ! src/java.base/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java ! src/java.base/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java ! src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java ! src/java.base/share/classes/java/util/concurrent/LinkedBlockingQueue.java ! src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java ! src/java.base/share/classes/java/util/concurrent/PriorityBlockingQueue.java ! test/java/util/Collection/RemoveMicroBenchmark.java + test/java/util/concurrent/ConcurrentLinkedQueue/WhiteBox.java + test/java/util/concurrent/LinkedTransferQueue/WhiteBox.java ! test/java/util/concurrent/tck/Collection8Test.java Changeset: 0aedd507e3cd Author: dl Date: 2017-02-03 13:24 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0aedd507e3cd 8171886: Miscellaneous changes imported from jsr166 CVS 2017-02 Reviewed-by: martin, psandoz ! src/java.base/share/classes/java/util/PriorityQueue.java ! src/java.base/share/classes/java/util/concurrent/ArrayBlockingQueue.java ! src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListSet.java ! src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java ! src/java.base/share/classes/java/util/concurrent/DelayQueue.java ! src/java.base/share/classes/java/util/concurrent/SynchronousQueue.java ! src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java ! src/java.base/share/classes/java/util/concurrent/locks/LockSupport.java ! test/java/util/AbstractList/CheckForComodification.java ! test/java/util/ArrayList/Bug6533203.java ! test/java/util/ArrayList/IteratorMicroBenchmark.java ! test/java/util/ArrayList/RangeCheckMicroBenchmark.java ! test/java/util/Collection/IteratorMicroBenchmark.java ! test/java/util/Collection/MOAT.java ! test/java/util/Collections/BigBinarySearch.java ! test/java/util/Collections/Disjoint.java ! test/java/util/Collections/RacingCollections.java ! test/java/util/Collections/ReverseOrder2.java ! test/java/util/Collections/SetFromMap.java ! test/java/util/Deque/ChorusLine.java ! test/java/util/IdentityHashMap/ToArray.java ! test/java/util/IdentityHashMap/ToString.java ! test/java/util/NavigableMap/LockStep.java ! test/java/util/PriorityQueue/ForgetMeNot.java ! test/java/util/PriorityQueue/NoNulls.java ! test/java/util/PriorityQueue/PriorityQueueSort.java ! test/java/util/PriorityQueue/RemoveContains.java ! test/java/util/Random/DistinctSeeds.java ! test/java/util/TreeMap/NullAtEnd.java ! test/java/util/Vector/CopyInto.java ! test/java/util/concurrent/ArrayBlockingQueue/IteratorConsistency.java ! test/java/util/concurrent/BlockingQueue/CancelledProducerConsumerLoops.java ! test/java/util/concurrent/BlockingQueue/DrainToFails.java ! test/java/util/concurrent/BlockingQueue/Interrupt.java ! test/java/util/concurrent/BlockingQueue/PollMemoryLeak.java ! test/java/util/concurrent/ConcurrentHashMap/MapCheck.java ! test/java/util/concurrent/ConcurrentHashMap/MapLoops.java ! test/java/util/concurrent/ConcurrentLinkedQueue/RemoveLeak.java ! test/java/util/concurrent/ConcurrentMap/ConcurrentRemoveIf.java ! test/java/util/concurrent/ConcurrentQueues/ConcurrentQueueLoops.java ! test/java/util/concurrent/ConcurrentQueues/GCRetention.java ! test/java/util/concurrent/ConcurrentQueues/IteratorWeakConsistency.java ! test/java/util/concurrent/ConcurrentQueues/RemovePollRace.java ! test/java/util/concurrent/CopyOnWriteArrayList/EqualsRace.java ! test/java/util/concurrent/CopyOnWriteArraySet/RacingCows.java ! test/java/util/concurrent/CyclicBarrier/Basic.java ! test/java/util/concurrent/DelayQueue/Iterate.java ! test/java/util/concurrent/DelayQueue/PollUnexpired.java ! test/java/util/concurrent/DelayQueue/Stress.java ! test/java/util/concurrent/Exchanger/ExchangeLoops.java ! test/java/util/concurrent/Executors/PrivilegedCallables.java ! test/java/util/concurrent/FutureTask/BlockingTaskExecutor.java ! test/java/util/concurrent/FutureTask/Customized.java ! test/java/util/concurrent/FutureTask/DoneMeansDone.java ! test/java/util/concurrent/FutureTask/DoneTimedGetLoops.java ! test/java/util/concurrent/LinkedBlockingQueue/ToArray.java ! test/java/util/concurrent/Phaser/Arrive.java ! test/java/util/concurrent/Phaser/Basic.java ! test/java/util/concurrent/Phaser/FickleRegister.java ! test/java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java ! test/java/util/concurrent/ThreadPoolExecutor/CoreThreadTimeOut.java ! test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java ! test/java/util/concurrent/atomic/Lazy.java ! test/java/util/concurrent/locks/Lock/CheckedLockLoops.java ! test/java/util/concurrent/locks/Lock/TimedAcquireLeak.java ! test/java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.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/tck/AbstractExecutorServiceTest.java ! test/java/util/concurrent/tck/AbstractQueuedLongSynchronizerTest.java ! test/java/util/concurrent/tck/AbstractQueuedSynchronizerTest.java ! test/java/util/concurrent/tck/Atomic8Test.java ! test/java/util/concurrent/tck/AtomicReferenceArrayTest.java ! test/java/util/concurrent/tck/CompletableFutureTest.java ! test/java/util/concurrent/tck/ConcurrentHashMapTest.java ! test/java/util/concurrent/tck/ConcurrentLinkedDequeTest.java ! test/java/util/concurrent/tck/ConcurrentLinkedQueueTest.java ! test/java/util/concurrent/tck/CopyOnWriteArrayListTest.java ! test/java/util/concurrent/tck/CopyOnWriteArraySetTest.java ! test/java/util/concurrent/tck/CountedCompleterTest.java ! test/java/util/concurrent/tck/DelayQueueTest.java ! test/java/util/concurrent/tck/ExecutorsTest.java ! test/java/util/concurrent/tck/ForkJoinPoolTest.java ! test/java/util/concurrent/tck/LinkedListTest.java ! test/java/util/concurrent/tck/LinkedTransferQueueTest.java ! test/java/util/concurrent/tck/PhaserTest.java ! test/java/util/concurrent/tck/PriorityQueueTest.java ! test/java/util/concurrent/tck/ReentrantLockTest.java ! test/java/util/concurrent/tck/ReentrantReadWriteLockTest.java ! test/java/util/concurrent/tck/ScheduledExecutorSubclassTest.java ! test/java/util/concurrent/tck/ScheduledExecutorTest.java ! test/java/util/concurrent/tck/SubmissionPublisherTest.java ! test/java/util/concurrent/tck/SynchronousQueueTest.java ! test/java/util/concurrent/tck/ThreadPoolExecutorSubclassTest.java ! test/java/util/concurrent/tck/ThreadPoolExecutorTest.java ! test/java/util/concurrent/tck/TreeSetTest.java ! test/java/util/concurrent/tck/TreeSubSetTest.java Changeset: 4ebe8e908989 Author: mchung Date: 2017-02-03 18:06 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4ebe8e908989 8173412: @Test in java/lang/annotation and java/lang/reflect/Proxy tests not run Reviewed-by: redestad ! test/java/lang/annotation/AnnotationWithLambda.java ! test/java/lang/reflect/Proxy/ProxyForMethodHandle.java Changeset: 5315de9bf0e3 Author: vtewari Date: 2016-12-23 12:15 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5315de9bf0e3 8170861: Remove DcmdMBeanPermissionsTest.java from ProblemList Summary: removed DcmdMBeanPermissionsTest.java from ProblemList Reviewed-by: dholmes, fparain Contributed-by: ujwal.vangapally at oracle.com ! test/ProblemList.txt Changeset: 531f23cf8fb6 Author: dfazunen Date: 2016-12-27 16:24 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/531f23cf8fb6 8171441: tools/launcher/VersionCheck.java doesn't report names of tools which failed checks Reviewed-by: stsmirno, iignatyev, anazarov ! test/tools/launcher/VersionCheck.java Changeset: a099563cb23c Author: jwilhelm Date: 2016-12-27 22:34 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a099563cb23c Merge ! test/ProblemList.txt Changeset: 6002279db5b9 Author: ctornqvi Date: 2017-01-05 16:46 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6002279db5b9 8172188: JDI tests fail due to "permission denied" when creating temp file Reviewed-by: hseigel, mseledtsov ! test/com/sun/jdi/ShellScaffold.sh Changeset: b747d4c9a917 Author: jwilhelm Date: 2017-01-09 15:10 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b747d4c9a917 Merge Changeset: 727e88de35ed Author: hseigel Date: 2017-01-13 10:45 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/727e88de35ed 8172288: Fix Jigsaw related module/package error messages and throw correct exceptions Summary: Reword error messages and throw IllegalStateExceptions where appropriate Reviewed-by: alanb, acorn, lfoltan, gtriantafill ! src/java.base/share/classes/java/lang/reflect/Layer.java Changeset: dac0e2eafbd5 Author: jwilhelm Date: 2017-01-13 18:26 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/dac0e2eafbd5 Merge Changeset: e56f36205735 Author: jwilhelm Date: 2017-01-16 16:18 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e56f36205735 Merge Changeset: a2d3b7f65c95 Author: redestad Date: 2017-01-19 11:27 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a2d3b7f65c95 8171855: Move package name transformations during module bootstrap into native code Reviewed-by: alanb, acorn, lfoltan, mchung, plevart, hseigel, sspitsyn ! src/java.base/share/classes/java/lang/reflect/Module.java ! src/java.base/share/native/include/jvm.h ! src/java.base/share/native/libjava/Module.c Changeset: 5c08f2a9daee Author: gtriantafill Date: 2017-01-19 10:55 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5c08f2a9daee 8152206: Simplify jvmstat modules Reviewed-by: alanb, mchung, hseigel ! src/java.base/share/classes/module-info.java ! src/jdk.attach/share/classes/module-info.java + src/jdk.internal.jvmstat/share/classes/module-info.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/AbstractMonitor.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/BufferedMonitoredVm.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/ByteArrayMonitor.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/HostIdentifier.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/IntegerMonitor.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/LongMonitor.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/Monitor.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/MonitorException.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/MonitoredHost.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/MonitoredHostService.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/MonitoredVm.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/MonitoredVmUtil.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/StringMonitor.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/Units.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/Variability.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/VmIdentifier.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/event/HostEvent.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/event/HostListener.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/event/MonitorStatusChangeEvent.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/event/VmEvent.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/event/VmListener.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/event/VmStatusChangeEvent.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/event/package.html + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/package.html + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/AbstractMonitoredVm.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/AbstractPerfDataBuffer.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/AbstractPerfDataBufferPrologue.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/AliasFileParser.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/CountedTimerTask.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/CountedTimerTaskUtils.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/MonitorDataException.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/MonitorStatus.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/MonitorStructureException.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/MonitorTypeException.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/MonitorVersionException.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfByteArrayMonitor.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfDataBufferImpl.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfIntegerMonitor.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfLongMonitor.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfStringConstantMonitor.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfStringMonitor.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfStringVariableMonitor.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/SyntaxException.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/package.html + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/FileMonitoredVm.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/MonitoredHostFileService.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/MonitoredHostProvider.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/PerfDataBuffer.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/package.html + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/LocalEventTimer.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/LocalMonitoredVm.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/LocalVmManager.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/MonitoredHostLocalService.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/MonitoredHostProvider.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/PerfDataBuffer.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/PerfDataFile.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/package.html + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v1_0/BasicType.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v1_0/PerfDataBuffer.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v1_0/PerfDataBufferPrologue.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v2_0/PerfDataBuffer.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v2_0/PerfDataBufferPrologue.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v2_0/TypeCode.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/resources/aliasmap ! src/jdk.jcmd/share/classes/module-info.java ! src/jdk.jconsole/share/classes/module-info.java ! src/jdk.jstatd/share/classes/module-info.java - src/jdk.jvmstat/share/classes/module-info.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/AbstractMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/BufferedMonitoredVm.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/ByteArrayMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/HostIdentifier.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/IntegerMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/LongMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/Monitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/MonitorException.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/MonitoredHost.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/MonitoredHostService.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/MonitoredVm.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/MonitoredVmUtil.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/StringMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/Units.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/Variability.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/VmIdentifier.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/event/HostEvent.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/event/HostListener.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/event/MonitorStatusChangeEvent.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/event/VmEvent.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/event/VmListener.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/event/VmStatusChangeEvent.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/event/package.html - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/package.html - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/AbstractMonitoredVm.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/AbstractPerfDataBuffer.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/AbstractPerfDataBufferPrologue.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/AliasFileParser.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/CountedTimerTask.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/CountedTimerTaskUtils.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/MonitorDataException.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/MonitorStatus.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/MonitorStructureException.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/MonitorTypeException.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/MonitorVersionException.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfByteArrayMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfDataBufferImpl.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfIntegerMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfLongMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfStringConstantMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfStringMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfStringVariableMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/SyntaxException.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/package.html - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/FileMonitoredVm.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/MonitoredHostFileService.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/MonitoredHostProvider.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/PerfDataBuffer.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/package.html - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/LocalEventTimer.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/LocalMonitoredVm.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/LocalVmManager.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/MonitoredHostLocalService.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/MonitoredHostProvider.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/PerfDataBuffer.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/PerfDataFile.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/package.html - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v1_0/BasicType.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v1_0/PerfDataBuffer.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v1_0/PerfDataBufferPrologue.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v2_0/PerfDataBuffer.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v2_0/PerfDataBufferPrologue.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v2_0/TypeCode.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/resources/aliasmap ! test/sun/jvmstat/monitor/HostIdentifier/HostIdentifierCreate.java ! test/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java ! test/sun/jvmstat/monitor/MonitoredVm/TestPollingInterval.java ! test/sun/jvmstat/monitor/VmIdentifier/VmIdentifierCreateResolve.java ! test/sun/jvmstat/perfdata/PrologSanity/PrologSizeSanityCheck.java Changeset: 79dbfcdbe1b0 Author: rraghavan Date: 2017-01-20 04:42 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/79dbfcdbe1b0 8167337: When jmxremote.port=0, JDP broadcasts "0" instead of assigned port Summary: Fetched the correct jmx service url for jdp to broadcast it. Reviewed-by: dsamersoff, rriggs Contributed-by: amit.sapre at oracle.com ! src/java.management/share/classes/sun/management/Agent.java ! test/sun/management/jdp/DynamicLauncher.java + test/sun/management/jdp/JdpJmxRemoteDynamicPortTest.java + test/sun/management/jdp/JdpJmxRemoteDynamicPortTestCase.java Changeset: 825a12434329 Author: dpochepk Date: 2017-01-23 16:31 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/825a12434329 8171149: java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java failed with "Out of space in CodeCache for adapters" Reviewed-by: kvn ! test/java/lang/invoke/LFCaching/LambdaFormTestCase.java ! test/lib/testlibrary/jsr292/com/oracle/testlibrary/jsr292/CodeCacheOverflowProcessor.java Changeset: 33e6f9b9e3b5 Author: vtewari Date: 2017-01-25 15:31 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/33e6f9b9e3b5 8167178: Exported elements referring to inaccessible types in java.naming Reviewed-by: chegar, rriggs, alanb ! src/java.naming/share/classes/javax/naming/CompoundName.java Changeset: 955d8b6ded80 Author: jwilhelm Date: 2017-01-24 00:30 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/955d8b6ded80 Merge ! src/java.base/share/classes/module-info.java - src/java.base/share/classes/sun/security/util/AuthResourcesProvider.java - src/java.base/share/classes/sun/security/util/AuthResourcesProviderImpl.java - src/linux/doc/man/ja/jvisualvm.1 - src/linux/doc/man/jvisualvm.1 - src/solaris/doc/sun/man/man1/ja/jvisualvm.1 - src/solaris/doc/sun/man/man1/jvisualvm.1 ! test/ProblemList.txt - test/java/lang/SecurityManager/RestrictedPackages.java - test/java/rmi/registry/readTest/readTest.java - test/java/rmi/registry/readTest/readTest.sh - test/lib/security/SecurityTools.java - test/tools/jar/mmrjar/ConcealedPackage.java - test/tools/jmod/hashes/src/m1/module-info.java - test/tools/jmod/hashes/src/m1/org/m1/Main.java - test/tools/jmod/hashes/src/m2/module-info.java - test/tools/jmod/hashes/src/m2/org/m2/Util.java - test/tools/jmod/hashes/src/m3/module-info.java - test/tools/jmod/hashes/src/m3/org/m3/Name.java - test/tools/jmod/hashes/src/org.bar/module-info.java - test/tools/jmod/hashes/src/org.foo/module-info.java ! test/tools/launcher/VersionCheck.java Changeset: 0eb0f644345d Author: jwilhelm Date: 2017-02-04 03:29 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0eb0f644345d Merge ! src/java.base/share/classes/module-info.java + src/jdk.internal.jvmstat/share/classes/module-info.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/AbstractMonitor.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/BufferedMonitoredVm.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/ByteArrayMonitor.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/HostIdentifier.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/IntegerMonitor.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/LongMonitor.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/Monitor.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/MonitorException.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/MonitoredHost.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/MonitoredHostService.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/MonitoredVm.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/MonitoredVmUtil.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/StringMonitor.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/Units.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/Variability.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/VmIdentifier.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/event/HostEvent.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/event/HostListener.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/event/MonitorStatusChangeEvent.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/event/VmEvent.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/event/VmListener.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/event/VmStatusChangeEvent.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/event/package.html + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/package.html + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/AbstractMonitoredVm.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/AbstractPerfDataBuffer.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/AbstractPerfDataBufferPrologue.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/AliasFileParser.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/CountedTimerTask.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/CountedTimerTaskUtils.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/MonitorDataException.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/MonitorStatus.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/MonitorStructureException.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/MonitorTypeException.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/MonitorVersionException.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfByteArrayMonitor.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfDataBufferImpl.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfIntegerMonitor.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfLongMonitor.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfStringConstantMonitor.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfStringMonitor.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfStringVariableMonitor.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/SyntaxException.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/package.html + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/FileMonitoredVm.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/MonitoredHostFileService.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/MonitoredHostProvider.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/PerfDataBuffer.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/package.html + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/LocalEventTimer.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/LocalMonitoredVm.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/LocalVmManager.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/MonitoredHostLocalService.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/MonitoredHostProvider.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/PerfDataBuffer.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/PerfDataFile.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/package.html + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v1_0/BasicType.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v1_0/PerfDataBuffer.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v1_0/PerfDataBufferPrologue.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v2_0/PerfDataBuffer.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v2_0/PerfDataBufferPrologue.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v2_0/TypeCode.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/resources/aliasmap ! src/jdk.jconsole/share/classes/module-info.java - src/jdk.jvmstat/share/classes/module-info.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/AbstractMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/BufferedMonitoredVm.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/ByteArrayMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/HostIdentifier.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/IntegerMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/LongMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/Monitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/MonitorException.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/MonitoredHost.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/MonitoredHostService.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/MonitoredVm.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/MonitoredVmUtil.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/StringMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/Units.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/Variability.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/VmIdentifier.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/event/HostEvent.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/event/HostListener.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/event/MonitorStatusChangeEvent.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/event/VmEvent.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/event/VmListener.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/event/VmStatusChangeEvent.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/event/package.html - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/package.html - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/AbstractMonitoredVm.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/AbstractPerfDataBuffer.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/AbstractPerfDataBufferPrologue.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/AliasFileParser.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/CountedTimerTask.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/CountedTimerTaskUtils.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/MonitorDataException.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/MonitorStatus.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/MonitorStructureException.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/MonitorTypeException.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/MonitorVersionException.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfByteArrayMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfDataBufferImpl.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfIntegerMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfLongMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfStringConstantMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfStringMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfStringVariableMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/SyntaxException.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/package.html - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/FileMonitoredVm.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/MonitoredHostFileService.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/MonitoredHostProvider.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/PerfDataBuffer.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/package.html - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/LocalEventTimer.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/LocalMonitoredVm.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/LocalVmManager.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/MonitoredHostLocalService.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/MonitoredHostProvider.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/PerfDataBuffer.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/PerfDataFile.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/package.html - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v1_0/BasicType.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v1_0/PerfDataBuffer.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v1_0/PerfDataBufferPrologue.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v2_0/PerfDataBuffer.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v2_0/PerfDataBufferPrologue.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v2_0/TypeCode.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/resources/aliasmap ! src/jdk.management.agent/share/classes/jdk/internal/agent/Agent.java ! test/ProblemList.txt Changeset: 19aaaf6ee13e Author: lancea Date: 2017-02-04 14:04 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/19aaaf6ee13e 8173604: Rename module 8173604 java.annotations.common to java.xml.ws.annoations Reviewed-by: dfuchs, alanb, psandoz, mchung ! make/src/classes/build/tools/jigsaw/GenGraphs.java ! make/src/classes/build/tools/jigsaw/technology-summary.html ! src/java.se.ee/share/classes/module-info.java ! test/tools/launcher/modules/addmods/AddModsTest.java Changeset: 2719a1f55cd8 Author: jlahoda Date: 2017-02-06 11:07 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2719a1f55cd8 8173653: jshell tool: ctrl-C when in external editor aborts jshell -- history lost Summary: Adding ability for WindowsTerminal subclasses to get and set console mode. Reviewed-by: rfield ! src/jdk.internal.le/share/classes/jdk/internal/jline/WindowsTerminal.java Changeset: 93005a285d67 Author: mullan Date: 2017-02-06 08:59 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/93005a285d67 8173827: Remove forRemoval=true from several deprecated security APIs Reviewed-by: redestad, xuelei ! src/java.base/share/classes/com/sun/net/ssl/HostnameVerifier.java ! src/java.base/share/classes/com/sun/net/ssl/HttpsURLConnection.java ! src/java.base/share/classes/com/sun/net/ssl/KeyManager.java ! src/java.base/share/classes/com/sun/net/ssl/KeyManagerFactory.java ! src/java.base/share/classes/com/sun/net/ssl/KeyManagerFactorySpi.java ! src/java.base/share/classes/com/sun/net/ssl/SSLContext.java ! src/java.base/share/classes/com/sun/net/ssl/SSLContextSpi.java ! src/java.base/share/classes/com/sun/net/ssl/SSLPermission.java ! src/java.base/share/classes/com/sun/net/ssl/TrustManager.java ! src/java.base/share/classes/com/sun/net/ssl/TrustManagerFactory.java ! src/java.base/share/classes/com/sun/net/ssl/TrustManagerFactorySpi.java ! src/java.base/share/classes/com/sun/net/ssl/X509KeyManager.java ! src/java.base/share/classes/com/sun/net/ssl/X509TrustManager.java ! src/java.base/share/classes/com/sun/net/ssl/internal/ssl/Provider.java ! src/java.base/share/classes/com/sun/net/ssl/internal/ssl/X509ExtendedTrustManager.java ! src/java.base/share/classes/com/sun/net/ssl/internal/www/protocol/https/DelegateHttpsURLConnection.java ! src/java.base/share/classes/com/sun/net/ssl/internal/www/protocol/https/Handler.java ! src/java.base/share/classes/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnectionOldImpl.java ! src/java.base/share/classes/java/security/Certificate.java ! src/java.base/share/classes/java/security/Identity.java ! src/java.base/share/classes/java/security/IdentityScope.java ! src/java.base/share/classes/java/security/Signer.java ! src/java.base/share/classes/java/security/acl/Acl.java ! src/java.base/share/classes/java/security/acl/AclEntry.java ! src/java.base/share/classes/java/security/acl/AclNotFoundException.java ! src/java.base/share/classes/java/security/acl/Group.java ! src/java.base/share/classes/java/security/acl/LastOwnerException.java ! src/java.base/share/classes/java/security/acl/NotOwnerException.java ! src/java.base/share/classes/java/security/acl/Owner.java ! src/java.base/share/classes/java/security/acl/Permission.java ! src/java.base/share/classes/java/security/acl/package-info.java ! src/java.base/share/classes/javax/net/ssl/HandshakeCompletedEvent.java ! src/java.base/share/classes/javax/net/ssl/SSLSession.java ! src/java.base/share/classes/javax/security/auth/Policy.java ! src/java.base/share/classes/javax/security/cert/Certificate.java ! src/java.base/share/classes/javax/security/cert/CertificateEncodingException.java ! src/java.base/share/classes/javax/security/cert/CertificateException.java ! src/java.base/share/classes/javax/security/cert/CertificateExpiredException.java ! src/java.base/share/classes/javax/security/cert/CertificateNotYetValidException.java ! src/java.base/share/classes/javax/security/cert/CertificateParsingException.java ! src/java.base/share/classes/javax/security/cert/X509Certificate.java Changeset: d571f86c2762 Author: mchung Date: 2017-02-06 08:03 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d571f86c2762 8173947: jconsole does not show local running VMs to attach Reviewed-by: alanb, dholmes, dfuchs ! src/jdk.jconsole/share/classes/sun/tools/jconsole/JConsole.java Changeset: 3ec66890e682 Author: vinnie Date: 2017-02-06 17:28 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3ec66890e682 8173956: KeyStore regression due to default keystore being changed to PKCS12 Reviewed-by: xuelei ! src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java + test/sun/security/pkcs12/MixedcaseAlias.java Changeset: 63f21de94ffd Author: redestad Date: 2017-02-06 22:23 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/63f21de94ffd 8173982: (fs) DefaultFileSystemProvider should be split into platform specific versions Reviewed-by: alanb + src/java.base/aix/classes/sun/nio/fs/DefaultFileSystemProvider.java + src/java.base/linux/classes/sun/nio/fs/DefaultFileSystemProvider.java + src/java.base/macosx/classes/sun/nio/fs/DefaultFileSystemProvider.java + src/java.base/solaris/classes/sun/nio/fs/DefaultFileSystemProvider.java - src/java.base/unix/classes/sun/nio/fs/DefaultFileSystemProvider.java Changeset: 7d64e541a6c0 Author: dl Date: 2017-02-07 00:38 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7d64e541a6c0 8172726: ForkJoin common pool retains a reference to the thread context class loader Reviewed-by: martin, psandoz, chegar ! src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java ! src/java.base/share/classes/java/util/concurrent/ForkJoinWorkerThread.java + test/java/util/concurrent/tck/ForkJoinPool9Test.java ! test/java/util/concurrent/tck/JSR166TestCase.java + test/java/util/concurrent/tck/tck.policy Changeset: 847d7a6aef45 Author: lana Date: 2017-02-09 17:21 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/847d7a6aef45 Added tag jdk-9+156 for changeset 7d64e541a6c0 ! .hgtags Changeset: b6294de9b2ea Author: alanb Date: 2017-02-09 20:53 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b6294de9b2ea Merge ! .hgtags - make/copy/Copy-java.management.gmk - make/gensrc/Gensrc-java.management.gmk + make/gensrc/Gensrc-jdk.management.agent.gmk ! make/lib/Lib-java.management.gmk ! make/lib/Lib-java.security.jgss.gmk ! make/lib/Lib-jdk.crypto.ec.gmk ! make/lib/NetworkingLibraries.gmk - make/rmic/Rmic-java.management.gmk + make/rmic/Rmic-java.management.rmi.gmk ! make/src/classes/build/tools/jigsaw/GenGraphs.java ! make/src/classes/build/tools/jigsaw/technology-summary.html ! 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/module-info.java ! src/java.base/share/classes/sun/launcher/LauncherHelper.java ! src/java.base/share/classes/sun/launcher/resources/launcher.properties ! src/java.base/share/native/include/jvm.h ! src/java.base/share/native/libjava/Module.c ! src/java.base/share/native/libjli/java.c - src/java.base/unix/classes/sun/nio/fs/DefaultFileSystemProvider.java + src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnector.java - src/java.management/share/classes/com/sun/jmx/remote/internal/ProxyRef.java - src/java.management/share/classes/com/sun/jmx/remote/internal/RMIExporter.java - src/java.management/share/classes/com/sun/jmx/remote/internal/Unmarshal.java - src/java.management/share/classes/com/sun/jmx/remote/protocol/rmi/ClientProvider.java - src/java.management/share/classes/com/sun/jmx/remote/protocol/rmi/ServerProvider.java ! src/java.management/share/classes/javax/management/remote/JMXConnectorFactory.java - src/java.management/share/classes/javax/management/remote/rmi/NoCallStackClassLoader.java - src/java.management/share/classes/javax/management/remote/rmi/RMIConnection.java - src/java.management/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java - src/java.management/share/classes/javax/management/remote/rmi/RMIConnector.java - src/java.management/share/classes/javax/management/remote/rmi/RMIConnectorServer.java - src/java.management/share/classes/javax/management/remote/rmi/RMIIIOPServerImpl.java - src/java.management/share/classes/javax/management/remote/rmi/RMIJRMPServerImpl.java - src/java.management/share/classes/javax/management/remote/rmi/RMIServer.java - src/java.management/share/classes/javax/management/remote/rmi/RMIServerImpl.java - src/java.management/share/classes/javax/management/remote/rmi/package.html ! src/java.management/share/classes/module-info.java - src/java.management/share/classes/sun/management/Agent.java - src/java.management/share/classes/sun/management/AgentConfigurationError.java - src/java.management/share/classes/sun/management/ConnectorAddressLink.java - src/java.management/share/classes/sun/management/FileSystem.java - src/java.management/share/classes/sun/management/jdp/JdpBroadcaster.java - src/java.management/share/classes/sun/management/jdp/JdpController.java - src/java.management/share/classes/sun/management/jdp/JdpException.java - src/java.management/share/classes/sun/management/jdp/JdpGenericPacket.java - src/java.management/share/classes/sun/management/jdp/JdpJmxPacket.java - src/java.management/share/classes/sun/management/jdp/JdpPacket.java - src/java.management/share/classes/sun/management/jdp/JdpPacketReader.java - src/java.management/share/classes/sun/management/jdp/JdpPacketWriter.java - src/java.management/share/classes/sun/management/jdp/package-info.java - src/java.management/share/classes/sun/management/jmxremote/ConnectorBootstrap.java - src/java.management/share/classes/sun/management/jmxremote/LocalRMIServerSocketFactory.java - src/java.management/share/classes/sun/management/jmxremote/SingleEntryRegistry.java - src/java.management/share/classes/sun/management/jmxremote/package.html - src/java.management/share/classes/sun/management/resources/agent.properties - src/java.management/share/classes/sun/management/resources/agent_de.properties - src/java.management/share/classes/sun/management/resources/agent_es.properties - src/java.management/share/classes/sun/management/resources/agent_fr.properties - src/java.management/share/classes/sun/management/resources/agent_it.properties - src/java.management/share/classes/sun/management/resources/agent_ja.properties - src/java.management/share/classes/sun/management/resources/agent_ko.properties - src/java.management/share/classes/sun/management/resources/agent_pt_BR.properties - src/java.management/share/classes/sun/management/resources/agent_sv.properties - src/java.management/share/classes/sun/management/resources/agent_zh_CN.properties - src/java.management/share/classes/sun/management/resources/agent_zh_TW.properties - src/java.management/share/classes/sun/management/spi/AgentProvider.java - src/java.management/share/conf/jmxremote.access - src/java.management/share/conf/jmxremote.password.template - src/java.management/share/conf/management.properties - src/java.management/share/conf/snmp.acl.template - src/java.management/unix/classes/sun/management/FileSystemImpl.java - src/java.management/unix/native/libmanagement/FileSystemImpl.c - src/java.management/windows/classes/sun/management/FileSystemImpl.java - src/java.management/windows/native/libmanagement/FileSystemImpl.c ! src/java.rmi/share/classes/module-info.java ! src/java.se.ee/share/classes/module-info.java ! src/java.se/share/classes/module-info.java ! src/jdk.attach/share/classes/module-info.java + src/jdk.internal.jvmstat/share/classes/module-info.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/AliasFileParser.java + src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfDataBufferImpl.java ! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties ! src/jdk.jcmd/share/classes/module-info.java ! src/jdk.jconsole/share/classes/module-info.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties - src/jdk.jvmstat/share/classes/module-info.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/AbstractMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/BufferedMonitoredVm.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/ByteArrayMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/HostIdentifier.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/IntegerMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/LongMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/Monitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/MonitorException.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/MonitoredHost.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/MonitoredHostService.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/MonitoredVm.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/MonitoredVmUtil.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/StringMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/Units.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/Variability.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/VmIdentifier.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/event/HostEvent.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/event/HostListener.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/event/MonitorStatusChangeEvent.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/event/VmEvent.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/event/VmListener.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/event/VmStatusChangeEvent.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/event/package.html - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/package.html - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/AbstractMonitoredVm.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/AbstractPerfDataBuffer.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/AbstractPerfDataBufferPrologue.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/AliasFileParser.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/CountedTimerTask.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/CountedTimerTaskUtils.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/MonitorDataException.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/MonitorStatus.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/MonitorStructureException.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/MonitorTypeException.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/MonitorVersionException.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfByteArrayMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfDataBufferImpl.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfIntegerMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfLongMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfStringConstantMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfStringMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfStringVariableMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/SyntaxException.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/package.html - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/FileMonitoredVm.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/MonitoredHostFileService.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/MonitoredHostProvider.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/PerfDataBuffer.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/package.html - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/LocalEventTimer.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/LocalMonitoredVm.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/LocalVmManager.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/MonitoredHostLocalService.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/MonitoredHostProvider.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/PerfDataBuffer.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/PerfDataFile.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/package.html - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v1_0/BasicType.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v1_0/PerfDataBuffer.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v1_0/PerfDataBufferPrologue.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v2_0/PerfDataBuffer.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v2_0/PerfDataBufferPrologue.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v2_0/TypeCode.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/resources/aliasmap + src/jdk.management.agent/share/classes/jdk/internal/agent/Agent.java ! test/ProblemList.txt ! test/com/sun/tools/attach/StartManagementAgent.java ! test/java/lang/reflect/Proxy/ProxyForMethodHandle.java ! test/java/util/Collection/MOAT.java ! test/java/util/concurrent/ArrayBlockingQueue/IteratorConsistency.java ! test/java/util/concurrent/BlockingQueue/PollMemoryLeak.java ! test/java/util/concurrent/ConcurrentLinkedQueue/RemoveLeak.java ! test/java/util/concurrent/tck/JSR166TestCase.java ! test/javax/management/MBeanInfo/NotificationInfoTest.java ! test/javax/management/remote/mandatory/connection/IdleTimeoutTest.java ! test/javax/management/remote/mandatory/connection/ObjectInputStreamWithLoaderNullCheckTest.java ! test/javax/management/remote/mandatory/connection/RMIConnectorInternalMapTest.java ! test/javax/management/remote/mandatory/connection/RMIConnectorNullSubjectConnTest.java ! test/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java ! test/javax/management/remote/mandatory/connectorServer/RMIExporterTest.java ! test/javax/management/remote/mandatory/connectorServer/SetMBeanServerForwarder.java ! test/javax/management/remote/mandatory/loading/MissingClassTest.java ! test/javax/management/remote/mandatory/notif/DeadListenerTest.java ! test/javax/management/remote/mandatory/notif/NotSerializableNotifTest.java ! test/javax/management/remote/mandatory/notif/NotificationAccessControllerTest.java ! test/javax/management/remote/mandatory/passwordAuthenticator/RMIAltAuthTest.java ! test/javax/management/remote/mandatory/passwordAuthenticator/RMIPasswdAuthTest.java ! test/javax/management/remote/mandatory/serverError/JMXServerErrorTest.java ! test/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java ! test/javax/management/remote/mandatory/util/MapNullValuesTest.java + test/jdk/internal/agent/AgentCMETest.java + test/jdk/internal/agent/AgentCheckTest.java ! test/sun/jvmstat/monitor/HostIdentifier/HostIdentifierCreate.java ! test/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java ! test/sun/jvmstat/monitor/MonitoredVm/TestPollingInterval.java ! test/sun/jvmstat/monitor/VmIdentifier/VmIdentifierCreateResolve.java ! test/sun/jvmstat/perfdata/PrologSanity/PrologSizeSanityCheck.java - test/sun/management/AgentCMETest.java - test/sun/management/AgentCheckTest.java ! test/sun/management/jdp/JdpDefaultsTest.java + test/sun/management/jdp/JdpJmxRemoteDynamicPortTest.java ! test/sun/management/jdp/JdpOffTest.java ! test/sun/management/jdp/JdpSpecificAddressTest.java ! test/sun/management/jmxremote/bootstrap/CustomLauncherTest.java ! test/sun/management/jmxremote/bootstrap/JvmstatCountersTest.java ! test/sun/management/jmxremote/bootstrap/LocalManagementTest.java ! test/sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh ! test/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh ! test/sun/management/jmxremote/bootstrap/RmiSslNoKeyStoreTest.sh ! test/sun/management/jmxremote/startstop/JMXStartStopTest.java ! test/sun/management/jmxremote/startstop/JMXStatusPerfCountersTest.java ! test/tools/jlink/JLinkTest.java ! test/tools/launcher/VersionCheck.java ! test/tools/launcher/modules/addmods/AddModsTest.java ! test/tools/launcher/modules/listmods/ListModsTest.java From Alan.Bateman at oracle.com Thu Feb 9 21:28:35 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 9 Feb 2017 21:28:35 +0000 Subject: 8173393: Module system implementation refresh (2/2017) In-Reply-To: References: Message-ID: <7e9e42b7-7579-1a0d-cf75-d740cf0c3b4c@oracle.com> On 07/02/2017 13:23, Alan Bateman wrote: > I will re-generate the webrevs later in the week once jdk-9+156 is > promoted before eventually merging with jdk9/dev in advance of the > eventual push. I've sync'ed up jake to jdk-9+156 and re-generated the webrevs: http://cr.openjdk.java.net/~alanb/8173393/3/ Assuming that nothing significant comes up then these are the changes that I'd like to push to jdk9/dev for jdk-9+157. -Alan From Alan.Bateman at oracle.com Thu Feb 9 21:42:22 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 9 Feb 2017 21:42:22 +0000 Subject: jlink RuntimeException: descriptor returns inconsistent package set In-Reply-To: <0ee41ff8-6682-fe7c-7ecc-315f430c8a09@oracle.com> References: <0ee41ff8-6682-fe7c-7ecc-315f430c8a09@oracle.com> Message-ID: <0a60f45d-1503-11f9-226f-a6fef296fc85@oracle.com> On 09/02/2017 18:42, Jim Connors wrote: > Trying to create JDK9 runtime image that includes only the necessary > modules to run a JavaFX program called Scoreboard. It has been > converted to a JDK9 module called Scoreboard and has dependencies on > system modules as well as another module called > com.jtconnors.socket. More details below, this program runs fine > when invoked with jdk9-ea+155 as follows (Scoreboard.jar and > com.jtconnors.socket.jar are in the current directory): > > C:\tmp\scratch>java --module-path . -m Scoreboard > > However when attempting to create the jlink image as follows, this > error message appears: > > C:\tmp\scratch>jlink --module-path .;\Users\jtconnor\jdk-9\jmods > --add-modules S > coreboard --output reducedImage --compress=2 --strip-debug > Error: java.lang.RuntimeException: Module Scoreboard's descriptor > returns incons > istent package set Jim - is Scoreboard a package module or is it exploded on the file system? If a packaged module is a modular JAR then can you say which version of the `jar` tool was used to create it? -Alan From vicente.romero at oracle.com Thu Feb 9 22:49:08 2017 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 9 Feb 2017 17:49:08 -0500 Subject: Confusing error message for inner non-public service provider In-Reply-To: <589A1E45.3060604@oracle.com> References: <5898F31A.1010101@oracle.com> <589A1E45.3060604@oracle.com> Message-ID: <92b56a2d-89ef-cb6d-82b7-d8efb928269e@oracle.com> Hi Alex, Just to double check, the right javac behavior in this case should be to issue similar errors in both cases like: some position here: error: ServiceImpl is not public in com.example.internal; cannot be accessed from outside package some other position here: error: Outer.ServiceImpl is not public in com.example.internal; cannot be accessed from outside package without mentioning in any case anything about visibility right? Thanks, Vicente On 02/07/2017 02:21 PM, Alex Buckley wrote: > On 2/7/2017 1:11 AM, Gunnar Morling wrote: >> --- >> package com.example; >> public interface SomeService { >> public void foo(); >> } >> --- >> package com.example.internal; >> class Outer { >> >> public static class ServiceImpl implements >> com.example.SomeService { >> public ServiceImpl() {} >> public void foo() {} >> } >> } >> --- >> package com.example.internal; >> class ServiceImpl implements com.example.SomeService { >> public ServiceImpl() {} >> public void foo() {} >> } >> --- >> module com.example { >> exports com.example; >> provides com.example.SomeService with >> com.example.internal.ServiceImpl; >> provides com.example.SomeService with >> com.example.internal.Outer.ServiceImpl; >> } >> --- >> >> Essentially, I'm wondering: >> >> * Why Outer.ServiceImpl triggers the error about package visibility >> while ServiceImpl doesn't (I had a look at the EDR JLS, but I couldn't >> find an explanation for that, happy about any specific pointers). >> * Why Outer.ServiceImpl triggers "does not have a default constructor" >> (ServiceImpl does not). Maybe a hint would be nice that is caused by >> Outer not having public access. > > Thanks for showing the code. Since everything in the same module, > package visibility is not relevant and javac shouldn't mention it. > > I suspect that javac is getting tripped up by the fact that > Outer.ServiceImpl is declared 'public' (as the JLS and ServiceLoader > both demand) but it isn't widely accessible, even within the > com.example module, due to Outer's default (package) access. I believe > the JLS and ServiceLoader rules are correct, so it's a javac bug. > > Alex From alex.buckley at oracle.com Thu Feb 9 23:07:40 2017 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 09 Feb 2017 15:07:40 -0800 Subject: Confusing error message for inner non-public service provider In-Reply-To: <92b56a2d-89ef-cb6d-82b7-d8efb928269e@oracle.com> References: <5898F31A.1010101@oracle.com> <589A1E45.3060604@oracle.com> <92b56a2d-89ef-cb6d-82b7-d8efb928269e@oracle.com> Message-ID: <589CF63C.2040202@oracle.com> On 2/9/2017 2:49 PM, Vicente Romero wrote: > Just to double check, the right javac behavior in this case should be to > issue similar errors in both cases like: > > some position here: error: ServiceImpl is not public in > com.example.internal; cannot be accessed from outside package It's correct to give an error, but the clause "cannot be accessed from outside package" should be dropped (it's not relevant to ServiceLoader). > some other position here: error: Outer.ServiceImpl is not public in > com.example.internal; cannot be accessed from outside package It's not correct to give an error at all. The JLS (acting on behalf of ServiceLoader) is not interested in the class Outer.ServiceImpl being "accessible" by some arbitrary client. All the JLS wants is for the class to be 'public'. > without mentioning in any case anything about visibility right? Correct. All the types we're discussing are in the same module so they (and their packages) are all visible to each other; package visibility is irrelevant to this example. Alex From vicente.romero at oracle.com Thu Feb 9 23:12:11 2017 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 9 Feb 2017 18:12:11 -0500 Subject: Confusing error message for inner non-public service provider In-Reply-To: <589CF63C.2040202@oracle.com> References: <5898F31A.1010101@oracle.com> <589A1E45.3060604@oracle.com> <92b56a2d-89ef-cb6d-82b7-d8efb928269e@oracle.com> <589CF63C.2040202@oracle.com> Message-ID: <84641613-92a9-e7ca-99b1-d120d8e7d959@oracle.com> Hi Alex, Thanks for your answer, Vicente On 02/09/2017 06:07 PM, Alex Buckley wrote: > On 2/9/2017 2:49 PM, Vicente Romero wrote: >> Just to double check, the right javac behavior in this case should be to >> issue similar errors in both cases like: >> >> some position here: error: ServiceImpl is not public in >> com.example.internal; cannot be accessed from outside package > > It's correct to give an error, but the clause "cannot be accessed from > outside package" should be dropped (it's not relevant to ServiceLoader). > >> some other position here: error: Outer.ServiceImpl is not public in >> com.example.internal; cannot be accessed from outside package > > It's not correct to give an error at all. The JLS (acting on behalf of > ServiceLoader) is not interested in the class Outer.ServiceImpl being > "accessible" by some arbitrary client. All the JLS wants is for the > class to be 'public'. > >> without mentioning in any case anything about visibility right? > > Correct. All the types we're discussing are in the same module so they > (and their packages) are all visible to each other; package visibility > is irrelevant to this example. > > Alex From jonathan.gibbons at oracle.com Fri Feb 10 00:21:56 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 9 Feb 2017 16:21:56 -0800 Subject: Confusing error message for inner non-public service provider In-Reply-To: <589CF63C.2040202@oracle.com> References: <5898F31A.1010101@oracle.com> <589A1E45.3060604@oracle.com> <92b56a2d-89ef-cb6d-82b7-d8efb928269e@oracle.com> <589CF63C.2040202@oracle.com> Message-ID: On 2/9/17 3:07 PM, Alex Buckley wrote: > All the JLS wants is for the class to be 'public'. Alex: Does that just apply locally to the declaration of the class itself, or does it also indirectly apply to any enclosing classes, in the case of a nested class? -- Jon From alex.buckley at oracle.com Fri Feb 10 01:23:30 2017 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 09 Feb 2017 17:23:30 -0800 Subject: Confusing error message for inner non-public service provider In-Reply-To: References: <5898F31A.1010101@oracle.com> <589A1E45.3060604@oracle.com> <92b56a2d-89ef-cb6d-82b7-d8efb928269e@oracle.com> <589CF63C.2040202@oracle.com> Message-ID: <589D1612.5000009@oracle.com> On 2/9/2017 4:21 PM, Jonathan Gibbons wrote: > On 2/9/17 3:07 PM, Alex Buckley wrote: >> All the JLS wants is for the class to be 'public'. > Does that just apply locally to the declaration of the class itself, or > does it also indirectly apply to any enclosing classes, in the case of a > nested class? Just the declaration of the class itself. The JLS does NOT want the specified class must be accessible from , which would imply a chain of accessibility from to the provider class. The JLS just wants the 'public' modifier on the class declaration, end of story. Alex From alex.buckley at oracle.com Fri Feb 10 01:31:30 2017 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 09 Feb 2017 17:31:30 -0800 Subject: Confusing error message for inner non-public service provider In-Reply-To: References: <5898F31A.1010101@oracle.com> <589A1E45.3060604@oracle.com> <92b56a2d-89ef-cb6d-82b7-d8efb928269e@oracle.com> <589CF63C.2040202@oracle.com> Message-ID: <589D17F2.90507@oracle.com> // Rewording and resending to avoid confusion. On 2/9/2017 4:21 PM, Jonathan Gibbons wrote: > On 2/9/17 3:07 PM, Alex Buckley wrote: >> All the JLS wants is for the class to be 'public'. > Does that just apply locally to the declaration of the class itself, or > does it also indirectly apply to any enclosing classes, in the case of a > nested class? Just the declaration of the class itself. The JLS does NOT want the specified class to be accessible from . That is, the JLS does not care about a chain of access from to the provider class, which might conceivably allow the provider class to have default (package) access. The JLS just wants the 'public' modifier on the class declaration, end of story. Alex From james.connors at oracle.com Fri Feb 10 01:47:24 2017 From: james.connors at oracle.com (Jim Connors) Date: Thu, 9 Feb 2017 20:47:24 -0500 Subject: jlink RuntimeException: descriptor returns inconsistent package set In-Reply-To: <0a60f45d-1503-11f9-226f-a6fef296fc85@oracle.com> References: <0ee41ff8-6682-fe7c-7ecc-315f430c8a09@oracle.com> <0a60f45d-1503-11f9-226f-a6fef296fc85@oracle.com> Message-ID: <19720521-df58-fe05-7864-b8ed6556fa69@oracle.com> >> C:\tmp\scratch>jlink --module-path .;\Users\jtconnor\jdk-9\jmods >> --add-modules S >> coreboard --output reducedImage --compress=2 --strip-debug >> Error: java.lang.RuntimeException: Module Scoreboard's descriptor >> returns incons >> istent package set > Jim - is Scoreboard a package module or is it exploded on the file > system? If a packaged module is a modular JAR then can you say which > version of the `jar` tool was used to create it? It's a JAR file. I used an early access build of NetBeans (supporting JDK9) to build the JAR. MANIFEST.MF contents: Manifest-Version: 1.0 Ant-Version: Apache Ant 1.10.0alpha Created-By: 1.8.0_121-b13 (Oracle Corporation) X-COMMENT: Main-Class will be added automatically by build Main-Class: scoreboard.fx2.Main Is a JDK9 version of jar required to build the JAR file? If so, then I wonder why the example I furnished, with com.jtconnors.socket, worked? It was built the same way. Thanks, -- Jim C From Alan.Bateman at oracle.com Fri Feb 10 07:05:45 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 10 Feb 2017 07:05:45 +0000 Subject: jlink RuntimeException: descriptor returns inconsistent package set In-Reply-To: <19720521-df58-fe05-7864-b8ed6556fa69@oracle.com> References: <0ee41ff8-6682-fe7c-7ecc-315f430c8a09@oracle.com> <0a60f45d-1503-11f9-226f-a6fef296fc85@oracle.com> <19720521-df58-fe05-7864-b8ed6556fa69@oracle.com> Message-ID: <675217c7-396d-f45e-bdf8-a1cab84abe13@oracle.com> On 10/02/2017 01:47, Jim Connors wrote: > > It's a JAR file. I used an early access build of NetBeans (supporting > JDK9) to build the JAR. > > MANIFEST.MF contents: > > Manifest-Version: 1.0 > Ant-Version: Apache Ant 1.10.0alpha > Created-By: 1.8.0_121-b13 (Oracle Corporation) > X-COMMENT: Main-Class will be added automatically by build > Main-Class: scoreboard.fx2.Main > > Is a JDK9 version of jar required to build the JAR file? If so, then > I wonder why the example I furnished, with com.jtconnors.socket, > worked? It was built the same way. > I think I need to see the JAR file to explain this. My guess is that it has the ModulePackages class file attribute with the non-exported packages rather than all packages (the ModulePackages changed a while back to include all packages). I can't be sure of course but we do need to improve the error message from jlink when it finds the mismatch with the JAR file contents. -Alan From s.2016.kay at gmail.com Fri Feb 10 07:24:58 2017 From: s.2016.kay at gmail.com (Ess Kay) Date: Fri, 10 Feb 2017 18:24:58 +1100 Subject: "OpenJDK specific" attribute specifications In-Reply-To: References: Message-ID: Thanks Alan. I am not 100% sure what you mean when you say that the ModuleHashes and ModuleResolution attributes are "JDK-specific". Are you saying that they may appear in Java 9 class files but it is assumed that they will only be used only by Java compilers as opposed to the JVM? From peter.levart at gmail.com Fri Feb 10 10:00:00 2017 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 10 Feb 2017 11:00:00 +0100 Subject: 8173393: Module system implementation refresh (2/2017) In-Reply-To: <7e9e42b7-7579-1a0d-cf75-d740cf0c3b4c@oracle.com> References: <7e9e42b7-7579-1a0d-cf75-d740cf0c3b4c@oracle.com> Message-ID: <88645880-d2fb-9c46-dfae-637047f370a3@gmail.com> Hi Alan, On 02/09/2017 10:28 PM, Alan Bateman wrote: > On 07/02/2017 13:23, Alan Bateman wrote: > >> I will re-generate the webrevs later in the week once jdk-9+156 is >> promoted before eventually merging with jdk9/dev in advance of the >> eventual push. > I've sync'ed up jake to jdk-9+156 and re-generated the webrevs: > http://cr.openjdk.java.net/~alanb/8173393/3/ > > Assuming that nothing significant comes up then these are the changes > that I'd like to push to jdk9/dev for jdk-9+157. > > -Alan First, just a nit... java.lang.module.Resolver: 320 private void addFoundModule(ModuleReference mref) { 321 ModuleDescriptor descriptor = mref.descriptor(); 322 nameToReference.put(descriptor.name(), mref); 323 324 if (descriptor.osName().isPresent() 325 || descriptor.osArch().isPresent() 326 || descriptor.osVersion().isPresent()) 327 checkTargetConstraints(descriptor); 328 } ...perhaps more correct would be to reverse the order: 1st check target constraints and then add descriptor to map. Otherwise in case of check failure, you end up with a Resolver instance that is poisoned with incompatible module descriptor. Maybe you always throw away such Resolver if this method fails, but maybe someone will sometime try to recover and continue to use the Resolver for rest of modules? ...then something more involving... java.lang.reflect.AccessibleObject::canAccess could share access cache with internal method checkAccess. In particular since one might use this new method in scenarios like: Method method = ...; if (method.canAccess(target)) { method.invoke(target, ...); } else { ... Here's what you could do: http://cr.openjdk.java.net/~plevart/jdk9-jake/AccessibleObject.canAccess_caching/webrev.01/ Regards, Peter From Alan.Bateman at oracle.com Fri Feb 10 12:04:14 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 10 Feb 2017 12:04:14 +0000 Subject: "OpenJDK specific" attribute specifications In-Reply-To: References: Message-ID: <1cd05d4f-b62d-d187-46d7-dedf94f1c9a7@oracle.com> On 10/02/2017 07:24, Ess Kay wrote: > Thanks Alan. I am not 100% sure what you mean when you say that the > ModuleHashes and ModuleResolution attributes are "JDK-specific". Are > you saying that they may appear in Java 9 class files but it is > assumed that they will only be used only by Java compilers as opposed > to the JVM? You won't find the attributes defined in the JVMS and so no guarantee that other implementations of Java SE will support them. As regards whether you will encounter class files with these attributes then you might. The `jar` tool supports an option to record the hashes of modules. It's less likely that you will encounter the ModuleResolution attribute but the the `jar` tool does have the `--warn-if-resolved` option that adds this attribute for modules that are incubating or on death row. More on this in JEP 11 [1]. -Alan [1] http://openjdk.java.net/jeps/11 From Alan.Bateman at oracle.com Fri Feb 10 13:49:53 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 10 Feb 2017 13:49:53 +0000 Subject: 8173393: Module system implementation refresh (2/2017) In-Reply-To: <88645880-d2fb-9c46-dfae-637047f370a3@gmail.com> References: <7e9e42b7-7579-1a0d-cf75-d740cf0c3b4c@oracle.com> <88645880-d2fb-9c46-dfae-637047f370a3@gmail.com> Message-ID: On 10/02/2017 10:00, Peter Levart wrote: > > First, just a nit... > > java.lang.module.Resolver: > > 320 private void addFoundModule(ModuleReference mref) { > 321 ModuleDescriptor descriptor = mref.descriptor(); > 322 nameToReference.put(descriptor.name(), mref); > 323 > 324 if (descriptor.osName().isPresent() > 325 || descriptor.osArch().isPresent() > 326 || descriptor.osVersion().isPresent()) > 327 checkTargetConstraints(descriptor); > 328 } > > ...perhaps more correct would be to reverse the order: 1st check > target constraints and then add descriptor to map. Otherwise in case > of check failure, you end up with a Resolver instance that is poisoned > with incompatible module descriptor. Maybe you always throw away such > Resolver if this method fails, but maybe someone will sometime try to > recover and continue to use the Resolver for rest of modules? Yes, fair point, it would be better to do this check first. I don't think we have any issue now because this is an internal class and the resolver is always thrown away after an exception. The ModuleTarget attribute isn't completely firmed up yet so I expect we will be back to this code soon. > > > ...then something more involving... > > java.lang.reflect.AccessibleObject::canAccess could share access cache > with internal method checkAccess. In particular since one might use > this new method in scenarios like: > > Method method = ...; > > if (method.canAccess(target)) { > method.invoke(target, ...); > } else { or the other usage I would expect to see is: if (method.canAccess(target) || method.tryAccessible()) { .. } > ... > > Here's what you could do: > > http://cr.openjdk.java.net/~plevart/jdk9-jake/AccessibleObject.canAccess_caching/webrev.01/ > Good idea. Do you want to create an issue for this and follow-up on core-libs-dev? The changes are in jdk9/dev now so it can follow. A minor nit is that the InternalError was useful to catch bad changes, a NPE could work too but it should never happen. -Alan From james.connors at oracle.com Fri Feb 10 15:49:38 2017 From: james.connors at oracle.com (Jim Connors) Date: Fri, 10 Feb 2017 10:49:38 -0500 Subject: jlink RuntimeException: descriptor returns inconsistent package set In-Reply-To: <675217c7-396d-f45e-bdf8-a1cab84abe13@oracle.com> References: <0ee41ff8-6682-fe7c-7ecc-315f430c8a09@oracle.com> <0a60f45d-1503-11f9-226f-a6fef296fc85@oracle.com> <19720521-df58-fe05-7864-b8ed6556fa69@oracle.com> <675217c7-396d-f45e-bdf8-a1cab84abe13@oracle.com> Message-ID: <1f97706f-6876-ceff-ba07-37fb1e940bf3@oracle.com> On 2/10/2017 2:05 AM, Alan Bateman wrote: > I think I need to see the JAR file to explain this. My guess is that > it has the ModulePackages class file attribute with the non-exported > packages rather than all packages (the ModulePackages changed a while > back to include all packages). I can't be sure of course but we do > need to improve the error message from jlink when it finds the > mismatch with the JAR file contents. > In addition to sending you the jar files on the side, I went ahead and extracted the contents of the jar files to a directory. It is organized as follows: com.jtconnors.socket/ module-info.class com/ jtconnors/ socket/ class files test/ class files scoreboard/ module-info.class scoreboard/ common/ fx2/ images/ util/ ... In this scenario, the same error appears: C:\tmp\scratch>jlink --module-path .;\Users\jtconnor\jdk-9\jmods --add-modules scoreboard --output reducedImage --compress=2 --strip-debug Error: java.lang.RuntimeException: Module scoreboard's descriptor returns inconsistent package set -- Jim C From Alan.Bateman at oracle.com Fri Feb 10 16:10:57 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 10 Feb 2017 16:10:57 +0000 Subject: jlink RuntimeException: descriptor returns inconsistent package set In-Reply-To: <19720521-df58-fe05-7864-b8ed6556fa69@oracle.com> References: <0ee41ff8-6682-fe7c-7ecc-315f430c8a09@oracle.com> <0a60f45d-1503-11f9-226f-a6fef296fc85@oracle.com> <19720521-df58-fe05-7864-b8ed6556fa69@oracle.com> Message-ID: <56e1f400-fe3a-c46e-ddf1-f1e8d10d3e88@oracle.com> On 10/02/2017 01:47, Jim Connors wrote: > : > > Is a JDK9 version of jar required to build the JAR file? If so, then > I wonder why the example I furnished, with com.jtconnors.socket, > worked? It was built the same way. > Can you re-create the JAR file for scoreboard with JDK 9's jar tool as a workaround for now? The reason you don't see the issue with com.jtconnors.socket is that it doesn't have any concealed packages and that is where jlink is tripping up. -Alan From mandy.chung at oracle.com Fri Feb 10 16:18:16 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 10 Feb 2017 08:18:16 -0800 Subject: Review Request: JDK-8174739: Rename JMOD section name for native libraries from native to lib Message-ID: <2ACA865A-FCA5-4361-A3C8-2DED13F78651@oracle.com> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8174739/webrev.00/ This renames the JMOD section name from `native` to `lib` that would map closely to the directory in the run-time image (with the exception on windows DLLs that go to image/bin directory). jlink defines a scheme to name a non-java resource entry in each module for plugins to lookup/add/remove from the modules: /$MODULE/$JMOD_SECTION/ jlink will write such entry to image// according to the jmod section: conf -> image/conf bin -> image/bin man -> image/man include -> image/include native -> image/lib with the exception on windows DLLs goes to image/bin For example --exclude-files plugin uses this naming scheme to specify the files/patterns in non-classes JMOD section and this change would make it more intuitive what to specify. Mandy From james.connors at oracle.com Fri Feb 10 16:21:01 2017 From: james.connors at oracle.com (Jim Connors) Date: Fri, 10 Feb 2017 11:21:01 -0500 Subject: jlink RuntimeException: descriptor returns inconsistent package set In-Reply-To: <56e1f400-fe3a-c46e-ddf1-f1e8d10d3e88@oracle.com> References: <0ee41ff8-6682-fe7c-7ecc-315f430c8a09@oracle.com> <0a60f45d-1503-11f9-226f-a6fef296fc85@oracle.com> <19720521-df58-fe05-7864-b8ed6556fa69@oracle.com> <56e1f400-fe3a-c46e-ddf1-f1e8d10d3e88@oracle.com> Message-ID: >> >> > Can you re-create the JAR file for scoreboard with JDK 9's jar tool as > a workaround for now? The reason you don't see the issue with > com.jtconnors.socket is that it doesn't have any concealed packages > and that is where jlink is tripping up. > > -Alan Jim Clarke, cc:ed on these emails just did exactly that and didn't have any success with his attempt. I will also try the same thing. -- Jim C From Alan.Bateman at oracle.com Fri Feb 10 16:24:04 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 10 Feb 2017 16:24:04 +0000 Subject: Review Request: JDK-8174739: Rename JMOD section name for native libraries from native to lib In-Reply-To: <2ACA865A-FCA5-4361-A3C8-2DED13F78651@oracle.com> References: <2ACA865A-FCA5-4361-A3C8-2DED13F78651@oracle.com> Message-ID: <5ff75b82-5dc8-898f-d73d-67a128cd7257@oracle.com> On 10/02/2017 16:18, Mandy Chung wrote: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8174739/webrev.00/ > > This renames the JMOD section name from `native` to `lib` that would > map closely to the directory in the run-time image (with the exception > on windows DLLs that go to image/bin directory). > > This looks okay. -Alan From peter.levart at gmail.com Fri Feb 10 16:38:59 2017 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 10 Feb 2017 17:38:59 +0100 Subject: 8173393: Module system implementation refresh (2/2017) In-Reply-To: References: <7e9e42b7-7579-1a0d-cf75-d740cf0c3b4c@oracle.com> <88645880-d2fb-9c46-dfae-637047f370a3@gmail.com> Message-ID: <79a3a721-64e1-e526-1e51-9dc4b897c0a9@gmail.com> On 02/10/2017 02:49 PM, Alan Bateman wrote: >> Here's what you could do: >> >> http://cr.openjdk.java.net/~plevart/jdk9-jake/AccessibleObject.canAccess_caching/webrev.01/ >> > Good idea. Do you want to create an issue for this and follow-up on > core-libs-dev? The changes are in jdk9/dev now so it can follow. A > minor nit is that the InternalError was useful to catch bad changes, a > NPE could work too but it should never happen. > > -Alan Ok, will create an issue and a follow-up change. Regards, Peter From Alan.Bateman at oracle.com Fri Feb 10 17:01:10 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 10 Feb 2017 17:01:10 +0000 Subject: jlink RuntimeException: descriptor returns inconsistent package set In-Reply-To: References: <0ee41ff8-6682-fe7c-7ecc-315f430c8a09@oracle.com> <0a60f45d-1503-11f9-226f-a6fef296fc85@oracle.com> <19720521-df58-fe05-7864-b8ed6556fa69@oracle.com> <56e1f400-fe3a-c46e-ddf1-f1e8d10d3e88@oracle.com> Message-ID: <39ccc003-bdd4-a71b-b4de-6b7858cf2ac7@oracle.com> On 10/02/2017 16:21, Jim Connors wrote: > > Jim Clarke, cc:ed on these emails just did exactly that and didn't > have any success with his attempt. I will also try the same thing. > I'm confident it should work if you use the JDK 9 `jar` tool. We'll get the jlink bug fixed in the mean-time. -Alan From james.connors at oracle.com Fri Feb 10 17:03:09 2017 From: james.connors at oracle.com (Jim Connors) Date: Fri, 10 Feb 2017 12:03:09 -0500 Subject: jlink RuntimeException: descriptor returns inconsistent package set In-Reply-To: References: <0ee41ff8-6682-fe7c-7ecc-315f430c8a09@oracle.com> <0a60f45d-1503-11f9-226f-a6fef296fc85@oracle.com> <19720521-df58-fe05-7864-b8ed6556fa69@oracle.com> <56e1f400-fe3a-c46e-ddf1-f1e8d10d3e88@oracle.com> Message-ID: <4e56d520-895b-b37f-2d94-8a66c0ec08c8@oracle.com> On 2/10/2017 11:21 AM, Jim Connors wrote: > >> Can you re-create the JAR file for scoreboard with JDK 9's jar tool >> as a workaround for now? The reason you don't see the issue with >> com.jtconnors.socket is that it doesn't have any concealed packages >> and that is where jlink is tripping up. >> >> -Alan > > Jim Clarke, cc:ed on these emails just did exactly that and didn't > have any success with his attempt. I will also try the same thing. > > -- Jim C > OK, here's the moral of the story: Use the jdk9 jar utility. This works: C:\tmp\scratch>jar --create --file scoreboard.jar --main-class scoreboard.fx2.Main --module-version 1.0 -C scoreboard . C:\tmp\scratch>jlink --module-path .;\Users\jtconnor\jdk-9\jmods --add-modules scoreboard --output reducedImage --compress=2 --strip-debug One interesting thing though. jdeps on the scoreboard.jar file yields this: C:\tmp\scratch>jdeps -s --module-path . scoreboard.jar scoreboard -> com.jtconnors.socket scoreboard -> java.base scoreboard -> java.logging scoreboard -> java.xml scoreboard -> javafx.base scoreboard -> javafx.controls scoreboard -> javafx.graphics scoreboard -> javafx.media Whereas the jlink image includes additional modules: C:\tmp\scratch>reducedImage\bin\java.exe --list-modules com.jtconnors.socket java.base at 9-ea -> java.datatransfer at 9-ea -> java.desktop at 9-ea java.logging at 9-ea -> java.prefs at 9-ea java.xml at 9-ea javafx.base at 9-ea javafx.controls at 9-ea javafx.graphics at 9-ea javafx.media at 9-ea -> jdk.jsobject at 9-ea scoreboard at 1.0 From Alan.Bateman at oracle.com Fri Feb 10 17:43:57 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 10 Feb 2017 17:43:57 +0000 Subject: jlink RuntimeException: descriptor returns inconsistent package set In-Reply-To: <4e56d520-895b-b37f-2d94-8a66c0ec08c8@oracle.com> References: <0ee41ff8-6682-fe7c-7ecc-315f430c8a09@oracle.com> <0a60f45d-1503-11f9-226f-a6fef296fc85@oracle.com> <19720521-df58-fe05-7864-b8ed6556fa69@oracle.com> <56e1f400-fe3a-c46e-ddf1-f1e8d10d3e88@oracle.com> <4e56d520-895b-b37f-2d94-8a66c0ec08c8@oracle.com> Message-ID: On 10/02/2017 17:03, Jim Connors wrote: > One interesting thing though. jdeps on the scoreboard.jar file yields > this: > > C:\tmp\scratch>jdeps -s --module-path . scoreboard.jar > scoreboard -> com.jtconnors.socket > scoreboard -> java.base > scoreboard -> java.logging > scoreboard -> java.xml > scoreboard -> javafx.base > scoreboard -> javafx.controls > scoreboard -> javafx.graphics > scoreboard -> javafx.media > > Whereas the jlink image includes additional modules: > > C:\tmp\scratch>reducedImage\bin\java.exe --list-modules > com.jtconnors.socket > java.base at 9-ea > -> java.datatransfer at 9-ea > -> java.desktop at 9-ea > java.logging at 9-ea > -> java.prefs at 9-ea > java.xml at 9-ea > javafx.base at 9-ea > javafx.controls at 9-ea > javafx.graphics at 9-ea > javafx.media at 9-ea > -> jdk.jsobject at 9-ea > scoreboard at 1.0 Can you add -R (or -recursive) to the jdeps command? That should reveal that javafx.graphics requires java.desktop and jdk.jsobject. -Alan From james.connors at oracle.com Fri Feb 10 17:49:14 2017 From: james.connors at oracle.com (Jim Connors) Date: Fri, 10 Feb 2017 12:49:14 -0500 Subject: jlink RuntimeException: descriptor returns inconsistent package set In-Reply-To: References: <0ee41ff8-6682-fe7c-7ecc-315f430c8a09@oracle.com> <0a60f45d-1503-11f9-226f-a6fef296fc85@oracle.com> <19720521-df58-fe05-7864-b8ed6556fa69@oracle.com> <56e1f400-fe3a-c46e-ddf1-f1e8d10d3e88@oracle.com> <4e56d520-895b-b37f-2d94-8a66c0ec08c8@oracle.com> Message-ID: On 2/10/2017 12:43 PM, Alan Bateman wrote: > Can you add -R (or -recursive) to the jdeps command? That should > reveal that javafx.graphics requires java.desktop and jdk.jsobject. > > -Alan Like this? Still not there. C:\tmp\scratch>jdeps -R -s --module-path . scoreboard.jar com.jtconnors.socket -> java.base com.jtconnors.socket -> java.logging scoreboard -> com.jtconnors.socket scoreboard -> java.base scoreboard -> java.logging scoreboard -> java.xml scoreboard -> javafx.base scoreboard -> javafx.controls scoreboard -> javafx.graphics scoreboard -> javafx.media From james.connors at oracle.com Fri Feb 10 17:55:40 2017 From: james.connors at oracle.com (Jim Connors) Date: Fri, 10 Feb 2017 12:55:40 -0500 Subject: jlink RuntimeException: descriptor returns inconsistent package set In-Reply-To: References: <0ee41ff8-6682-fe7c-7ecc-315f430c8a09@oracle.com> <0a60f45d-1503-11f9-226f-a6fef296fc85@oracle.com> <19720521-df58-fe05-7864-b8ed6556fa69@oracle.com> <56e1f400-fe3a-c46e-ddf1-f1e8d10d3e88@oracle.com> <4e56d520-895b-b37f-2d94-8a66c0ec08c8@oracle.com> Message-ID: <3c2ee717-dfc6-d9ef-cf6d-6b572fc42d9a@oracle.com> OK, it shows up without the '-s' option. Not sure if that's intentional. Anyway I've taken enough of your time. Thanks for all the help. C:\tmp\scratch>jdeps -R --module-path . scoreboard.jar ... scoreboard [file:///C:/tmp/scratch/./scoreboard.jar] requires com.jtconnors.socket requires java.base (@9-ea) requires java.datatransfer (@9-ea) requires java.desktop (@9-ea) requires java.logging (@9-ea) requires java.prefs (@9-ea) requires java.xml (@9-ea) requires javafx.base (@9-ea) requires javafx.controls (@9-ea) requires javafx.graphics (@9-ea) requires javafx.media (@9-ea) requires jdk.jsobject (@9-ea) scoreboard -> com.jtconnors.socket scoreboard -> java.base scoreboard -> java.logging scoreboard -> java.xml scoreboard -> javafx.base scoreboard -> javafx.controls scoreboard -> javafx.graphics scoreboard -> javafx.media ... On 2/10/2017 12:49 PM, Jim Connors wrote: > On 2/10/2017 12:43 PM, Alan Bateman wrote: >> Can you add -R (or -recursive) to the jdeps command? That should >> reveal that javafx.graphics requires java.desktop and jdk.jsobject. >> >> -Alan > > Like this? Still not there. > > C:\tmp\scratch>jdeps -R -s --module-path . scoreboard.jar > com.jtconnors.socket -> java.base > com.jtconnors.socket -> java.logging > scoreboard -> com.jtconnors.socket > scoreboard -> java.base > scoreboard -> java.logging > scoreboard -> java.xml > scoreboard -> javafx.base > scoreboard -> javafx.controls > scoreboard -> javafx.graphics > scoreboard -> javafx.media > From mandy.chung at oracle.com Fri Feb 10 17:59:21 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 10 Feb 2017 09:59:21 -0800 Subject: jlink RuntimeException: descriptor returns inconsistent package set In-Reply-To: <3c2ee717-dfc6-d9ef-cf6d-6b572fc42d9a@oracle.com> References: <0ee41ff8-6682-fe7c-7ecc-315f430c8a09@oracle.com> <0a60f45d-1503-11f9-226f-a6fef296fc85@oracle.com> <19720521-df58-fe05-7864-b8ed6556fa69@oracle.com> <56e1f400-fe3a-c46e-ddf1-f1e8d10d3e88@oracle.com> <4e56d520-895b-b37f-2d94-8a66c0ec08c8@oracle.com> <3c2ee717-dfc6-d9ef-cf6d-6b572fc42d9a@oracle.com> Message-ID: <6D599673-67F1-412C-928B-A4FE264CA777@oracle.com> > On Feb 10, 2017, at 9:55 AM, Jim Connors wrote: > > OK, it shows up without the '-s' option. Not sure if that's intentional. Anyway I've taken enough of your time. Thanks for all the help. > I?ll file a bug to follow up jdeps -R -s. Mandy > C:\tmp\scratch>jdeps -R --module-path . scoreboard.jar > ... > scoreboard > [file:///C:/tmp/scratch/./scoreboard.jar] > requires com.jtconnors.socket > requires java.base (@9-ea) > requires java.datatransfer (@9-ea) > requires java.desktop (@9-ea) > requires java.logging (@9-ea) > requires java.prefs (@9-ea) > requires java.xml (@9-ea) > requires javafx.base (@9-ea) > requires javafx.controls (@9-ea) > requires javafx.graphics (@9-ea) > requires javafx.media (@9-ea) > requires jdk.jsobject (@9-ea) > scoreboard -> com.jtconnors.socket > scoreboard -> java.base > scoreboard -> java.logging > scoreboard -> java.xml > scoreboard -> javafx.base > scoreboard -> javafx.controls > scoreboard -> javafx.graphics > scoreboard -> javafx.media > ... > > > > On 2/10/2017 12:49 PM, Jim Connors wrote: >> On 2/10/2017 12:43 PM, Alan Bateman wrote: >>> Can you add -R (or -recursive) to the jdeps command? That should reveal that javafx.graphics requires java.desktop and jdk.jsobject. >>> >>> -Alan >> >> Like this? Still not there. >> >> C:\tmp\scratch>jdeps -R -s --module-path . scoreboard.jar >> com.jtconnors.socket -> java.base >> com.jtconnors.socket -> java.logging >> scoreboard -> com.jtconnors.socket >> scoreboard -> java.base >> scoreboard -> java.logging >> scoreboard -> java.xml >> scoreboard -> javafx.base >> scoreboard -> javafx.controls >> scoreboard -> javafx.graphics >> scoreboard -> javafx.media >> > From mandy.chung at oracle.com Fri Feb 10 22:25:42 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 10 Feb 2017 14:25:42 -0800 Subject: Review Request: JDK-8174740: RuntimeException: Module m's descriptor returns inconsistent package set Message-ID: <96323E3E-1603-4DFE-B994-3EC486D56AAD@oracle.com> Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8174740/webrev.00/ jlink system modules plugin incorrectly assumes that ModuleDescriptor::packages returns an empty set if the ModulePackages attribute is not present and no packageFinder supplier is provided. That?s not the case when the module descriptor contains exports/open packages. This fixes how the plugin determines if ModulePackages attribute is present. Mandy [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-February/011268.html From gunnar at hibernate.org Fri Feb 10 23:06:40 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Sat, 11 Feb 2017 00:06:40 +0100 Subject: Compiling classes for multi-release JAR with module-info.java Message-ID: Hi, I'm trying to figure the intended process for compiling different versions of a class for a multi-release (MR) JAR if there is a module descriptor present. I have these classes: --- src/main/java/com/example/Version.java package com.example; public class Version { private String value; String getValue() { return value; } public Version(String value) { this.value = value; } } --- --- src/main/java/com/example/A.java package com.example; public class A { public Version getVersion() { return new Version( "Java 8" ); } } --- --- src/main/java9/com/example/A.java package com.example; public class A { public Version getVersion() { return new Version( "Java 9" ); } } --- I.e. "Version" is common to all Java versions supported by the MR JAR, whereas there is one variant of "A" for Java 8 and one for Java 9. If I don't have a module descriptor things work fine: javac --source-path=src/main/java -d target/classes --release 8 $(find src/main/java -name "*.java") javac --source-path=src/main/java9 -cp target/classes -d target/classes-java9 --release 9 $(find src/main/java9 -name "*.java") jar --create --file mr.jar -C target/classes . --release 9 -C target/classes-java9 . Specifically, the second javac call picks up the (shared) class file for "Version" from the classpath by pointing to the output directory of the first compilation. Things fail when adding a module descriptor: --- src/main/java9/module-info.java module com.example { } --- Now the second javac call fails: src/main/java9/com/example/A.java:4: error: cannot find symbol public Version getVersion() { return new Version( "Java 9" ); } ^ symbol: class Version location: class A It seems as if the presence of module-info.java suppresses the configured classpath. Reading JEP 261 [1] I assumed this should be supported: "It is possible to put arbitrary classes and JAR files on the class path in [Single-module mode]", which I think is what I have here. Am I running into a bug? Or am I on the wrong track here and creating such MR JAR should be done differently? If so, how should classes that are meant to go into META-INF/versions/9 be compiled without re-compiling all the shared classes? Thanks for any pointers, --Gunnar [1] http://openjdk.java.net/jeps/261 From Alan.Bateman at oracle.com Sat Feb 11 17:40:26 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 11 Feb 2017 17:40:26 +0000 Subject: Compiling classes for multi-release JAR with module-info.java In-Reply-To: References: Message-ID: On 10/02/2017 23:06, Gunnar Morling wrote: > : > > If I don't have a module descriptor things work fine: > > javac --source-path=src/main/java -d target/classes --release 8 > $(find src/main/java -name "*.java") > javac --source-path=src/main/java9 -cp target/classes -d > target/classes-java9 --release 9 $(find src/main/java9 -name "*.java") > jar --create --file mr.jar -C target/classes . --release 9 -C > target/classes-java9 . > > Specifically, the second javac call picks up the (shared) class file > for "Version" from the classpath by pointing to the output directory > of the first compilation. > > Things fail when adding a module descriptor: > > --- src/main/java9/module-info.java > module com.example { > } > --- It is complicated but I think the reason you are running into issues is because the second javac command is essentially compiling a module with references to types on the class path. If you move the module-info.java to the top-level directory directory then I would expect this should work: javac --release 8 -d target/classes src/main/java/com/example/A.java src/main/java/com/example/Version.java javac -d target/classes src/main/java/module-info.java javac -d target/classes-java9 -cp target/classes src/main/java9/com/example/A.java jar --create --file mr.jar -C target/classes . --release 9 -C target/classes-java9 . Jon might have other suggestions. -Alan From paul.sandoz at oracle.com Sun Feb 12 02:09:33 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Sat, 11 Feb 2017 18:09:33 -0800 Subject: Compiling classes for multi-release JAR with module-info.java In-Reply-To: References: Message-ID: It?s also possible to do this: javac --source-path=src/main/java9 --source-path=src/main/java -implicit:none -d target/classes-java9 --release 9 $(find src/main/java9 -name "*.java?) but that approach is fragile (it assumes the implicitly referenced source can be processed for release 8 and 9). Separately compiling the module descriptor source is likely a better approach. Paul. > On 11 Feb 2017, at 09:40, Alan Bateman wrote: > > On 10/02/2017 23:06, Gunnar Morling wrote: > >> : >> >> If I don't have a module descriptor things work fine: >> >> javac --source-path=src/main/java -d target/classes --release 8 >> $(find src/main/java -name "*.java") >> javac --source-path=src/main/java9 -cp target/classes -d >> target/classes-java9 --release 9 $(find src/main/java9 -name "*.java") >> jar --create --file mr.jar -C target/classes . --release 9 -C >> target/classes-java9 . >> >> Specifically, the second javac call picks up the (shared) class file >> for "Version" from the classpath by pointing to the output directory >> of the first compilation. >> >> Things fail when adding a module descriptor: >> >> --- src/main/java9/module-info.java >> module com.example { >> } >> --- > It is complicated but I think the reason you are running into issues is because the second javac command is essentially compiling a module with references to types on the class path. > > If you move the module-info.java to the top-level directory directory then I would expect this should work: > > javac --release 8 -d target/classes src/main/java/com/example/A.java src/main/java/com/example/Version.java > javac -d target/classes src/main/java/module-info.java > javac -d target/classes-java9 -cp target/classes src/main/java9/com/example/A.java > jar --create --file mr.jar -C target/classes . --release 9 -C target/classes-java9 . > > Jon might have other suggestions. > > -Alan From alexjecan88 at yahoo.com Sun Feb 12 13:29:13 2017 From: alexjecan88 at yahoo.com (Alexandru Jecan) Date: Sun, 12 Feb 2017 14:29:13 +0100 Subject: JAR searched on the classpath instead of the module path in Build #156 Message-ID: <000001d28534$01524c50$03f6e4f0$@yahoo.com> Hello Jigsaw team, I have the following problem in Jigsaw build #156: I moved the hibernate-core.jar to automatic modules by putting it on the module path. I also have a classpath that does not contain this JAR. In my module-info.java I require it using ?requires hibernate.core?. I compile my application, create the modular JAR and then at runtime I get the error: Caused by: org.hibernate.boot.jaxb.internal.stax.XmlInfrastructureException: Unable to locate schema [org/hibernate/jpa/orm_2_0.xsd] via classpath Could you please tell me, why does it search for the JAR on the classpath since I moved the JAR to automatic modules ? I have run using the ?classpath and the ?module-path options at the same time. After that I took an older Jigsaw build (#141 and also #142). I performed exactly the same steps and it works perfectly. The error from above is not displayed any more. I was wondering what has been changed in these 3 months between build #141 and build#156 so that now it tries to search for the JAR on the classpath instead of the module path. Has the name changed? Or it is something else that I am missing? Thank you! Best regards Alexandru Jecan From Alan.Bateman at oracle.com Sun Feb 12 15:33:37 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 12 Feb 2017 15:33:37 +0000 Subject: JAR searched on the classpath instead of the module path in Build #156 In-Reply-To: <000001d28534$01524c50$03f6e4f0$@yahoo.com> References: <000001d28534$01524c50$03f6e4f0$@yahoo.com> Message-ID: <404865d4-a933-dd9e-1869-a326b825a4a6@oracle.com> On 12/02/2017 13:29, Alexandru Jecan wrote: > : > > > > I compile my application, create the modular JAR and then at runtime I get the error: > > Caused by: org.hibernate.boot.jaxb.internal.stax.XmlInfrastructureException: Unable to locate schema [org/hibernate/jpa/orm_2_0.xsd] via classpath > > > > Could you please tell me, why does it search for the JAR on the classpath since I moved the JAR to automatic modules ? > > I have run using the ?classpath and the ?module-path options at the same time. > > > > After that I took an older Jigsaw build (#141 and also #142). > > I performed exactly the same steps and it works perfectly. The error from above is not displayed any more. There are >1500 changes in builds 143-156. Is there any way that you can bisect this and track down the first build where you see a problem? The exception hints of something involving JAXB and a XML schema file. You don't say if you are using the java.xml.bind module or the standalone JAXB on the class path. In this area, I note that there was a big refresh of JAXB from the upstream Metro project in jdk-9+146. In addition, there was a change to the Xalan serializer in jdk-9+150 that have brought several regressions and bug reports, the fixes for all issues aren't in JDK 9 yet. So anything to narrow this down would be good. -Alan From Alan.Bateman at oracle.com Sun Feb 12 16:31:06 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 12 Feb 2017 16:31:06 +0000 Subject: Review Request: JDK-8174740: RuntimeException: Module m's descriptor returns inconsistent package set In-Reply-To: <96323E3E-1603-4DFE-B994-3EC486D56AAD@oracle.com> References: <96323E3E-1603-4DFE-B994-3EC486D56AAD@oracle.com> Message-ID: <886e8f52-1642-535e-d519-54e2ac38df2f@oracle.com> On 10/02/2017 22:25, Mandy Chung wrote: > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8174740/webrev.00/ > > jlink system modules plugin incorrectly assumes that ModuleDescriptor::packages returns an empty set if the ModulePackages attribute is not present and no packageFinder supplier is provided. That?s not the case when the module descriptor contains exports/open packages. This fixes how the plugin determines if ModulePackages attribute is present. > This looks okay to me. -Alan From alan.bateman at oracle.com Mon Feb 13 09:29:12 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 13 Feb 2017 09:29:12 +0000 Subject: hg: jigsaw/jake/nashorn: 3 new changesets Message-ID: <201702130929.v1D9TCNn002189@aojmv0008.oracle.com> Changeset: c84e9bd100e9 Author: alanb Date: 2017-02-10 09:06 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/c84e9bd100e9 8173393: Module system implementation refresh (2/2017) Reviewed-by: mchung, alanb Contributed-by: alan.bateman at oracle.com, mandy.chung at oracle.com ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptLoader.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/StructureLoader.java Changeset: f6070efba6af Author: mli Date: 2017-02-12 18:37 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/f6070efba6af 8174699: Fix @since in module-info.java in dev/nashorn repo Reviewed-by: jlaskey ! src/jdk.dynalink/share/classes/module-info.java ! src/jdk.scripting.nashorn.shell/share/classes/module-info.java ! src/jdk.scripting.nashorn/share/classes/module-info.java Changeset: 8359795fdbb5 Author: alanb Date: 2017-02-13 08:13 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/8359795fdbb5 Merge ! src/jdk.scripting.nashorn.shell/share/classes/module-info.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptLoader.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/StructureLoader.java ! src/jdk.scripting.nashorn/share/classes/module-info.java From alan.bateman at oracle.com Mon Feb 13 09:29:12 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 13 Feb 2017 09:29:12 +0000 Subject: hg: jigsaw/jake/jaxws: 4 new changesets Message-ID: <201702130929.v1D9TC81002184@aojmv0008.oracle.com> Changeset: 42993fcbd8f3 Author: lancea Date: 2017-02-07 15:46 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/42993fcbd8f3 8057795: Update of the mimestypes.default for JAF Reviewed-by: bpb ! src/java.activation/share/classes/META-INF/mimetypes.default Changeset: 487620ebb019 Author: lana Date: 2017-02-09 18:10 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/487620ebb019 Merge Changeset: b7e70e1e0154 Author: mli Date: 2017-02-10 00:39 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/b7e70e1e0154 8174697: Fix @since in module-info.java in dev/jaxws repo Reviewed-by: alanb ! src/java.activation/share/classes/module-info.java ! src/java.xml.bind/share/classes/module-info.java ! src/java.xml.ws.annotation/share/classes/module-info.java ! src/java.xml.ws/share/classes/module-info.java Changeset: a84ace0198c8 Author: alanb Date: 2017-02-13 08:14 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/a84ace0198c8 Merge ! src/java.activation/share/classes/module-info.java ! src/java.xml.bind/share/classes/module-info.java ! src/java.xml.ws.annotation/share/classes/module-info.java ! src/java.xml.ws/share/classes/module-info.java From alan.bateman at oracle.com Mon Feb 13 09:29:13 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 13 Feb 2017 09:29:13 +0000 Subject: hg: jigsaw/jake/jaxp: 6 new changesets Message-ID: <201702130929.v1D9TDRK002192@aojmv0008.oracle.com> Changeset: e372795e1b7c Author: fyuan Date: 2017-02-09 16:47 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/e372795e1b7c 8173290: 3% regression in SPECjvm2008-XML with b150 Reviewed-by: joehw ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/ToHTMLStream.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/ToStream.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/ToXMLStream.java Changeset: 98998dfe5208 Author: lana Date: 2017-02-09 18:09 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/98998dfe5208 Merge Changeset: 7990ced86ca4 Author: mli Date: 2017-02-10 00:37 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/7990ced86ca4 8174696: Fix @since in module-info.java in dev/jaxp repo Reviewed-by: alanb ! src/java.xml/share/classes/module-info.java Changeset: 42c30d817faa Author: alanb Date: 2017-02-10 09:04 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/42c30d817faa 8173393: Module system implementation refresh (2/2017) Reviewed-by: mchung, alanb Contributed-by: alan.bateman at oracle.com, mandy.chung at oracle.com ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java ! test/javax/xml/jaxp/module/ServiceProviderTest/LayerModularXMLParserTest.java Changeset: 412df235a8a2 Author: alanb Date: 2017-02-10 12:28 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/412df235a8a2 Merge Changeset: c063339ee984 Author: alanb Date: 2017-02-13 08:14 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/c063339ee984 Merge ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java ! src/java.xml/share/classes/module-info.java ! test/javax/xml/jaxp/module/ServiceProviderTest/LayerModularXMLParserTest.java From alan.bateman at oracle.com Mon Feb 13 09:29:11 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 13 Feb 2017 09:29:11 +0000 Subject: hg: jigsaw/jake/corba: 4 new changesets Message-ID: <201702130929.v1D9TBcN002178@aojmv0008.oracle.com> Changeset: 9eada61b403d Author: msheppar Date: 2017-02-09 15:52 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/9eada61b403d 8049375: Extend how the org.omg.CORBA.ORB handles the search for orb.properties Reviewed-by: lancea, alanb ! src/java.corba/share/classes/org/omg/CORBA/ORB.java Changeset: fee432a1b886 Author: lana Date: 2017-02-09 18:09 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/fee432a1b886 Merge Changeset: 9383da04b385 Author: mli Date: 2017-02-10 00:33 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/9383da04b385 8174698: Fix @since in module-info.java in dev/corba repo Reviewed-by: alanb ! src/java.corba/share/classes/module-info.java Changeset: 10dc5a3e2fad Author: alanb Date: 2017-02-13 08:20 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/10dc5a3e2fad Merge ! src/java.corba/share/classes/module-info.java ! src/java.corba/share/classes/org/omg/CORBA/ORB.java From alan.bateman at oracle.com Mon Feb 13 09:29:11 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 13 Feb 2017 09:29:11 +0000 Subject: hg: jigsaw/jake: 12 new changesets Message-ID: <201702130929.v1D9TBCU002179@aojmv0008.oracle.com> Changeset: 7e095c2db6b2 Author: ihse Date: 2017-02-07 11:09 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/7e095c2db6b2 8174064: Tab expansion broken for make Reviewed-by: erikj ! make/Init.gmk Changeset: 98503c50ee77 Author: ihse Date: 2017-02-07 12:17 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/98503c50ee77 8174069: Verify that bash is at least version 3.2 Reviewed-by: erikj ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh Changeset: 6669d58b28b0 Author: erikj Date: 2017-02-09 09:51 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/6669d58b28b0 8174172: Race when building java.base.jmod Reviewed-by: alanb, mchung ! make/Main.gmk Changeset: e1d613aa8c8d Author: lana Date: 2017-02-09 18:09 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/e1d613aa8c8d Merge Changeset: e799e4e170d1 Author: jwilhelm Date: 2017-01-31 20:54 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/e799e4e170d1 Merge ! common/autoconf/generated-configure.sh ! common/bin/unshuffle_list.txt Changeset: 5327e511b68d Author: dnsimon Date: 2017-02-02 05:26 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/5327e511b68d 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied Reviewed-by: kvn, alanb, mchung, mullan ! make/common/Modules.gmk Changeset: 5c4f6b099621 Author: jwilhelm Date: 2017-02-09 23:23 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/5c4f6b099621 Merge ! common/autoconf/generated-configure.sh ! common/bin/unshuffle_list.txt ! make/common/Modules.gmk Changeset: 5308bdd50d13 Author: jwilhelm Date: 2017-02-09 23:35 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/5308bdd50d13 Merge ! common/autoconf/generated-configure.sh Changeset: 9942e3c1ffd3 Author: prr Date: 2017-02-03 09:28 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/9942e3c1ffd3 8173409: make setMixingCutoutShape public and remove jdk.desktop Reviewed-by: serb, mchung, alexsch ! make/common/Modules.gmk Changeset: 7e2e1deb2314 Author: prr Date: 2017-02-06 09:35 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/7e2e1deb2314 Merge ! make/common/Modules.gmk Changeset: 4eb77fb98952 Author: prr Date: 2017-02-10 08:21 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/4eb77fb98952 Merge ! make/common/Modules.gmk Changeset: a6fa93c0074b Author: alanb Date: 2017-02-13 08:07 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/a6fa93c0074b Merge ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh ! make/Main.gmk ! make/common/Modules.gmk From alan.bateman at oracle.com Mon Feb 13 09:29:13 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 13 Feb 2017 09:29:13 +0000 Subject: hg: jigsaw/jake/langtools: 19 new changesets Message-ID: <201702130929.v1D9TEfG002196@aojmv0008.oracle.com> Changeset: f0bc0f34d2cc Author: jjg Date: 2017-02-07 16:19 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/f0bc0f34d2cc 8174140: Move test files into package hierarchy Reviewed-by: darcy ! test/tools/javac/T4093617/T4093617.java - test/tools/javac/T4093617/java.base/Object.java + test/tools/javac/T4093617/java.base/java/lang/Object.java ! test/tools/javac/redefineObject/Object1-test.java ! test/tools/javac/redefineObject/Object2-test.java - test/tools/javac/redefineObject/java.base/Object1.java - test/tools/javac/redefineObject/java.base/Object2.java + test/tools/javac/redefineObject/java.base/java/lang/Object1.java + test/tools/javac/redefineObject/java.base/java/lang/Object2.java Changeset: 981fbff798b8 Author: ksrini Date: 2017-02-07 13:45 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/981fbff798b8 8173302: Move the Description up on module and package index page Reviewed-by: bpatel, jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageIndexWriter.java + test/jdk/javadoc/doclet/testOverview/TestOverview.java + test/jdk/javadoc/doclet/testOverview/msrc/module-info.java + test/jdk/javadoc/doclet/testOverview/msrc/p1/C.java + test/jdk/javadoc/doclet/testOverview/msrc/p2/C2.java + test/jdk/javadoc/doclet/testOverview/overview.html + test/jdk/javadoc/doclet/testOverview/src/p1/C.java + test/jdk/javadoc/doclet/testOverview/src/p2/C2.java Changeset: c80dce0bcab4 Author: vromero Date: 2017-02-08 06:43 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/c80dce0bcab4 8174027: error message should adapt to the corresponding top level element Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/T6234077.out + test/tools/javac/T8173955/MessageForClassTest.java + test/tools/javac/T8173955/MessageForClassTest.out + test/tools/javac/T8173955/MessageForEnumTest.java + test/tools/javac/T8173955/MessageForEnumTest.out + test/tools/javac/T8173955/MessageForInterfaceTest.java + test/tools/javac/T8173955/MessageForInterfaceTest.out ! test/tools/javac/modules/ModuleInfoTest.java Changeset: e8d71e4be697 Author: rfield Date: 2017-02-08 09:12 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/e8d71e4be697 8173893: JShell: reduce memory leaks Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/jdk/internal/jshell/debug/InternalDebugControl.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java ! src/jdk.jshell/share/classes/jdk/jshell/JShell.java Changeset: c9b0b57e3bd5 Author: rfield Date: 2017-02-08 10:43 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/c9b0b57e3bd5 8173845: JShell API: not patch compatible Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/jdk/jshell/JShell.java ! src/jdk.jshell/share/classes/jdk/jshell/MemoryFileManager.java ! src/jdk.jshell/share/classes/jdk/jshell/execution/JdiDefaultExecutionControl.java ! src/jdk.jshell/share/classes/jdk/jshell/execution/JdiInitiator.java + test/jdk/jshell/FileManagerTest.java ! test/jdk/jshell/MyExecutionControl.java Changeset: fc0a9318d392 Author: rfield Date: 2017-02-08 13:35 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/fc0a9318d392 8173916: jshell tool: /methods signature confusing/non-standard format 8174028: jshell tool: /method /type failed declaration listed (without indication) 8174041: jshell tool: --startup PRINTING references undeclared Locale class Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/Feedback.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java ! src/jdk.jshell/share/classes/jdk/jshell/tool/resources/PRINTING.jsh ! test/jdk/jshell/ReplToolTesting.java ! test/jdk/jshell/ToolReloadTest.java ! test/jdk/jshell/ToolSimpleTest.java Changeset: 7729c633b9f1 Author: vromero Date: 2017-02-08 19:42 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/7729c633b9f1 8174073: NPE caused by @link reference to class Reviewed-by: jjg, ksrini ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java + test/tools/javac/doclint/NPEDuplicateClassNamesTest.java Changeset: 706967704e65 Author: mcimadamore Date: 2017-02-09 15:19 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/706967704e65 8174249: Regression in generic method unchecked calls Summary: Erasure for unchecked call occurs too early after JDK-8078093 Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/generics/inference/8174249/T8174249a.java + test/tools/javac/generics/inference/8174249/T8174249b.java Changeset: f06dc0d49d68 Author: bpatel Date: 2017-02-09 08:01 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/f06dc0d49d68 8168965: search items are not listed in any sensible order Reviewed-by: jjg, ksrini Contributed-by: michel.trudeau at oracle.com ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/search.js ! test/jdk/javadoc/doclet/testSearch/TestSearch.java Changeset: 7549af75ce62 Author: lana Date: 2017-02-09 18:09 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/7549af75ce62 Merge - test/tools/javac/T4093617/java.base/Object.java - test/tools/javac/redefineObject/java.base/Object1.java - test/tools/javac/redefineObject/java.base/Object2.java Changeset: 70014b92e871 Author: rfield Date: 2017-02-09 14:37 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/70014b92e871 8174672: JShell tests: jdk/jshell/UserJdiUserRemoteTest.java problem listed with wrong bug number Reviewed-by: jjg ! test/ProblemList.txt Changeset: 37ec42288f73 Author: vromero Date: 2017-02-09 16:30 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/37ec42288f73 8169200: Gen has a reference to Flow that is not used, should be removed Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java Changeset: fbfd5e635eb2 Author: rfield Date: 2017-02-09 18:58 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/fbfd5e635eb2 8174262: Error message misspelling: "instanciated" Reviewed-by: jjg ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties ! src/jdk.jshell/share/classes/jdk/jshell/execution/Util.java ! test/jdk/jshell/ToolSimpleTest.java Changeset: 65d446c80cdf Author: alanb Date: 2017-02-10 09:06 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/65d446c80cdf 8173393: Module system implementation refresh (2/2017) Reviewed-by: mcimadamore, mchung, alanb Contributed-by: alan.bateman at oracle.com, mandy.chung at oracle.com ! make/tools/crules/MutableFieldsAnalyzer.java ! src/java.compiler/share/classes/javax/lang/model/element/Element.java ! src/java.compiler/share/classes/javax/lang/model/element/ElementKind.java ! src/java.compiler/share/classes/javax/lang/model/element/ElementVisitor.java ! src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java ! src/java.compiler/share/classes/javax/lang/model/element/PackageElement.java ! src/java.compiler/share/classes/javax/lang/model/type/TypeKind.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor6.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor9.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementFilter.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor9.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementScanner9.java ! src/java.compiler/share/classes/javax/lang/model/util/Elements.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor9.java ! src/java.compiler/share/classes/javax/tools/ForwardingJavaFileManager.java ! src/java.compiler/share/classes/javax/tools/JavaFileManager.java ! src/java.compiler/share/classes/javax/tools/StandardLocation.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Directive.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/JDK9Wrappers.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/Module_attribute.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsConfiguration.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Module.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleAnalyzer.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleExportsAnalyzer.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleInfoBuilder.java ! test/jdk/jshell/KullaTesting.java ! test/tools/javac/T8003967/DetectMutableStaticFields.java Changeset: 22c052d7a86d Author: alanb Date: 2017-02-10 12:28 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/22c052d7a86d Merge Changeset: 3e4d400638e5 Author: vromero Date: 2017-02-10 07:50 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/3e4d400638e5 8174099: class ComboTask at the combo test library needs an execute() method Reviewed-by: mcimadamore ! test/tools/javac/lib/combo/ComboTask.java Changeset: e7b7e4e436c4 Author: rfield Date: 2017-02-10 13:49 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/e7b7e4e436c4 8174762: JShell: @since tags missing Reviewed-by: jjg ! src/jdk.jshell/share/classes/jdk/jshell/DeclarationSnippet.java ! src/jdk.jshell/share/classes/jdk/jshell/Diag.java ! src/jdk.jshell/share/classes/jdk/jshell/ErroneousSnippet.java ! src/jdk.jshell/share/classes/jdk/jshell/EvalException.java ! src/jdk.jshell/share/classes/jdk/jshell/ExpressionSnippet.java ! src/jdk.jshell/share/classes/jdk/jshell/ImportSnippet.java ! src/jdk.jshell/share/classes/jdk/jshell/JShell.java ! src/jdk.jshell/share/classes/jdk/jshell/JShellException.java ! src/jdk.jshell/share/classes/jdk/jshell/MethodSnippet.java ! src/jdk.jshell/share/classes/jdk/jshell/OuterImportSnippetWrap.java ! src/jdk.jshell/share/classes/jdk/jshell/OuterSnippetsClassWrap.java ! src/jdk.jshell/share/classes/jdk/jshell/OuterWrapMap.java ! src/jdk.jshell/share/classes/jdk/jshell/PersistentSnippet.java ! src/jdk.jshell/share/classes/jdk/jshell/Snippet.java ! src/jdk.jshell/share/classes/jdk/jshell/SnippetEvent.java ! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysis.java ! src/jdk.jshell/share/classes/jdk/jshell/StatementSnippet.java ! src/jdk.jshell/share/classes/jdk/jshell/TypeDeclSnippet.java ! src/jdk.jshell/share/classes/jdk/jshell/UnresolvedReferenceException.java ! src/jdk.jshell/share/classes/jdk/jshell/VarSnippet.java ! src/jdk.jshell/share/classes/jdk/jshell/execution/DirectExecutionControl.java ! src/jdk.jshell/share/classes/jdk/jshell/execution/FailOverExecutionControlProvider.java ! src/jdk.jshell/share/classes/jdk/jshell/execution/JdiDefaultExecutionControl.java ! src/jdk.jshell/share/classes/jdk/jshell/execution/JdiExecutionControl.java ! src/jdk.jshell/share/classes/jdk/jshell/execution/JdiExecutionControlProvider.java ! src/jdk.jshell/share/classes/jdk/jshell/execution/JdiInitiator.java ! src/jdk.jshell/share/classes/jdk/jshell/execution/LoaderDelegate.java ! src/jdk.jshell/share/classes/jdk/jshell/execution/LocalExecutionControl.java ! src/jdk.jshell/share/classes/jdk/jshell/execution/LocalExecutionControlProvider.java ! src/jdk.jshell/share/classes/jdk/jshell/execution/RemoteExecutionControl.java ! src/jdk.jshell/share/classes/jdk/jshell/execution/StreamingExecutionControl.java ! src/jdk.jshell/share/classes/jdk/jshell/execution/Util.java ! src/jdk.jshell/share/classes/jdk/jshell/execution/package-info.java ! src/jdk.jshell/share/classes/jdk/jshell/package-info.java ! src/jdk.jshell/share/classes/jdk/jshell/spi/ExecutionControl.java ! src/jdk.jshell/share/classes/jdk/jshell/spi/ExecutionControlProvider.java ! src/jdk.jshell/share/classes/jdk/jshell/spi/ExecutionEnv.java ! src/jdk.jshell/share/classes/jdk/jshell/spi/SPIResolutionException.java ! src/jdk.jshell/share/classes/jdk/jshell/spi/package-info.java ! src/jdk.jshell/share/classes/jdk/jshell/tool/JavaShellToolBuilder.java ! src/jdk.jshell/share/classes/jdk/jshell/tool/package-info.java ! src/jdk.jshell/share/classes/module-info.java Changeset: f34b5b81ef55 Author: jjg Date: 2017-02-10 15:42 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/f34b5b81ef55 8174104: Compiler does not allow non-existent module path entry Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java ! test/tools/javac/diags/examples/IllegalArgumentForOption/IllegalArgumentForOption.java ! test/tools/javac/modules/ModulePathTest.java Changeset: 7cb91a17315a Author: alanb Date: 2017-02-13 08:12 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/7cb91a17315a Merge ! make/tools/crules/MutableFieldsAnalyzer.java ! src/java.compiler/share/classes/javax/lang/model/element/Element.java ! src/java.compiler/share/classes/javax/lang/model/element/ElementKind.java ! src/java.compiler/share/classes/javax/lang/model/element/ElementVisitor.java ! src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java ! src/java.compiler/share/classes/javax/lang/model/element/PackageElement.java ! src/java.compiler/share/classes/javax/lang/model/type/TypeKind.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor6.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor9.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementFilter.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor9.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementScanner9.java ! src/java.compiler/share/classes/javax/lang/model/util/Elements.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor9.java ! src/java.compiler/share/classes/javax/tools/ForwardingJavaFileManager.java ! src/java.compiler/share/classes/javax/tools/JavaFileManager.java ! src/java.compiler/share/classes/javax/tools/StandardLocation.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Directive.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/file/JavacFileManager.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/JDK9Wrappers.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageIndexWriter.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/Module_attribute.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsConfiguration.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Module.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleAnalyzer.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleExportsAnalyzer.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleInfoBuilder.java ! src/jdk.jshell/share/classes/module-info.java ! test/ProblemList.txt ! test/jdk/jshell/KullaTesting.java - test/tools/javac/T4093617/java.base/Object.java + test/tools/javac/T4093617/java.base/java/lang/Object.java ! test/tools/javac/T8003967/DetectMutableStaticFields.java ! test/tools/javac/modules/ModuleInfoTest.java ! test/tools/javac/modules/ModulePathTest.java ! test/tools/javac/redefineObject/Object1-test.java ! test/tools/javac/redefineObject/Object2-test.java - test/tools/javac/redefineObject/java.base/Object1.java - test/tools/javac/redefineObject/java.base/Object2.java + test/tools/javac/redefineObject/java.base/java/lang/Object1.java + test/tools/javac/redefineObject/java.base/java/lang/Object2.java From alan.bateman at oracle.com Mon Feb 13 09:29:17 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 13 Feb 2017 09:29:17 +0000 Subject: hg: jigsaw/jake/hotspot: 22 new changesets Message-ID: <201702130929.v1D9TIPb002250@aojmv0008.oracle.com> Changeset: 8c7769a2e1fe Author: alanb Date: 2017-02-10 09:03 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/8c7769a2e1fe 8173393: Module system implementation refresh (2/2017) Reviewed-by: lfoltan, acorn, mchung Contributed-by: alan.bateman at oracle.com, george.triantafillou at oracle.com ! src/share/vm/prims/methodHandles.cpp ! test/ProblemList.txt ! test/runtime/modules/AccessCheck/AccessExportTwice.java ! test/runtime/modules/AccessCheck/AccessReadTwice.java ! test/runtime/modules/AccessCheck/CheckRead.java ! test/runtime/modules/AccessCheck/DiffCL_CheckRead.java ! test/runtime/modules/AccessCheck/DiffCL_ExpQualOther.java ! test/runtime/modules/AccessCheck/DiffCL_ExpQualToM1.java ! test/runtime/modules/AccessCheck/DiffCL_ExpUnqual.java ! test/runtime/modules/AccessCheck/DiffCL_PkgNotExp.java ! test/runtime/modules/AccessCheck/DiffCL_Umod.java ! test/runtime/modules/AccessCheck/DiffCL_UmodUpkg.java ! test/runtime/modules/AccessCheck/ExpQualOther.java ! test/runtime/modules/AccessCheck/ExpQualToM1.java ! test/runtime/modules/AccessCheck/ExpUnqual.java ! test/runtime/modules/AccessCheck/ExportAllUnnamed.java ! test/runtime/modules/AccessCheck/PkgNotExp.java ! test/runtime/modules/AccessCheck/Umod.java ! test/runtime/modules/AccessCheck/UmodDiffCL_ExpQualOther.java ! test/runtime/modules/AccessCheck/UmodDiffCL_ExpUnqual.java ! test/runtime/modules/AccessCheck/UmodDiffCL_PkgNotExp.java ! test/runtime/modules/AccessCheck/UmodUPkg.java ! test/runtime/modules/AccessCheck/UmodUpkgDiffCL_ExpQualOther.java ! test/runtime/modules/AccessCheck/UmodUpkgDiffCL_NotExp.java ! test/runtime/modules/AccessCheck/UmodUpkg_ExpQualOther.java ! test/runtime/modules/AccessCheck/UmodUpkg_NotExp.java ! test/runtime/modules/AccessCheck/Umod_ExpQualOther.java ! test/runtime/modules/AccessCheck/Umod_ExpUnqual.java ! test/runtime/modules/AccessCheck/Umod_PkgNotExp.java ! test/runtime/modules/AccessCheck/p1/c1Loose.java ! test/runtime/modules/AccessCheck/p1/c1ReadEdge.java ! test/runtime/modules/AccessCheck/p1/c1ReadEdgeDiffLoader.java ! test/runtime/modules/AccessCheck/p3/c3ReadEdge.jcod ! test/runtime/modules/AccessCheck/p3/c3ReadEdgeDiffLoader.jcod ! test/runtime/modules/AccessCheckAllUnnamed.java ! test/runtime/modules/AccessCheckExp.java ! test/runtime/modules/AccessCheckJavaBase.java ! test/runtime/modules/AccessCheckRead.java ! test/runtime/modules/AccessCheckSuper.java ! test/runtime/modules/AccessCheckUnnamed.java ! test/runtime/modules/AccessCheckWorks.java ! test/runtime/modules/CCE_module_msg.java ! test/runtime/modules/ExportTwice.java ! test/runtime/modules/IgnoreModulePropertiesTest.java ! test/runtime/modules/JVMAddModuleExportToAllUnnamed.java ! test/runtime/modules/JVMAddModuleExportsToAll.java ! test/runtime/modules/JVMAddModulePackage.java ! test/runtime/modules/JVMDefineModule.java ! test/runtime/modules/JVMGetModuleByPkgName.java ! test/runtime/modules/ModuleHelper.java ! test/runtime/modules/ModuleOptionsTest.java ! test/runtime/modules/ModuleStress/CustomSystemClassLoader.java ! test/runtime/modules/ModuleStress/ModuleNonBuiltinCLMain.java ! test/runtime/modules/ModuleStress/ModuleSameCLMain.java ! test/runtime/modules/ModuleStress/ModuleStress.java ! test/runtime/modules/ModuleStress/src/jdk.test/test/Main.java ! test/runtime/modules/ModuleStress/src/jdk.test/test/MainGC.java ! test/runtime/modules/PatchModule/PatchModuleDupModule.java ! test/serviceability/jvmti/GetModulesInfo/JvmtiGetAllModulesTest.java Changeset: 8a7b0b443ca7 Author: tschatzl Date: 2017-01-27 13:12 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/8a7b0b443ca7 8173229: Wrong assert whether all remembered set entries have been iterated over in presence of coarsenings Summary: Remove asserts as they are almost useless. Reviewed-by: mgerdin, ehelin ! src/share/vm/gc/g1/heapRegionRemSet.cpp ! src/share/vm/gc/g1/heapRegionRemSet.hpp Changeset: b53b0251e250 Author: aph Date: 2017-01-27 09:50 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b53b0251e250 8173472: AArch64: C1 comparisons with null only use 32-bit instructions Reviewed-by: roland ! src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp Changeset: 9bfa2cceba90 Author: aph Date: 2017-01-27 18:22 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9bfa2cceba90 Merge Changeset: aa9bbc5fbf68 Author: dpochepk Date: 2017-01-27 18:44 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/aa9bbc5fbf68 8173399: Jittester: sources should be aligned with latest product state Reviewed-by: kvn ! test/testlibrary/jittester/Makefile ! test/testlibrary/jittester/src/jdk/test/lib/jittester/TestsGenerator.java Changeset: 8c1d94c35134 Author: dpochepk Date: 2017-01-27 21:39 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/8c1d94c35134 Merge Changeset: 2c44cff993b8 Author: jgeorge Date: 2017-01-30 13:48 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2c44cff993b8 8171084: heapdump/JMapHeapCore fails with java.lang.RuntimeException: Heap segment size overflow Summary: Create a new heapdump segment and truncate huge arrays if required, to avoid overflow of the 32 bit value representing the size. Reviewed-by: dholmes, dsamersoff Contributed-by: jini.george at oracle.com ! src/jdk.hotspot.agent/linux/native/libsaproc/libproc_impl.c ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/AbstractHeapGraphWriter.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java + test/serviceability/sa/LingeredAppWithLargeArray.java + test/serviceability/sa/TestHeapDumpForLargeArray.java ! test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java Changeset: ab3d4589f4d8 Author: never Date: 2017-01-30 10:30 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ab3d4589f4d8 8173584: Add unit test for 8173309 Reviewed-by: kvn ! test/compiler/jvmci/compilerToVM/MaterializeVirtualObjectTest.java Changeset: 6349a973d248 Author: vlivanov Date: 2017-01-30 16:03 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6349a973d248 8158546: C1 compilation fails with "Constant field loads are folded during parsing" Reviewed-by: kvn ! src/share/vm/c1/c1_Canonicalizer.cpp Changeset: 47dfa7f4098e Author: vlivanov Date: 2017-01-30 16:04 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/47dfa7f4098e 8173404: C2: wrong nmethod dependency can be recorded for CallSite.target Reviewed-by: kvn ! src/share/vm/opto/type.cpp ! test/compiler/jsr292/ContinuousCallSiteTargetChange.java Changeset: a1d2a9d7e580 Author: vlivanov Date: 2017-01-31 01:11 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a1d2a9d7e580 8173338: C2: continuous CallSite relinkage eventually disables compilation for a method Reviewed-by: jrose, dlong, kvn ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/nmethod.cpp Changeset: 7fc338000594 Author: thartmann Date: 2017-01-31 18:42 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7fc338000594 8173373: C1: NPE is thrown instead of LinkageError when accessing inaccessible field on NULL receiver Summary: Deoptimize if receiver null check of unresolved field access fails to throw NoClassDefFoundError instead of NPE. Reviewed-by: vlivanov ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp + test/compiler/c1/TestUnresolvedField.jasm + test/compiler/c1/TestUnresolvedFieldMain.java Changeset: 9a9d35b5f377 Author: bchristi Date: 2017-01-31 11:50 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9a9d35b5f377 8156073: 2-slot LiveStackFrame locals (long and double) are incorrect Reviewed-by: coleenp, mchung ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/prims/stackwalk.cpp ! src/share/vm/prims/stackwalk.hpp ! test/runtime/LocalLong/LocalLongHelper.java Changeset: 8f9d73e44c1a Author: bchristi Date: 2017-01-31 20:04 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/8f9d73e44c1a Merge Changeset: b07ef472634f Author: dcubed Date: 2017-01-31 14:33 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b07ef472634f 8173693: disable post_class_unload() for non JavaThread initiators Reviewed-by: sspitsyn, gthornbr ! src/share/vm/prims/jvmtiExport.cpp Changeset: 3db03a3709f4 Author: jwilhelm Date: 2017-01-31 20:54 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3db03a3709f4 Merge ! src/cpu/aarch64/vm/globals_aarch64.hpp - src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/collect/ClassCollector.java ! src/os_cpu/linux_aarch64/vm/os_linux_aarch64.cpp - test/compiler/aot/cli/jaotc/ClasspathOptionTest.java - test/compiler/aot/fingerprint/CDSDumper.java - test/compiler/aot/fingerprint/CDSRunner.java - test/compiler/aot/fingerprint/SelfChanged.java - test/compiler/aot/fingerprint/SelfChangedCDS.java - test/compiler/aot/fingerprint/SuperChanged.java - test/compiler/c2/cr7200264/Test7200264.sh - test/compiler/jvmci/compilerToVM/CanInlineMethodTest.java Changeset: 5fdcab5b7979 Author: jwilhelm Date: 2017-02-01 00:56 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5fdcab5b7979 Merge Changeset: b6f61bfa87dd Author: never Date: 2017-01-30 17:29 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b6f61bfa87dd 8173227: [JVMCI] HotSpotJVMCIMetaAccessContext.fromClass is inefficient Reviewed-by: dnsimon ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJVMCIMetaAccessContext.java Changeset: fa455b914ac9 Author: iveresov Date: 2017-02-02 16:57 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/fa455b914ac9 8173846: [AOT] Stubs hang onto intermediate compiler state forever Summary: Stub shouldn't keep alive the graph Reviewed-by: kvn Contributed-by: tom.rodriguez at oracle.com ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/AOTStub.java ! src/jdk.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/stubs/Stub.java Changeset: e64d5880a8be Author: jwilhelm Date: 2017-02-09 23:15 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e64d5880a8be Merge ! src/share/vm/classfile/vmSymbols.hpp Changeset: b2d0a906afd7 Author: jwilhelm Date: 2017-02-09 23:35 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b2d0a906afd7 Merge Changeset: 977ea8a751aa Author: alanb Date: 2017-02-13 08:12 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/977ea8a751aa Merge ! src/jdk.hotspot.agent/linux/native/libsaproc/libproc_impl.c ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/AbstractHeapGraphWriter.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/methodHandles.cpp ! test/ProblemList.txt ! test/runtime/modules/AccessCheck/CheckRead.java ! test/runtime/modules/AccessCheck/DiffCL_CheckRead.java ! test/runtime/modules/AccessCheck/DiffCL_ExpQualOther.java ! test/runtime/modules/AccessCheck/DiffCL_ExpQualToM1.java ! test/runtime/modules/AccessCheck/DiffCL_ExpUnqual.java ! test/runtime/modules/AccessCheck/DiffCL_PkgNotExp.java ! test/runtime/modules/AccessCheck/DiffCL_Umod.java ! test/runtime/modules/AccessCheck/DiffCL_UmodUpkg.java ! test/runtime/modules/AccessCheck/ExpQualOther.java ! test/runtime/modules/AccessCheck/ExpQualToM1.java ! test/runtime/modules/AccessCheck/ExpUnqual.java ! test/runtime/modules/AccessCheck/ExportAllUnnamed.java ! test/runtime/modules/AccessCheck/PkgNotExp.java ! test/runtime/modules/AccessCheck/Umod.java ! test/runtime/modules/AccessCheck/UmodDiffCL_ExpQualOther.java ! test/runtime/modules/AccessCheck/UmodDiffCL_ExpUnqual.java ! test/runtime/modules/AccessCheck/UmodDiffCL_PkgNotExp.java ! test/runtime/modules/AccessCheck/UmodUPkg.java ! test/runtime/modules/AccessCheck/UmodUpkgDiffCL_ExpQualOther.java ! test/runtime/modules/AccessCheck/UmodUpkgDiffCL_NotExp.java ! test/runtime/modules/AccessCheck/UmodUpkg_ExpQualOther.java ! test/runtime/modules/AccessCheck/UmodUpkg_NotExp.java ! test/runtime/modules/AccessCheck/Umod_ExpQualOther.java ! test/runtime/modules/AccessCheck/Umod_ExpUnqual.java ! test/runtime/modules/AccessCheck/Umod_PkgNotExp.java ! test/runtime/modules/AccessCheck/p1/c1Loose.java ! test/runtime/modules/AccessCheckAllUnnamed.java ! test/runtime/modules/AccessCheckExp.java ! test/runtime/modules/AccessCheckRead.java ! test/runtime/modules/AccessCheckSuper.java ! test/runtime/modules/AccessCheckUnnamed.java ! test/runtime/modules/AccessCheckWorks.java ! test/runtime/modules/ExportTwice.java ! test/runtime/modules/IgnoreModulePropertiesTest.java ! test/runtime/modules/JVMAddModuleExportToAllUnnamed.java ! test/runtime/modules/JVMAddModuleExportsToAll.java ! test/runtime/modules/JVMAddModulePackage.java ! test/runtime/modules/JVMDefineModule.java ! test/runtime/modules/ModuleHelper.java ! test/runtime/modules/ModuleOptionsTest.java ! test/runtime/modules/ModuleStress/ModuleNonBuiltinCLMain.java ! test/runtime/modules/ModuleStress/ModuleSameCLMain.java ! test/runtime/modules/PatchModule/PatchModuleDupModule.java ! test/serviceability/jvmti/GetModulesInfo/JvmtiGetAllModulesTest.java ! test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java ! test/testlibrary/jittester/Makefile From alan.bateman at oracle.com Mon Feb 13 09:29:24 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 13 Feb 2017 09:29:24 +0000 Subject: hg: jigsaw/jake/jdk: 48 new changesets Message-ID: <201702130929.v1D9TQ1B002267@aojmv0008.oracle.com> Changeset: c39f051b38d8 Author: bpb Date: 2017-02-07 11:01 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c39f051b38d8 8173910: (fs) java/nio/file/FileSystem/Basic.java should conditionally check FileStores Summary: On Unix platforms, spawn a 'df' process and skip FileStore check if it hangs Reviewed-by: alanb ! test/java/nio/file/FileSystem/Basic.java Changeset: 1ef7723209e7 Author: lancea Date: 2017-02-07 14:07 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1ef7723209e7 8169313: java.xml.ws not granted NetPermission(getProxySelector) Reviewed-by: alanb, aefimov, mchung ! src/java.base/share/lib/security/default.policy Changeset: 88f5292cbbad Author: rpatil Date: 2017-02-08 02:23 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/88f5292cbbad 8173943: Change error reporting of LauncherHelper to include actual Error class name Reviewed-by: alanb, ksrini ! src/java.base/share/classes/sun/launcher/LauncherHelper.java Changeset: f5807d240630 Author: smarks Date: 2017-02-07 13:45 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f5807d240630 8044626: Update RMI specifications to reflect modularization changes 8165649: Re-examine if Activatable object can be created from non-public class and/or constructor Reviewed-by: alanb, mchung ! src/java.rmi/share/classes/java/rmi/activation/ActivationInstantiator.java ! src/java.rmi/share/classes/java/rmi/activation/Activator.java ! src/java.rmi/share/classes/java/rmi/server/UnicastRemoteObject.java Changeset: e50de2389390 Author: mchung Date: 2017-02-07 16:41 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e50de2389390 8173712: Rename JAVA_OPTIONS environment variable to JDK_JAVA_OPTIONS Reviewed-by: henryjen, psandoz ! src/java.base/share/native/launcher/main.c ! src/java.base/share/native/libjli/args.c ! src/java.base/share/native/libjli/java.h ! src/java.base/windows/native/libjli/cmdtoargs.c ! test/ProblemList.txt ! test/tools/launcher/ArgsEnvVar.java ! test/tools/launcher/I18NArgTest.java Changeset: 47526f23be49 Author: ascarpino Date: 2017-02-07 19:55 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/47526f23be49 8151116: Add extended key usage constraint to the jdk.certpath.disabledAlgorithms security property Reviewed-by: wetmore ! src/java.base/share/conf/security/java.security Changeset: 04c3f5221759 Author: coffeys Date: 2017-02-08 08:40 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/04c3f5221759 8173783: IllegalArgumentException: jdk.tls.namedGroups Reviewed-by: xuelei, wetmore ! src/java.base/share/classes/sun/security/ssl/EllipticCurvesExtension.java + test/sun/security/ssl/ServerHandshaker/HelloExtensionsTest.java Changeset: e56bfa6ae3ce Author: dfuchs Date: 2017-02-08 16:33 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e56bfa6ae3ce 8173898: StackWalker.walk throws InternalError if called from a constructor invoked through reflection. Summary: StackWalker is fixed to take into account constructor reflection frames. The specification of StackWalker.Option.SHOW_REFLECT_FRAMES is also clarified in this regard. Reviewed-by: bchristi, lancea, mchung, psandoz ! src/java.base/share/classes/java/lang/StackStreamFactory.java ! src/java.base/share/classes/java/lang/StackWalker.java ! test/java/lang/StackWalker/Basic.java + test/java/lang/StackWalker/ReflectionFrames.java Changeset: 23074c7a0bc6 Author: rriggs Date: 2017-02-08 13:17 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/23074c7a0bc6 8174128: [testbug] Remove implementation dependency from java.time TCK tests Reviewed-by: dfuchs, scolebourne ! test/java/time/TEST.properties ! test/java/time/tck/java/time/AbstractTCKTest.java ! test/java/time/tck/java/time/TCKOffsetDateTime.java ! test/java/time/tck/java/time/TCKOffsetTime.java ! test/java/time/tck/java/time/serial/TCKZoneIdSerialization.java + test/java/time/test/java/time/TEST.properties Changeset: bb824eeea452 Author: ascarpino Date: 2017-02-08 10:56 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/bb824eeea452 8174157: Backout 8151116 Reviewed-by: mullan ! src/java.base/share/conf/security/java.security Changeset: 223b9c6c892f Author: ascarpino Date: 2017-02-08 11:01 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/223b9c6c892f 8173410: Add commented config line for jdk.security.provider.preferred Reviewed-by: wetmore ! src/java.base/share/conf/security/java.security Changeset: cb761a779278 Author: valeriep Date: 2017-02-08 19:20 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/cb761a779278 8173708: Re-enable AES cipher with CFB128 mode for Ucrypto provider Summary: Updated Ucrypto config file to remove the disabled mechanisms Reviewed-by: wetmore ! src/jdk.crypto.ucrypto/solaris/conf/security/ucrypto-solaris.cfg ! test/com/oracle/security/ucrypto/TestAES.java Changeset: d4816c8d3ab8 Author: valeriep Date: 2017-02-08 19:22 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d4816c8d3ab8 Merge Changeset: 4be3ef759ead Author: dlsmith Date: 2017-02-08 12:27 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4be3ef759ead 8173587: LambdaMetafactory needs to validate descriptors and method name Reviewed-by: psandoz ! src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java + test/java/lang/invoke/lambda/MetafactoryDescriptorTest.java + test/java/lang/invoke/lambda/MetafactoryMethodNameTest.java - test/java/lang/invoke/lambda/MetafactorySamReturnTest.java Changeset: 00cd2ba50e10 Author: ascarpino Date: 2017-02-08 12:08 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/00cd2ba50e10 8160655: Fix denyAfter and usage types for security properties Reviewed-by: mullan, xuelei ! src/java.base/share/classes/sun/security/pkcs/SignerInfo.java ! src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChecker.java ! src/java.base/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java ! src/java.base/share/classes/sun/security/provider/certpath/OCSP.java ! src/java.base/share/classes/sun/security/provider/certpath/OCSPResponse.java ! src/java.base/share/classes/sun/security/provider/certpath/PKIX.java ! src/java.base/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java + src/java.base/share/classes/sun/security/provider/certpath/PKIXExtendedParameters.java - src/java.base/share/classes/sun/security/provider/certpath/PKIXTimestampParameters.java ! src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java ! src/java.base/share/classes/sun/security/provider/certpath/SunCertPathBuilder.java ! src/java.base/share/classes/sun/security/ssl/SSLContextImpl.java ! src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java - src/java.base/share/classes/sun/security/util/CertConstraintParameters.java + src/java.base/share/classes/sun/security/util/ConstraintsParameters.java ! src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java ! src/java.base/share/classes/sun/security/util/SignatureFileVerifier.java ! src/java.base/share/classes/sun/security/validator/PKIXValidator.java ! src/java.base/share/classes/sun/security/validator/SimpleValidator.java ! src/java.base/share/conf/security/java.security ! test/sun/security/tools/jarsigner/TimestampCheck.java Changeset: 56a5cee26bbb Author: dlsmith Date: 2017-02-08 14:23 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/56a5cee26bbb 8033076: LambdaMetafactory should use types in implMethod.type() Reviewed-by: psandoz ! src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java ! src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java Changeset: 95050afa6898 Author: dlsmith Date: 2017-02-08 17:28 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/95050afa6898 8174226: Test failures after JDK-8033076 Summary: Reverting JDK-8033076 for now Reviewed-by: darcy ! src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java ! src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java Changeset: cad3932c20ec Author: ssahoo Date: 2017-02-09 05:19 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/cad3932c20ec 8168423: Test Task: Custom system class loader + security manager + malformed policy file = recursive initialization Summary: If a malformed policy file is encountered when running with a custom system class loader then it leads to a recursive initialization issue Reviewed-by: mullan + test/java/lang/ClassLoader/securityManager/ClassLoaderTest.java + test/java/lang/ClassLoader/securityManager/TestClassLoader.java + test/java/lang/ClassLoader/securityManager/TestClient.java + test/java/lang/ClassLoader/securityManager/malformed.policy + test/java/lang/ClassLoader/securityManager/valid.policy Changeset: 5757370ec024 Author: bpb Date: 2017-02-09 07:48 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5757370ec024 8173387: java/nio/channels/Selector/SelectTimeout.java failed with "Test timed out early with timeout 100000000999" Summary: Corrected timing problem with multiple threads setting static variables Reviewed-by: clanger, alanb ! test/java/nio/channels/Selector/SelectTimeout.java Changeset: a547b3736c3b Author: msheppar Date: 2017-02-09 15:56 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a547b3736c3b 8049375: Extend how the org.omg.CORBA.ORB handles the search for orb.properties Reviewed-by: lancea, alanb ! test/TEST.groups + test/org/omg/CORBA/OrbPropertiesTest.java + test/org/omg/CORBA/TestOrbImpl.java + test/org/omg/CORBA/TestSingletonOrbImpl.java + test/org/omg/CORBA/jtreg.test.policy Changeset: 68cb676e526a Author: lana Date: 2017-02-09 18:10 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/68cb676e526a Merge - src/java.base/share/classes/sun/security/provider/certpath/PKIXTimestampParameters.java - src/java.base/share/classes/sun/security/util/CertConstraintParameters.java - test/java/lang/invoke/lambda/MetafactorySamReturnTest.java Changeset: 34174308ee40 Author: bpb Date: 2017-02-09 14:49 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/34174308ee40 8174127: (ch) Add instrumentation to java/nio/channels/FileChannel/Transfer.java Summary: Convert to TestNG and add some debugging output for large file creation time Reviewed-by: alanb ! test/java/nio/channels/FileChannel/Transfer.java Changeset: 23ef25fca147 Author: amlu Date: 2017-02-10 10:07 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/23ef25fca147 8174241: ProblemList update for TestWsImport, JdbMethodExitTest and jimage tests Reviewed-by: lancea ! test/ProblemList.txt Changeset: 297a26386644 Author: mli Date: 2017-02-09 18:33 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/297a26386644 8173957: Fix @since in module-info.java in dev/jdk repo Reviewed-by: alanb, lancea ! src/java.base/share/classes/module-info.java ! src/java.datatransfer/share/classes/module-info.java ! src/java.desktop/share/classes/module-info.java ! src/java.instrument/share/classes/module-info.java ! src/java.logging/share/classes/module-info.java ! src/java.management.rmi/share/classes/module-info.java ! src/java.management/share/classes/module-info.java ! src/java.naming/share/classes/module-info.java ! src/java.prefs/share/classes/module-info.java ! src/java.rmi/share/classes/module-info.java ! src/java.scripting/share/classes/module-info.java ! src/java.se.ee/share/classes/module-info.java ! src/java.se/share/classes/module-info.java ! src/java.security.jgss/share/classes/module-info.java ! src/java.security.sasl/share/classes/module-info.java ! src/java.smartcardio/share/classes/module-info.java ! src/java.sql.rowset/share/classes/module-info.java ! src/java.sql/share/classes/module-info.java ! src/java.transaction/share/classes/module-info.java ! src/java.xml.crypto/share/classes/module-info.java ! src/jdk.attach/share/classes/module-info.java ! src/jdk.desktop/share/classes/module-info.java ! src/jdk.editpad/share/classes/module-info.java ! src/jdk.incubator.httpclient/share/classes/module-info.java ! src/jdk.internal.ed/share/classes/module-info.java ! src/jdk.internal.le/share/classes/module-info.java ! src/jdk.internal.opt/share/classes/module-info.java ! src/jdk.jdi/share/classes/module-info.java ! src/jdk.jdwp.agent/share/classes/module-info.java ! src/jdk.security.auth/share/classes/module-info.java ! src/jdk.security.jgss/share/classes/module-info.java Changeset: cb3a760ccbb0 Author: michaelm Date: 2017-02-10 09:55 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/cb3a760ccbb0 8174716: java/net/httpclient/security/Driver.java failing in JDK 9 Reviewed-by: alanb ! test/java/net/httpclient/security/Driver.java Changeset: 1c8f054f6278 Author: alanb Date: 2017-02-10 09:04 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1c8f054f6278 8173393: Module system implementation refresh (2/2017) Reviewed-by: dfuchs, psandoz, mchung, alanb Contributed-by: alan.bateman at oracle.com, mandy.chung at oracle.com, claes.redestad at oracle.com, alex.buckley at oracle.com, mark.reinhold at oracle.com, john.r.rose at oracle.com ! make/src/classes/build/tools/jigsaw/GenGraphs.java ! make/src/classes/build/tools/jigsaw/ModuleSummary.java ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/classes/java/lang/ClassLoader.java + src/java.base/share/classes/java/lang/IllegalCallerException.java ! src/java.base/share/classes/java/lang/Package.java ! src/java.base/share/classes/java/lang/SecurityManager.java ! src/java.base/share/classes/java/lang/StackStreamFactory.java ! src/java.base/share/classes/java/lang/StackTraceElement.java ! src/java.base/share/classes/java/lang/StackWalker.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/lang/module/Configuration.java ! src/java.base/share/classes/java/lang/module/FindException.java ! src/java.base/share/classes/java/lang/module/InvalidModuleDescriptorException.java ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java ! src/java.base/share/classes/java/lang/module/ModuleFinder.java ! src/java.base/share/classes/java/lang/module/ModuleReader.java ! src/java.base/share/classes/java/lang/module/ModuleReference.java ! src/java.base/share/classes/java/lang/module/ResolutionException.java ! src/java.base/share/classes/java/lang/module/ResolvedModule.java ! src/java.base/share/classes/java/lang/module/Resolver.java ! src/java.base/share/classes/java/lang/module/package-info.java ! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java ! src/java.base/share/classes/java/lang/reflect/Constructor.java ! src/java.base/share/classes/java/lang/reflect/Field.java ! src/java.base/share/classes/java/lang/reflect/InaccessibleObjectException.java ! src/java.base/share/classes/java/lang/reflect/Layer.java ! src/java.base/share/classes/java/lang/reflect/LayerInstantiationException.java ! src/java.base/share/classes/java/lang/reflect/Method.java ! src/java.base/share/classes/java/lang/reflect/Module.java ! src/java.base/share/classes/java/lang/reflect/Proxy.java ! src/java.base/share/classes/java/lang/reflect/package-info.java ! src/java.base/share/classes/java/net/URLClassLoader.java ! src/java.base/share/classes/java/security/SecureClassLoader.java ! src/java.base/share/classes/java/security/Security.java ! src/java.base/share/classes/java/util/ResourceBundle.java ! src/java.base/share/classes/java/util/ServiceLoader.java ! src/java.base/share/classes/java/util/spi/AbstractResourceBundleProvider.java ! src/java.base/share/classes/java/util/spi/ResourceBundleControlProvider.java ! src/java.base/share/classes/java/util/spi/ResourceBundleProvider.java ! src/java.base/share/classes/jdk/internal/jmod/JmodFile.java ! src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java ! src/java.base/share/classes/jdk/internal/loader/ResourceHelper.java ! src/java.base/share/classes/jdk/internal/misc/JavaLangAccess.java ! src/java.base/share/classes/jdk/internal/misc/JavaLangModuleAccess.java ! src/java.base/share/classes/jdk/internal/module/Builder.java ! src/java.base/share/classes/jdk/internal/module/Checks.java ! src/java.base/share/classes/jdk/internal/module/ClassFileAttributes.java ! src/java.base/share/classes/jdk/internal/module/ClassFileConstants.java ! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java ! src/java.base/share/classes/jdk/internal/module/ModuleInfo.java ! src/java.base/share/classes/jdk/internal/module/ModuleInfoExtender.java ! src/java.base/share/classes/jdk/internal/module/ModuleLoaderMap.java ! src/java.base/share/classes/jdk/internal/module/ModulePatcher.java ! src/java.base/share/classes/jdk/internal/module/ModulePath.java ! src/java.base/share/classes/jdk/internal/module/ModuleReferenceImpl.java ! src/java.base/share/classes/jdk/internal/module/ModuleReferences.java ! src/java.base/share/classes/jdk/internal/module/Modules.java ! src/java.base/share/classes/jdk/internal/module/SystemModuleFinder.java ! src/java.base/share/classes/jdk/internal/reflect/Reflection.java ! src/java.base/share/classes/sun/invoke/util/VerifyAccess.java ! src/java.base/share/classes/sun/launcher/LauncherHelper.java ! src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java ! src/java.instrument/share/classes/java/lang/instrument/ClassFileTransformer.java ! src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java ! src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnector.java ! src/jdk.jartool/share/classes/sun/tools/jar/GNUStyleOptions.java ! src/jdk.jartool/share/classes/sun/tools/jar/Main.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ResourcePoolConfiguration.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java ! test/ProblemList.txt ! test/java/io/FilePermission/ReadFileOnPath.java ! test/java/lang/Class/forName/modules/TestLayer.java ! test/java/lang/Class/forName/modules/src/m3/p3/NoAccess.java ! test/java/lang/Class/getPackageName/Basic.java ! test/java/lang/StackWalker/CallerFromMain.java ! test/java/lang/invoke/AccessControlTest.java ! test/java/lang/invoke/DropLookupModeTest.java ! test/java/lang/invoke/MethodHandles/privateLookupIn/Driver.java + test/java/lang/invoke/MethodHandles/privateLookupIn/Unnamed.java ! test/java/lang/invoke/MethodHandles/privateLookupIn/test/p/PrivateLookupInTests.java + test/java/lang/invoke/modules/Driver.java - test/java/lang/invoke/modules/ModuleAccessControlTest.java + test/java/lang/invoke/modules/Unnamed.java + test/java/lang/invoke/modules/m1/module-info.java + test/java/lang/invoke/modules/m1/p1/Main.java + test/java/lang/invoke/modules/m1/p1/Type1.java + test/java/lang/invoke/modules/m1/p2/Type2.java + test/java/lang/invoke/modules/m2/module-info.java + test/java/lang/invoke/modules/m2/q1/Type1.java + test/java/lang/invoke/modules/m2/q2/Type2.java - test/java/lang/invoke/modules/src/m1/module-info.java - test/java/lang/invoke/modules/src/m1/p1/Main.java - test/java/lang/invoke/modules/src/m1/p1/Type1.java - test/java/lang/invoke/modules/src/m1/p2/Type2.java - test/java/lang/invoke/modules/src/m2/module-info.java - test/java/lang/invoke/modules/src/m2/q1/Type1.java - test/java/lang/invoke/modules/src/m2/q2/Type2.java ! test/java/lang/module/AutomaticModulesTest.java ! test/java/lang/module/ConfigurationTest.java ! test/java/lang/module/ModuleDescriptorTest.java ! test/java/lang/module/ModuleFinderTest.java ! test/java/lang/module/ModuleNamesTest.java ! test/java/lang/module/ModuleReader/ModuleReaderTest.java ! test/java/lang/module/ModuleReferenceTest.java ! test/java/lang/module/MultiReleaseJarTest.java + test/java/lang/reflect/AccessibleObject/CanAccessTest.java ! test/java/lang/reflect/AccessibleObject/ModuleSetAccessibleTest.java + test/java/lang/reflect/AccessibleObject/TrySetAccessibleTest.java ! test/java/lang/reflect/Layer/BasicLayerTest.java ! test/java/lang/reflect/Layer/LayerAndLoadersTest.java ! test/java/lang/reflect/Layer/LayerControllerTest.java ! test/java/lang/reflect/Module/AnnotationsTest.java ! test/java/lang/reflect/Module/BasicModuleTest.java ! test/java/lang/reflect/Module/WithSecurityManager.java + test/java/lang/reflect/Module/addXXX/Driver.java + test/java/lang/reflect/Module/addXXX/m1/module-info.java + test/java/lang/reflect/Module/addXXX/m1/p1/C.java + test/java/lang/reflect/Module/addXXX/m2/module-info.java + test/java/lang/reflect/Module/addXXX/m2/p2/C.java + test/java/lang/reflect/Module/addXXX/m2/p2/internal/C.java + test/java/lang/reflect/Module/addXXX/m3/module-info.java + test/java/lang/reflect/Module/addXXX/m3/p3/C.java + test/java/lang/reflect/Module/addXXX/m4/module-info.java + test/java/lang/reflect/Module/addXXX/m4/p4/C.java + test/java/lang/reflect/Module/addXXX/test/module-info.java + test/java/lang/reflect/Module/addXXX/test/test/C.java + test/java/lang/reflect/Module/addXXX/test/test/Main.java + test/java/lang/reflect/Module/addXXX/test/test/Service.java ! test/java/lang/reflect/Proxy/ProxyClassAccessTest.java ! test/java/lang/reflect/Proxy/ProxyLayerTest.java ! test/java/security/modules/ModularTest.java ! test/java/util/ServiceLoader/modules/BadProvidersTest.java ! test/java/util/ServiceLoader/modules/Basic.java + test/jdk/internal/reflect/CallerSensitive/CheckCSMs.java ! test/jdk/modules/etc/VerifyModuleDelegation.java ! test/jdk/modules/scenarios/container/src/container/container/Main.java ! test/sun/management/jdp/JdpJmxRemoteDynamicPortTest.java ! test/tools/jar/mmrjar/Basic.java ! test/tools/jar/modularJar/Basic.java ! test/tools/jlink/JLinkNegativeTest.java ! test/tools/jmod/hashes/HashesTest.java ! test/tools/launcher/modules/patch/systemmodules/src1/java.base/jdk/internal/modules/SystemModules.java Changeset: d35044f37cdb Author: alanb Date: 2017-02-10 12:28 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d35044f37cdb Merge ! src/java.base/share/classes/java/lang/StackStreamFactory.java ! src/java.base/share/classes/java/lang/StackWalker.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java ! src/java.base/share/classes/sun/launcher/LauncherHelper.java ! test/ProblemList.txt ! test/java/lang/ClassLoader/securityManager/ClassLoaderTest.java - test/java/lang/invoke/modules/ModuleAccessControlTest.java - test/java/lang/invoke/modules/src/m1/module-info.java - test/java/lang/invoke/modules/src/m1/p1/Main.java - test/java/lang/invoke/modules/src/m1/p1/Type1.java - test/java/lang/invoke/modules/src/m1/p2/Type2.java - test/java/lang/invoke/modules/src/m2/module-info.java - test/java/lang/invoke/modules/src/m2/q1/Type1.java - test/java/lang/invoke/modules/src/m2/q2/Type2.java Changeset: d18d6cbde5e3 Author: alanb Date: 2017-02-10 12:30 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d18d6cbde5e3 Merge Changeset: ba1d4f8c77de Author: bchristi Date: 2017-01-31 11:51 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ba1d4f8c77de 8156073: 2-slot LiveStackFrame locals (long and double) are incorrect Reviewed-by: coleenp, mchung ! src/java.base/share/classes/java/lang/LiveStackFrame.java ! src/java.base/share/classes/java/lang/LiveStackFrameInfo.java - test/java/lang/StackWalker/CountLocalSlots.java ! test/java/lang/StackWalker/LocalsAndOperands.java - test/java/lang/StackWalker/LocalsCrash.java Changeset: 07739d8a2680 Author: jwilhelm Date: 2017-01-31 20:54 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/07739d8a2680 Merge ! src/java.base/share/classes/module-info.java - src/jdk.jvmstat/share/classes/module-info.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/AbstractMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/BufferedMonitoredVm.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/ByteArrayMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/HostIdentifier.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/IntegerMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/LongMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/Monitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/MonitorException.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/MonitoredHost.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/MonitoredHostService.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/MonitoredVm.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/MonitoredVmUtil.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/StringMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/Units.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/Variability.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/VmIdentifier.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/event/HostEvent.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/event/HostListener.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/event/MonitorStatusChangeEvent.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/event/VmEvent.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/event/VmListener.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/event/VmStatusChangeEvent.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/event/package.html - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/package.html - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/AbstractMonitoredVm.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/AbstractPerfDataBuffer.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/AbstractPerfDataBufferPrologue.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/AliasFileParser.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/CountedTimerTask.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/CountedTimerTaskUtils.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/MonitorDataException.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/MonitorStatus.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/MonitorStructureException.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/MonitorTypeException.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/MonitorVersionException.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfByteArrayMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfDataBufferImpl.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfIntegerMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfLongMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfStringConstantMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfStringMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfStringVariableMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/SyntaxException.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/package.html - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/FileMonitoredVm.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/MonitoredHostFileService.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/MonitoredHostProvider.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/PerfDataBuffer.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/package.html - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/LocalEventTimer.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/LocalMonitoredVm.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/LocalVmManager.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/MonitoredHostLocalService.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/MonitoredHostProvider.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/PerfDataBuffer.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/PerfDataFile.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/package.html - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v1_0/BasicType.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v1_0/PerfDataBuffer.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v1_0/PerfDataBufferPrologue.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v2_0/PerfDataBuffer.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v2_0/PerfDataBufferPrologue.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v2_0/TypeCode.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/resources/aliasmap ! test/ProblemList.txt Changeset: 46d67328922c Author: jwilhelm Date: 2017-02-01 00:56 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/46d67328922c Merge - test/java/lang/StackWalker/CountLocalSlots.java - test/java/lang/StackWalker/LocalsCrash.java Changeset: 0d2ab72ba600 Author: dnsimon Date: 2017-02-02 05:26 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0d2ab72ba600 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied Reviewed-by: kvn, alanb, mchung, mullan ! src/java.base/share/lib/security/default.policy Changeset: 31fdce5df5cd Author: jwilhelm Date: 2017-02-09 23:15 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/31fdce5df5cd Merge ! src/java.base/share/classes/module-info.java ! src/java.base/share/lib/security/default.policy ! src/jdk.management.agent/share/classes/jdk/internal/agent/Agent.java ! test/ProblemList.txt - test/java/lang/StackWalker/CountLocalSlots.java - test/java/lang/StackWalker/LocalsCrash.java Changeset: 9061aabb211d Author: jwilhelm Date: 2017-02-09 23:35 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9061aabb211d Merge ! src/java.base/share/classes/module-info.java ! test/ProblemList.txt - test/java/lang/StackWalker/CountLocalSlots.java - test/java/lang/StackWalker/LocalsCrash.java Changeset: a024ba2ca3d2 Author: dkononenko Date: 2017-02-09 19:43 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a024ba2ca3d2 8170113: jimage extract to readonly directory causes MissingResourceException Summary: Added a missing resource. Reviewed-by: alanb, anazarov Contributed-by: denis.kononenko at oracle.com ! src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage.properties Changeset: 27716a9b2378 Author: serb Date: 2017-01-31 19:22 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/27716a9b2378 8143077: Deprecate InputEvent._MASK in favor of InputEvent._DOWN_MASK Reviewed-by: prr, alexsch, azvegint, mchung, egahlin ! src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxPopup.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaInternalFrameDockIconUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaInternalFrameUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaMenuPainter.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaTabbedPaneCopyFromBasicUI.java ! src/java.desktop/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/java.desktop/macosx/classes/sun/lwawt/LWListPeer.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CDragSourceContextPeer.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CMenuItem.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPopupMenu.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterDialogPeer.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifDesktopIconUI.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifGraphicsUtils.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifInternalFrameTitlePane.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifLookAndFeel.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifPopupMenuUI.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifTextUI.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/windows/WindowsTabbedPaneUI.java ! src/java.desktop/share/classes/java/awt/AWTEvent.java ! src/java.desktop/share/classes/java/awt/AWTKeyStroke.java ! src/java.desktop/share/classes/java/awt/Component.java ! src/java.desktop/share/classes/java/awt/Container.java ! src/java.desktop/share/classes/java/awt/Event.java ! src/java.desktop/share/classes/java/awt/KeyboardFocusManager.java ! src/java.desktop/share/classes/java/awt/MenuBar.java ! src/java.desktop/share/classes/java/awt/MenuComponent.java ! src/java.desktop/share/classes/java/awt/MenuItem.java ! src/java.desktop/share/classes/java/awt/MenuShortcut.java ! src/java.desktop/share/classes/java/awt/PopupMenu.java ! src/java.desktop/share/classes/java/awt/Robot.java ! src/java.desktop/share/classes/java/awt/Toolkit.java ! src/java.desktop/share/classes/java/awt/dnd/DragSourceDragEvent.java ! src/java.desktop/share/classes/java/awt/event/ActionEvent.java ! src/java.desktop/share/classes/java/awt/event/InputEvent.java ! src/java.desktop/share/classes/java/awt/event/KeyEvent.java ! src/java.desktop/share/classes/java/awt/event/MouseEvent.java ! src/java.desktop/share/classes/java/awt/peer/PopupMenuPeer.java ! src/java.desktop/share/classes/javax/swing/Autoscroller.java ! src/java.desktop/share/classes/javax/swing/DefaultButtonModel.java ! src/java.desktop/share/classes/javax/swing/JComboBox.java ! src/java.desktop/share/classes/javax/swing/JComponent.java ! src/java.desktop/share/classes/javax/swing/JFileChooser.java ! src/java.desktop/share/classes/javax/swing/JList.java ! src/java.desktop/share/classes/javax/swing/JMenuItem.java ! src/java.desktop/share/classes/javax/swing/JPopupMenu.java ! src/java.desktop/share/classes/javax/swing/JTable.java ! src/java.desktop/share/classes/javax/swing/JTextField.java ! src/java.desktop/share/classes/javax/swing/JToggleButton.java ! src/java.desktop/share/classes/javax/swing/JTree.java ! src/java.desktop/share/classes/javax/swing/KeyboardManager.java ! src/java.desktop/share/classes/javax/swing/MenuSelectionManager.java ! src/java.desktop/share/classes/javax/swing/SwingUtilities.java ! src/java.desktop/share/classes/javax/swing/ToolTipManager.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicComboPopup.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicGraphicsUtils.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicInternalFrameUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicMenuItemUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicMenuUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicPopupMenuUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicSplitPaneUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java ! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalRootPaneUI.java ! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalToolTipUI.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthSplitPaneUI.java ! src/java.desktop/share/classes/javax/swing/table/JTableHeader.java ! src/java.desktop/share/classes/javax/swing/text/DefaultCaret.java ! src/java.desktop/share/classes/javax/swing/text/JTextComponent.java ! src/java.desktop/share/classes/sun/awt/NullComponentPeer.java ! src/java.desktop/share/classes/sun/awt/SunToolkit.java ! src/java.desktop/share/classes/sun/swing/FilePane.java ! src/java.desktop/share/classes/sun/swing/MenuItemLayoutHelper.java ! src/java.desktop/share/classes/sun/swing/SwingUtilities2.java ! src/java.desktop/unix/classes/sun/awt/X11/InfoWindow.java ! src/java.desktop/unix/classes/sun/awt/X11/ListHelper.java ! src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java ! src/java.desktop/unix/classes/sun/awt/X11/XButtonPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XChoicePeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XEmbedServerTester.java ! src/java.desktop/unix/classes/sun/awt/X11/XListPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XMenuBarPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XPopupMenuPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XScrollPanePeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XScrollbar.java ! src/java.desktop/unix/classes/sun/awt/X11/XScrollbarPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XTextAreaPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XTrayIconPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XWindow.java ! src/java.desktop/windows/classes/sun/awt/windows/WButtonPeer.java ! src/java.desktop/windows/classes/sun/awt/windows/WFileDialogPeer.java ! src/java.desktop/windows/classes/sun/awt/windows/WPopupMenuPeer.java ! src/java.desktop/windows/classes/sun/awt/windows/WPrintDialogPeer.java ! src/java.desktop/windows/classes/sun/awt/windows/WTextFieldPeer.java ! src/jdk.jconsole/share/classes/sun/tools/jconsole/JConsole.java ! src/jdk.jconsole/share/classes/sun/tools/jconsole/VMPanel.java ! src/jdk.jconsole/share/classes/sun/tools/jconsole/inspector/Utils.java Changeset: bdb8499fdb64 Author: psadhukhan Date: 2017-02-02 11:05 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/bdb8499fdb64 8170578: CUPS Printing is broken with Ubuntu 16.10 (CUPS 2.2) Reviewed-by: prr ! src/java.desktop/unix/classes/sun/print/IPPPrintService.java ! test/java/awt/print/PrinterJob/PrintAttributeUpdateTest.java Changeset: 6dbd2f0fbd71 Author: prr Date: 2017-02-03 09:28 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6dbd2f0fbd71 8173409: make setMixingCutoutShape public and remove jdk.desktop Reviewed-by: serb, mchung, alexsch ! src/java.desktop/share/classes/com/sun/awt/AWTUtilities.java ! src/java.desktop/share/classes/java/awt/Component.java ! src/java.desktop/share/classes/javax/swing/JLayer.java ! src/java.desktop/share/classes/javax/swing/JRootPane.java ! src/java.desktop/share/classes/module-info.java ! src/java.desktop/share/classes/sun/awt/AWTAccessor.java - src/jdk.desktop/share/classes/jdk/awt/AWTUtils.java - src/jdk.desktop/share/classes/module-info.java ! test/java/awt/Mixing/AWT_Mixing/OpaqueOverlapping.java ! test/java/awt/Mixing/OpaqueTest.java - test/java/awt/jdk/TestJDKAWTUtils.java Changeset: 05b82284817f Author: prr Date: 2017-02-06 09:32 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/05b82284817f 8170493: JNI exception pending in JavaComponentAccessibility.m Reviewed-by: serb, psadhukhan ! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m Changeset: 94038948b70f Author: prr Date: 2017-02-06 09:34 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/94038948b70f Merge - make/copy/Copy-java.management.gmk - make/gensrc/Gensrc-java.management.gmk - make/rmic/Rmic-java.management.gmk - src/java.management/share/classes/com/sun/jmx/remote/internal/ProxyRef.java - src/java.management/share/classes/com/sun/jmx/remote/internal/RMIExporter.java - src/java.management/share/classes/com/sun/jmx/remote/internal/Unmarshal.java - src/java.management/share/classes/com/sun/jmx/remote/protocol/rmi/ClientProvider.java - src/java.management/share/classes/com/sun/jmx/remote/protocol/rmi/ServerProvider.java - src/java.management/share/classes/javax/management/remote/rmi/NoCallStackClassLoader.java - src/java.management/share/classes/javax/management/remote/rmi/RMIConnection.java - src/java.management/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java - src/java.management/share/classes/javax/management/remote/rmi/RMIConnector.java - src/java.management/share/classes/javax/management/remote/rmi/RMIConnectorServer.java - src/java.management/share/classes/javax/management/remote/rmi/RMIIIOPServerImpl.java - src/java.management/share/classes/javax/management/remote/rmi/RMIJRMPServerImpl.java - src/java.management/share/classes/javax/management/remote/rmi/RMIServer.java - src/java.management/share/classes/javax/management/remote/rmi/RMIServerImpl.java - src/java.management/share/classes/javax/management/remote/rmi/package.html - src/java.management/share/classes/sun/management/Agent.java - src/java.management/share/classes/sun/management/AgentConfigurationError.java - src/java.management/share/classes/sun/management/ConnectorAddressLink.java - src/java.management/share/classes/sun/management/FileSystem.java - src/java.management/share/classes/sun/management/jdp/JdpBroadcaster.java - src/java.management/share/classes/sun/management/jdp/JdpController.java - src/java.management/share/classes/sun/management/jdp/JdpException.java - src/java.management/share/classes/sun/management/jdp/JdpGenericPacket.java - src/java.management/share/classes/sun/management/jdp/JdpJmxPacket.java - src/java.management/share/classes/sun/management/jdp/JdpPacket.java - src/java.management/share/classes/sun/management/jdp/JdpPacketReader.java - src/java.management/share/classes/sun/management/jdp/JdpPacketWriter.java - src/java.management/share/classes/sun/management/jdp/package-info.java - src/java.management/share/classes/sun/management/jmxremote/ConnectorBootstrap.java - src/java.management/share/classes/sun/management/jmxremote/LocalRMIServerSocketFactory.java - src/java.management/share/classes/sun/management/jmxremote/SingleEntryRegistry.java - src/java.management/share/classes/sun/management/jmxremote/package.html - src/java.management/share/classes/sun/management/resources/agent.properties - src/java.management/share/classes/sun/management/resources/agent_de.properties - src/java.management/share/classes/sun/management/resources/agent_es.properties - src/java.management/share/classes/sun/management/resources/agent_fr.properties - src/java.management/share/classes/sun/management/resources/agent_it.properties - src/java.management/share/classes/sun/management/resources/agent_ja.properties - src/java.management/share/classes/sun/management/resources/agent_ko.properties - src/java.management/share/classes/sun/management/resources/agent_pt_BR.properties - src/java.management/share/classes/sun/management/resources/agent_sv.properties - src/java.management/share/classes/sun/management/resources/agent_zh_CN.properties - src/java.management/share/classes/sun/management/resources/agent_zh_TW.properties - src/java.management/share/classes/sun/management/spi/AgentProvider.java - src/java.management/share/conf/jmxremote.access - src/java.management/share/conf/jmxremote.password.template - src/java.management/share/conf/management.properties - src/java.management/share/conf/snmp.acl.template - src/java.management/unix/classes/sun/management/FileSystemImpl.java - src/java.management/unix/native/libmanagement/FileSystemImpl.c - src/java.management/windows/classes/sun/management/FileSystemImpl.java - src/java.management/windows/native/libmanagement/FileSystemImpl.c ! src/jdk.jconsole/share/classes/sun/tools/jconsole/JConsole.java - src/jdk.jvmstat/share/classes/module-info.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/AbstractMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/BufferedMonitoredVm.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/ByteArrayMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/HostIdentifier.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/IntegerMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/LongMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/Monitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/MonitorException.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/MonitoredHost.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/MonitoredHostService.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/MonitoredVm.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/MonitoredVmUtil.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/StringMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/Units.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/Variability.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/VmIdentifier.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/event/HostEvent.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/event/HostListener.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/event/MonitorStatusChangeEvent.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/event/VmEvent.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/event/VmListener.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/event/VmStatusChangeEvent.java - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/event/package.html - src/jdk.jvmstat/share/classes/sun/jvmstat/monitor/package.html - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/AbstractMonitoredVm.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/AbstractPerfDataBuffer.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/AbstractPerfDataBufferPrologue.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/AliasFileParser.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/CountedTimerTask.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/CountedTimerTaskUtils.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/MonitorDataException.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/MonitorStatus.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/MonitorStructureException.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/MonitorTypeException.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/MonitorVersionException.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfByteArrayMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfDataBufferImpl.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfIntegerMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfLongMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfStringConstantMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfStringMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfStringVariableMonitor.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/SyntaxException.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/package.html - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/FileMonitoredVm.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/MonitoredHostFileService.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/MonitoredHostProvider.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/PerfDataBuffer.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/package.html - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/LocalEventTimer.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/LocalMonitoredVm.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/LocalVmManager.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/MonitoredHostLocalService.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/MonitoredHostProvider.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/PerfDataBuffer.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/PerfDataFile.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/package.html - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v1_0/BasicType.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v1_0/PerfDataBuffer.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v1_0/PerfDataBufferPrologue.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v2_0/PerfDataBuffer.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v2_0/PerfDataBufferPrologue.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v2_0/TypeCode.java - src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/resources/aliasmap - test/sun/management/AgentCMETest.java - test/sun/management/AgentCheckTest.java Changeset: fbddaaa26e1b Author: mcherkas Date: 2017-02-07 18:55 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fbddaaa26e1b 8173145: Menu is activated after using mnemonic Alt/Key combination Reviewed-by: serb, ssadetsky ! src/java.desktop/share/classes/com/sun/java/swing/plaf/windows/WindowsRootPaneUI.java + test/com/sun/java/swing/plaf/windows/Test8173145.java Changeset: 205e05380de6 Author: prr Date: 2017-02-10 08:17 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/205e05380de6 Merge - src/java.base/share/classes/sun/security/provider/certpath/PKIXTimestampParameters.java - src/java.base/share/classes/sun/security/util/CertConstraintParameters.java - src/java.base/unix/classes/sun/nio/fs/DefaultFileSystemProvider.java ! src/java.desktop/share/classes/module-info.java - test/java/lang/StackWalker/CountLocalSlots.java - test/java/lang/StackWalker/LocalsCrash.java - test/java/lang/invoke/lambda/MetafactorySamReturnTest.java - test/java/lang/invoke/modules/ModuleAccessControlTest.java - test/java/lang/invoke/modules/src/m1/module-info.java - test/java/lang/invoke/modules/src/m1/p1/Main.java - test/java/lang/invoke/modules/src/m1/p1/Type1.java - test/java/lang/invoke/modules/src/m1/p2/Type2.java - test/java/lang/invoke/modules/src/m2/module-info.java - test/java/lang/invoke/modules/src/m2/q1/Type1.java - test/java/lang/invoke/modules/src/m2/q2/Type2.java Changeset: ed26eebc8c88 Author: mchung Date: 2017-02-10 10:26 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ed26eebc8c88 8174739: Rename JMOD section name for native libraries from native to lib Reviewed-by: alanb ! src/java.base/share/classes/jdk/internal/jmod/JmodFile.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/builder/DefaultImageBuilder.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/AbstractResourcePoolEntry.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ExcludeVMPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties ! test/tools/jlink/JLinkNegativeTest.java ! test/tools/jlink/plugins/ExcludeVMPluginTest.java ! test/tools/jmod/JmodTest.java Changeset: 71ae110c5efd Author: michaelm Date: 2017-02-10 21:58 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/71ae110c5efd 8174745: Httpclient source update for JDK 8 Reviewed-by: dfuchs ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/AsyncSSLDelegate.java ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/DefaultPublisher.java ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/HttpResponse.java ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/ResponseProcessors.java ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/SSLDelegate.java ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/internal/common/MinimalFuture.java ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/internal/common/Queue.java ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/internal/common/Utils.java ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/internal/websocket/FrameConsumer.java ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/internal/websocket/UTF8AccumulatingDecoder.java ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/internal/websocket/WebSocketImpl.java Changeset: ef6894aeb9fe Author: sherman Date: 2017-02-11 21:31 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ef6894aeb9fe 8165640: Enhance jar tool to allow module-info in versioned directories but not in base in modular multi-release jar files Reviewed-by: psandoz, mchung ! src/jdk.jartool/share/classes/sun/tools/jar/Main.java ! src/jdk.jartool/share/classes/sun/tools/jar/Validator.java ! test/tools/jar/mmrjar/Basic.java ! test/tools/jar/modularJar/Basic.java + test/tools/jar/modularJar/src/baz/jdk/test/baz/Baz.java Changeset: 4cda2699bf59 Author: mchung Date: 2017-02-12 16:45 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4cda2699bf59 8174740: RuntimeException: Module m's descriptor returns inconsistent package set Reviewed-by: alanb ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java ! test/tools/jlink/plugins/SystemModuleDescriptors/UserModuleTest.java ! test/tools/jlink/plugins/SystemModuleDescriptors/src/m1/module-info.java Changeset: db26f90a85f5 Author: skovalev Date: 2017-02-10 11:00 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/db26f90a85f5 8174194: Several java/lang tests failing due to undeclared module dependencies Reviewed-by: dfuchs, mchung ! test/java/lang/SecurityManager/CheckPackageAccess.java ! test/java/lang/StackTraceElement/WithClassLoaderName.java ! test/java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java ! test/java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java ! test/java/lang/management/ManagementFactory/DefaultManagementProviderTest.java ! test/java/lang/reflect/PublicMethods/PublicMethodsTest.java Changeset: a535648a6748 Author: alanb Date: 2017-02-13 08:11 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a535648a6748 Merge ! make/src/classes/build/tools/jigsaw/GenGraphs.java ! make/src/classes/build/tools/jigsaw/ModuleSummary.java ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/java/lang/IllegalCallerException.java ! src/java.base/share/classes/java/lang/Package.java ! src/java.base/share/classes/java/lang/SecurityManager.java ! src/java.base/share/classes/java/lang/StackTraceElement.java ! src/java.base/share/classes/java/lang/StackWalker.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/lang/module/Configuration.java ! src/java.base/share/classes/java/lang/module/FindException.java ! src/java.base/share/classes/java/lang/module/InvalidModuleDescriptorException.java ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java ! src/java.base/share/classes/java/lang/module/ModuleFinder.java ! src/java.base/share/classes/java/lang/module/ModuleReader.java ! src/java.base/share/classes/java/lang/module/ModuleReference.java ! src/java.base/share/classes/java/lang/module/ResolutionException.java ! src/java.base/share/classes/java/lang/module/ResolvedModule.java ! src/java.base/share/classes/java/lang/module/Resolver.java ! src/java.base/share/classes/java/lang/module/package-info.java ! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java ! src/java.base/share/classes/java/lang/reflect/Constructor.java ! src/java.base/share/classes/java/lang/reflect/Field.java ! src/java.base/share/classes/java/lang/reflect/InaccessibleObjectException.java ! src/java.base/share/classes/java/lang/reflect/Layer.java ! src/java.base/share/classes/java/lang/reflect/LayerInstantiationException.java ! src/java.base/share/classes/java/lang/reflect/Method.java ! src/java.base/share/classes/java/lang/reflect/Module.java ! src/java.base/share/classes/java/lang/reflect/Proxy.java ! src/java.base/share/classes/java/net/URLClassLoader.java ! src/java.base/share/classes/java/security/SecureClassLoader.java ! src/java.base/share/classes/java/util/ResourceBundle.java ! src/java.base/share/classes/java/util/ServiceLoader.java ! src/java.base/share/classes/java/util/spi/AbstractResourceBundleProvider.java ! src/java.base/share/classes/java/util/spi/ResourceBundleControlProvider.java ! src/java.base/share/classes/java/util/spi/ResourceBundleProvider.java ! src/java.base/share/classes/jdk/internal/jmod/JmodFile.java ! src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java ! src/java.base/share/classes/jdk/internal/loader/ResourceHelper.java ! src/java.base/share/classes/jdk/internal/misc/JavaLangAccess.java ! src/java.base/share/classes/jdk/internal/misc/JavaLangModuleAccess.java ! src/java.base/share/classes/jdk/internal/module/Builder.java ! src/java.base/share/classes/jdk/internal/module/Checks.java ! src/java.base/share/classes/jdk/internal/module/ClassFileAttributes.java ! src/java.base/share/classes/jdk/internal/module/ClassFileConstants.java ! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java ! src/java.base/share/classes/jdk/internal/module/ModuleInfo.java ! src/java.base/share/classes/jdk/internal/module/ModuleInfoExtender.java ! src/java.base/share/classes/jdk/internal/module/ModuleLoaderMap.java ! src/java.base/share/classes/jdk/internal/module/ModulePatcher.java ! src/java.base/share/classes/jdk/internal/module/ModulePath.java ! src/java.base/share/classes/jdk/internal/module/ModuleReferenceImpl.java ! src/java.base/share/classes/jdk/internal/module/ModuleReferences.java ! src/java.base/share/classes/jdk/internal/module/Modules.java ! src/java.base/share/classes/jdk/internal/module/SystemModuleFinder.java ! src/java.base/share/classes/jdk/internal/reflect/Reflection.java ! src/java.base/share/classes/module-info.java ! src/java.base/share/classes/sun/invoke/util/VerifyAccess.java ! src/java.base/share/classes/sun/launcher/LauncherHelper.java ! src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java - src/java.base/share/classes/sun/security/provider/certpath/PKIXTimestampParameters.java - src/java.base/share/classes/sun/security/util/CertConstraintParameters.java ! src/java.base/share/conf/security/java.security ! src/java.base/share/native/launcher/main.c ! src/java.base/share/native/libjli/args.c ! src/java.base/share/native/libjli/java.h ! src/java.desktop/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/java.desktop/share/classes/java/awt/Component.java ! src/java.desktop/share/classes/java/awt/Toolkit.java ! src/java.desktop/share/classes/javax/swing/JTable.java ! src/java.desktop/share/classes/module-info.java ! src/java.instrument/share/classes/java/lang/instrument/ClassFileTransformer.java ! src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java ! src/java.instrument/share/classes/module-info.java ! src/java.logging/share/classes/module-info.java ! src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnector.java ! src/java.management/share/classes/module-info.java ! src/java.naming/share/classes/module-info.java ! src/java.prefs/share/classes/module-info.java ! src/java.rmi/share/classes/module-info.java ! src/java.scripting/share/classes/module-info.java ! src/java.se.ee/share/classes/module-info.java ! src/java.se/share/classes/module-info.java ! src/java.security.jgss/share/classes/module-info.java ! src/java.security.sasl/share/classes/module-info.java ! src/java.smartcardio/share/classes/module-info.java ! src/java.sql.rowset/share/classes/module-info.java ! src/java.sql/share/classes/module-info.java ! src/java.transaction/share/classes/module-info.java ! src/java.xml.crypto/share/classes/module-info.java ! src/jdk.attach/share/classes/module-info.java - src/jdk.desktop/share/classes/jdk/awt/AWTUtils.java - src/jdk.desktop/share/classes/module-info.java ! src/jdk.internal.le/share/classes/module-info.java ! src/jdk.internal.opt/share/classes/module-info.java ! src/jdk.jartool/share/classes/sun/tools/jar/GNUStyleOptions.java ! src/jdk.jartool/share/classes/sun/tools/jar/Main.java ! src/jdk.jconsole/share/classes/sun/tools/jconsole/VMPanel.java ! src/jdk.jdi/share/classes/module-info.java ! src/jdk.jdwp.agent/share/classes/module-info.java ! src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage.properties ! src/jdk.jlink/share/classes/jdk/tools/jlink/builder/DefaultImageBuilder.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ResourcePoolConfiguration.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ExcludeVMPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties ! src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java ! src/jdk.management.agent/share/classes/jdk/internal/agent/Agent.java ! src/jdk.security.auth/share/classes/module-info.java ! src/jdk.security.jgss/share/classes/module-info.java ! test/ProblemList.txt ! test/TEST.groups - test/java/awt/jdk/TestJDKAWTUtils.java ! test/java/lang/Class/forName/modules/TestLayer.java ! test/java/lang/Class/forName/modules/src/m3/p3/NoAccess.java ! test/java/lang/SecurityManager/CheckPackageAccess.java ! test/java/lang/StackTraceElement/WithClassLoaderName.java - test/java/lang/StackWalker/CountLocalSlots.java ! test/java/lang/StackWalker/LocalsAndOperands.java - test/java/lang/StackWalker/LocalsCrash.java ! test/java/lang/invoke/AccessControlTest.java ! test/java/lang/invoke/DropLookupModeTest.java ! test/java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java ! test/java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java ! test/java/lang/invoke/MethodHandles/privateLookupIn/test/p/PrivateLookupInTests.java - test/java/lang/invoke/lambda/MetafactorySamReturnTest.java ! test/java/lang/invoke/modules/Driver.java ! test/java/lang/invoke/modules/m1/module-info.java ! test/java/lang/invoke/modules/m1/p1/Main.java ! test/java/lang/invoke/modules/m1/p1/Type1.java ! test/java/lang/invoke/modules/m1/p2/Type2.java ! test/java/lang/invoke/modules/m2/module-info.java ! test/java/lang/invoke/modules/m2/q1/Type1.java ! test/java/lang/invoke/modules/m2/q2/Type2.java ! test/java/lang/module/AutomaticModulesTest.java ! test/java/lang/module/ConfigurationTest.java ! test/java/lang/module/ModuleDescriptorTest.java ! test/java/lang/module/ModuleFinderTest.java ! test/java/lang/module/ModuleNamesTest.java ! test/java/lang/module/ModuleReader/ModuleReaderTest.java ! test/java/lang/module/ModuleReferenceTest.java ! test/java/lang/module/MultiReleaseJarTest.java ! test/java/lang/reflect/AccessibleObject/ModuleSetAccessibleTest.java ! test/java/lang/reflect/Layer/BasicLayerTest.java ! test/java/lang/reflect/Layer/LayerAndLoadersTest.java ! test/java/lang/reflect/Layer/LayerControllerTest.java ! test/java/lang/reflect/Module/AnnotationsTest.java ! test/java/lang/reflect/Module/BasicModuleTest.java ! test/java/lang/reflect/Proxy/ProxyClassAccessTest.java ! test/java/lang/reflect/Proxy/ProxyLayerTest.java ! test/java/security/modules/ModularTest.java ! test/java/time/TEST.properties ! test/java/util/ServiceLoader/modules/BadProvidersTest.java ! test/java/util/ServiceLoader/modules/Basic.java ! test/jdk/internal/reflect/CallerSensitive/CheckCSMs.java ! test/jdk/modules/etc/VerifyModuleDelegation.java ! test/jdk/modules/scenarios/container/src/container/container/Main.java ! test/tools/jar/mmrjar/Basic.java ! test/tools/jar/modularJar/Basic.java ! test/tools/jlink/JLinkNegativeTest.java ! test/tools/jlink/plugins/ExcludeVMPluginTest.java ! test/tools/jlink/plugins/SystemModuleDescriptors/UserModuleTest.java ! test/tools/jlink/plugins/SystemModuleDescriptors/src/m1/module-info.java ! test/tools/jmod/JmodTest.java ! test/tools/jmod/hashes/HashesTest.java From sanne at redhat.com Mon Feb 13 12:52:07 2017 From: sanne at redhat.com (Sanne Grinovero) Date: Mon, 13 Feb 2017 12:52:07 +0000 Subject: JAR searched on the classpath instead of the module path in Build #156 In-Reply-To: <404865d4-a933-dd9e-1869-a326b825a4a6@oracle.com> References: <000001d28534$01524c50$03f6e4f0$@yahoo.com> <404865d4-a933-dd9e-1869-a326b825a4a6@oracle.com> Message-ID: Hi Alexandru, please be aware that Hibernate to support Jigsaw is a work in progress. We had some successful builds (including test runs) some months ago, but we have yet to catch up on recent changes in OpenJDK. Progress for each Hibernate project can be monitored here: - http://ci.hibernate.org/view/JDK9/ (although we didn't upgrade to build 156 yet, investigating still some surprising changes) The issue you've found should probably be recorded on the Hibernate JIRA for project HHH: - https://hibernate.atlassian.net/projects/HHH/summary Thanks, Sanne On Sun, Feb 12, 2017 at 3:33 PM, Alan Bateman wrote: > On 12/02/2017 13:29, Alexandru Jecan wrote: > >> : >> >> >> I compile my application, create the modular JAR and then at runtime I get >> the error: >> >> Caused by: >> org.hibernate.boot.jaxb.internal.stax.XmlInfrastructureException: Unable to >> locate schema [org/hibernate/jpa/orm_2_0.xsd] via classpath >> >> >> Could you please tell me, why does it search for the JAR on the classpath >> since I moved the JAR to automatic modules ? >> >> I have run using the ?classpath and the ?module-path options at the same >> time. >> >> >> After that I took an older Jigsaw build (#141 and also #142). >> >> I performed exactly the same steps and it works perfectly. The error from >> above is not displayed any more. > > There are >1500 changes in builds 143-156. Is there any way that you can > bisect this and track down the first build where you see a problem? The > exception hints of something involving JAXB and a XML schema file. You don't > say if you are using the java.xml.bind module or the standalone JAXB on the > class path. In this area, I note that there was a big refresh of JAXB from > the upstream Metro project in jdk-9+146. In addition, there was a change to > the Xalan serializer in jdk-9+150 that have brought several regressions and > bug reports, the fixes for all issues aren't in JDK 9 yet. So anything to > narrow this down would be good. > > -Alan From guillaume at hibernate.org Mon Feb 13 13:34:28 2017 From: guillaume at hibernate.org (Guillaume Smet) Date: Mon, 13 Feb 2017 14:34:28 +0100 Subject: Java SE JSR 250 annotations module renamed to java.xml.ws.annotation? Message-ID: Hi, (Posting this on the list at the request of Rory O'Donnell) This morning I tried to upgrade our Hibernate Validator build and came across this issue: https://bugs.openjdk.java.net/browse/JDK-8173604 . As a lot of projects experimenting with the Early access builds of the JDK 9, we added --add-modules java.annotations.common to our build options. This doesn't work anymore as the Java SE JSR 250 annotations (@Generated, @PreDestroy, @PostConstruct, @Resource...) that were previously in a module called java.annotations.common were moved to a module called java.xml.ws.annotation as part of the aforementioned issue. The fix is easy, I just have to change my --add-modules directive but I started to wonder if there's some sort of misunderstanding here. As far as I understand it, these annotations are supposed to be common annotations available in the JDK (see JSR 250: Common Annotations for the JavaTM Platform). Some are used by a lot of projects out there: nearly every project based on generated code requires the @Generated annotation to be present as most tools generating code use it. I don't know why these annotations were hosted in the jaxws part of the source code to begin with but I don't think we can limit them to this usage. At the end, I'm wondering if these classes shouldn't be part of the default set of classes exposed without requiring an --add-modules option. Thanks for your feedback. -- Guillaume From claes.redestad at oracle.com Mon Feb 13 14:08:09 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 13 Feb 2017 15:08:09 +0100 Subject: Java SE JSR 250 annotations module renamed to java.xml.ws.annotation? In-Reply-To: References: Message-ID: <9f466f7c-c512-574c-ab54-8655d561418a@oracle.com> Hi Guillaume, On 02/13/2017 02:34 PM, Guillaume Smet wrote: > At the end, I'm wondering if these classes shouldn't be part of the default > set of classes exposed without requiring an --add-modules option. one of the main reasons why java.xml.ws.annotations is not resolved by default is that there are many projects out there with dependencies on various JSR 305 implementations[1], which is a non-final and dormant JSR which happen to clash with JSR 250 by adding more annotations to the same packages... thus if java.xml.ws.annotations is resolved at boot time using --add-modules then any project with a dependency on one of the rogue JSR 305 implementations is likely to break[2]. A perhaps less fragile alternative here is to not depend on the JDK-bundled java.xml.ws.annotations at all but instead depend directly on the JSR 250 API as published by the JCP[3] as an explicit dependency. Hope this helps! /Claes [1] https://jcp.org/en/jsr/detail?id=305 [2] See http://openjdk.java.net/jeps/261#EE-modules for more info [3] E.g.: https://mvnrepository.com/artifact/javax.annotation/jsr250-api/1.0 From david.lloyd at redhat.com Mon Feb 13 14:32:40 2017 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 13 Feb 2017 08:32:40 -0600 Subject: Java SE JSR 250 annotations module renamed to java.xml.ws.annotation? In-Reply-To: <9f466f7c-c512-574c-ab54-8655d561418a@oracle.com> References: <9f466f7c-c512-574c-ab54-8655d561418a@oracle.com> Message-ID: I think this is an error. It makes more sense to have the javax.annotation package exist in its own module. If the long-idle JSR 250 and specifications like it are really a concern, then this module should follow the pattern of all other such modules and be upgradeable. Note that until #AvoidConcealedPackageConflicts is resolved, AFAICT the suggestion of depending on the JSR 250 API can't work anyway if java.xml.ws.annotations is used because there will be two sets of the same package in the module system. This once again shines a bright light on a few key Jigsaw defects, and it's getting a bit frustrating watching requirements get reconned to compensate for implementation problems. This is purely a hack to make up for an implementation difficulty and makes no sense when framed from the perspective of the end user. Let's try to do better. On 02/13/2017 08:08 AM, Claes Redestad wrote: > Hi Guillaume, > > On 02/13/2017 02:34 PM, Guillaume Smet wrote: >> At the end, I'm wondering if these classes shouldn't be part of the >> default >> set of classes exposed without requiring an --add-modules option. > > one of the main reasons why java.xml.ws.annotations is not resolved > by default is that there are many projects out there with dependencies > on various JSR 305 implementations[1], which is a non-final and dormant > JSR which happen to clash with JSR 250 by adding more annotations to > the same packages... thus if java.xml.ws.annotations is resolved at > boot time using --add-modules then any project with a dependency on > one of the rogue JSR 305 implementations is likely to break[2]. > > A perhaps less fragile alternative here is to not depend on the > JDK-bundled java.xml.ws.annotations at all but instead depend directly > on the JSR 250 API as published by the JCP[3] as an explicit dependency. > > Hope this helps! > > /Claes > > [1] https://jcp.org/en/jsr/detail?id=305 > [2] See http://openjdk.java.net/jeps/261#EE-modules for more info > [3] E.g.: > https://mvnrepository.com/artifact/javax.annotation/jsr250-api/1.0 -- - DML From Alan.Bateman at oracle.com Mon Feb 13 14:34:38 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 13 Feb 2017 14:34:38 +0000 Subject: Java SE JSR 250 annotations module renamed to java.xml.ws.annotation? In-Reply-To: References: Message-ID: On 13/02/2017 13:34, Guillaume Smet wrote: > : > > This doesn't work anymore as the Java SE JSR 250 annotations (@Generated, > @PreDestroy, @PostConstruct, @Resource...) that were previously in a module > called java.annotations.common were moved to a module called > java.xml.ws.annotation as part of the aforementioned issue. > There will be a some shimmer in the module graph and names until things are final so anything depending on the names in the EA builds may need to deal with changes. Yes, it is mildly disruptive but hopefully not too many changes before JSR 379 and JDK 9 is final. > As far as I understand it, these annotations are supposed to be common > annotations available in the JDK (see JSR 250: Common Annotations for the > JavaTM Platform). Some are used by a lot of projects out there: nearly > every project based on generated code requires the @Generated annotation to > be present as most tools generating code use it. > > I don't know why these annotations were hosted in the jaxws part of the > source code to begin with but I don't think we can limit them to this usage. > > At the end, I'm wondering if these classes shouldn't be part of the default > set of classes exposed without requiring an --add-modules option. > The small subset of the JSR-250 defined "Common Annotations" that you see in Java SE is part of the web services stack that was added in Java SE 6. If it weren't for JAX-WS then these annotations would have no business being in Java SE or the JDK. The rational for why this module is not resolved by default is documented in JEP 261. For those that don't deploy with the Java EE version of these annotations then it does mean using `--add-modules java.xml.ws.annotation`. One thing to be aware of is that the JSR 379 EDR proposes to deprecate this module for removal and hopefully it can be removed in Java SE 10. -Alan From Alan.Bateman at oracle.com Mon Feb 13 14:49:46 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 13 Feb 2017 14:49:46 +0000 Subject: Java SE JSR 250 annotations module renamed to java.xml.ws.annotation? In-Reply-To: References: <9f466f7c-c512-574c-ab54-8655d561418a@oracle.com> Message-ID: On 13/02/2017 14:32, David M. Lloyd wrote: > I think this is an error. It makes more sense to have the > javax.annotation package exist in its own module. If the long-idle > JSR 250 and specifications like it are really a concern, then this > module should follow the pattern of all other such modules and be > upgradeable. It is its own module and it is upgradable. > > This once again shines a bright light on a few key Jigsaw defects, and > it's getting a bit frustrating watching requirements get reconned to > compensate for implementation problems. This is purely a hack to make > up for an implementation difficulty and makes no sense when framed > from the perspective of the end user. Let's try to do better. The technical debt here that a handful of APIs are "shared" between Java SE and Java EE. The first steps to addressing that technical debt are in the JSR 379 EDR. -Alan. From david.lloyd at redhat.com Mon Feb 13 14:58:23 2017 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 13 Feb 2017 08:58:23 -0600 Subject: Java SE JSR 250 annotations module renamed to java.xml.ws.annotation? In-Reply-To: References: <9f466f7c-c512-574c-ab54-8655d561418a@oracle.com> Message-ID: <669b5d0a-a600-60fa-b88f-823402e8e490@redhat.com> On 02/13/2017 08:49 AM, Alan Bateman wrote: > On 13/02/2017 14:32, David M. Lloyd wrote: > >> I think this is an error. It makes more sense to have the >> javax.annotation package exist in its own module. If the long-idle >> JSR 250 and specifications like it are really a concern, then this >> module should follow the pattern of all other such modules and be >> upgradeable. > It is its own module and it is upgradable. > >> >> This once again shines a bright light on a few key Jigsaw defects, and >> it's getting a bit frustrating watching requirements get reconned to >> compensate for implementation problems. This is purely a hack to make >> up for an implementation difficulty and makes no sense when framed >> from the perspective of the end user. Let's try to do better. > The technical debt here that a handful of APIs are "shared" between Java > SE and Java EE. The first steps to addressing that technical debt are in > the JSR 379 EDR. I would agree but for the problem of @Generated. Would that it had been put into java.lang.annotation to begin with! But the reality is that there has been a long-standing assumption that is broken with Java 9 that this class would be in the JDK, thus code generators have been free to include this annotation (which, on the surface, seems like a useful thing to do) without fear of introducing additional dependencies. Now it's a compilation error unless you either include a very non-intuitive module name, or else an external dependency. The authors of such code generators can likely figure this out, but users will almost certainly run into trouble. It's yet another bump without a very good reason. -- - DML From forax at univ-mlv.fr Mon Feb 13 14:59:58 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 13 Feb 2017 15:59:58 +0100 (CET) Subject: Java SE JSR 250 annotations module renamed to java.xml.ws.annotation? In-Reply-To: References: Message-ID: <2016060755.369657.1486997998047.JavaMail.zimbra@u-pem.fr> TLDR; we can't. In Java 6, we made the mistake to create what you can call twin packages, a package with few classes in the JDK and the same package with more classes including the classes already present in the JDK. The idea was that you can run an application using the JDK, in that case you have access the the small subset and you can also use the full packages in a container env. This approach fails once you have to update such kind of packages because the classes that can from the JDK (from the bootclasspath) can have a different versions from the classes that comes from the container (from the classpath). Note that this problem is just a variation of the problem of having two different versions of the same jars in the classpath. In the java module world, a package can comes from only one module (i.e. one modular jar). So with java 9, if you have different versions of the same jars, from the VM point of view different modular jars containing the same package, the VM fails when trying to resolve the module graph at startup. So with Java 9 you can only have one jar containing a package in the module graph. With Java 9, the JDK is modularized otherwise it will not be able to run modules from the module path, it also has to provide a way for classes on the classpath to see modules of the JDK otherwise your application will not be able to find java.lang.Object. For that, classes from classpath are put in a fake module named the unamed module. Now if the module containing the JSR 250 annotations is included by default in the module graph of the JDK, every projects using a container that will also use the JSR 250 (so the JSR 250 jars is in the classpath) will fail because the module of the JDK and unamed module will both have the same package. To solve that issue, the idea is that the JDK is released with a module containing the JSR 250 annotations but this module is not included in the root modules and you have to use --add-modules to add it in the root modules. so there are 3 cases: - your application is modular, in that case one module defines a dependency (with requires) on a module* containing the JSR 250 annotation and you have nothing to do. - your application uses a container that provides a jar containing the JSR 250 annotations in the classpath, you still have nothing to do. - your application uses the classpath and do not provide any jars containing the JSR 250 annotations, you can use --add-modules but be aware after some point the JDK will stop to provide this jar (the module is marked deprecated). perhaps another way to see this is to think that we made a mistake to include parts of the Java EE modules inside the JDK when releasing Java 6, and we are trying to fix that mistake now, which means removing those packages but because we are Java instead of removing them now, we made them accessible under a flag and we will remove them in Java 10. cheers, R?mi ----- Mail original ----- > De: "Guillaume Smet" > ?: jigsaw-dev at openjdk.java.net > Envoy?: Lundi 13 F?vrier 2017 14:34:28 > Objet: Java SE JSR 250 annotations module renamed to java.xml.ws.annotation? > Hi, > > (Posting this on the list at the request of Rory O'Donnell) > > This morning I tried to upgrade our Hibernate Validator build and came > across this issue: > https://bugs.openjdk.java.net/browse/JDK-8173604 . > > As a lot of projects experimenting with the Early access builds of the JDK > 9, we added --add-modules java.annotations.common to our build options. > > This doesn't work anymore as the Java SE JSR 250 annotations (@Generated, > @PreDestroy, @PostConstruct, @Resource...) that were previously in a module > called java.annotations.common were moved to a module called > java.xml.ws.annotation as part of the aforementioned issue. > > The fix is easy, I just have to change my --add-modules directive but I > started to wonder if there's some sort of misunderstanding here. > > As far as I understand it, these annotations are supposed to be common > annotations available in the JDK (see JSR 250: Common Annotations for the > JavaTM Platform). Some are used by a lot of projects out there: nearly > every project based on generated code requires the @Generated annotation to > be present as most tools generating code use it. > > I don't know why these annotations were hosted in the jaxws part of the > source code to begin with but I don't think we can limit them to this usage. > > At the end, I'm wondering if these classes shouldn't be part of the default > set of classes exposed without requiring an --add-modules option. > > Thanks for your feedback. > > -- > Guillaume From david.lloyd at redhat.com Mon Feb 13 15:10:35 2017 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 13 Feb 2017 09:10:35 -0600 Subject: Java SE JSR 250 annotations module renamed to java.xml.ws.annotation? In-Reply-To: <669b5d0a-a600-60fa-b88f-823402e8e490@redhat.com> References: <9f466f7c-c512-574c-ab54-8655d561418a@oracle.com> <669b5d0a-a600-60fa-b88f-823402e8e490@redhat.com> Message-ID: On 02/13/2017 08:58 AM, David M. Lloyd wrote: > On 02/13/2017 08:49 AM, Alan Bateman wrote: >> On 13/02/2017 14:32, David M. Lloyd wrote: >> >>> I think this is an error. It makes more sense to have the >>> javax.annotation package exist in its own module. If the long-idle >>> JSR 250 and specifications like it are really a concern, then this >>> module should follow the pattern of all other such modules and be >>> upgradeable. >> It is its own module and it is upgradable. >> >>> >>> This once again shines a bright light on a few key Jigsaw defects, and >>> it's getting a bit frustrating watching requirements get reconned to >>> compensate for implementation problems. This is purely a hack to make >>> up for an implementation difficulty and makes no sense when framed >>> from the perspective of the end user. Let's try to do better. >> The technical debt here that a handful of APIs are "shared" between Java >> SE and Java EE. The first steps to addressing that technical debt are in >> the JSR 379 EDR. > > I would agree but for the problem of @Generated. Would that it had been > put into java.lang.annotation to begin with! But the reality is that > there has been a long-standing assumption that is broken with Java 9 > that this class would be in the JDK, thus code generators have been free > to include this annotation (which, on the surface, seems like a useful > thing to do) without fear of introducing additional dependencies. Now > it's a compilation error unless you either include a very non-intuitive > module name, or else an external dependency. The authors of such code > generators can likely figure this out, but users will almost certainly > run into trouble. It's yet another bump without a very good reason. Here is what I said to Andrew Haley (our JSR 379 rep): > I think that if this module is to be present in the JDK, it should retain its previous name ("java.annotations.common"). If the module is to be deprecated for removal from the platform (i.e. permanently replaced with an external dependency), then the @Generated annotation should be deprecated from JSR-250 and its related specifications, and also (ideally) moved into java.lang.annotation if it is deemed still useful, because such an annotation should always be present in the JDK. -- - DML From aph at redhat.com Mon Feb 13 15:11:48 2017 From: aph at redhat.com (Andrew Haley) Date: Mon, 13 Feb 2017 15:11:48 +0000 Subject: Java SE JSR 250 annotations module renamed to java.xml.ws.annotation? In-Reply-To: References: Message-ID: On 13/02/17 14:34, Alan Bateman wrote: > The small subset of the JSR-250 defined "Common Annotations" that you > see in Java SE is part of the web services stack that was added in Java > SE 6. If it weren't for JAX-WS then these annotations would have no > business being in Java SE or the JDK. Well, okay, but they have been advertised as "Common Annotations" for ten years now. It's a bit unconvincing to say "Yes, but we didn't really mean it." Andrew. From guillaume at hibernate.org Mon Feb 13 15:43:36 2017 From: guillaume at hibernate.org (Guillaume Smet) Date: Mon, 13 Feb 2017 16:43:36 +0100 Subject: Java SE JSR 250 annotations module renamed to java.xml.ws.annotation? In-Reply-To: <2016060755.369657.1486997998047.JavaMail.zimbra@u-pem.fr> References: <2016060755.369657.1486997998047.JavaMail.zimbra@u-pem.fr> Message-ID: Hi R?mi, (replied to you but it's more of a general answer to the consensus) On Mon, Feb 13, 2017 at 3:59 PM, Remi Forax wrote: > so there are 3 cases: > - your application is modular, in that case one module defines a > dependency (with requires) on a module* containing the JSR 250 annotation > and you have nothing to do. > - your application uses a container that provides a jar containing the JSR > 250 annotations in the classpath, you still have nothing to do. > - your application uses the classpath and do not provide any jars > containing the JSR 250 annotations, you can use --add-modules but be aware > after some point the JDK will stop to provide this jar (the module is > marked deprecated). > > perhaps another way to see this is to think that we made a mistake to > include parts of the Java EE modules inside the JDK when releasing Java 6, > and we are trying to fix that mistake now, which means removing those > packages but because we are Java instead of removing them now, we made them > accessible under a flag and we will remove them in Java 10. > I can understand this point of view but...: - if we are willing to deprecate this, maybe it would be better not to let the --add-modules fix spread in all the projects everywhere and maybe a clear statement about the future of it would be nice - I may have missed it though - see what they did for pax-exam for instance: https://github.com/ops4j/org.ops4j.pax.exam2/blob/master/containers/pax-exam-container-karaf/src/main/java/org/ops4j/pax/exam/karaf/container/internal/runner/KarafJavaRunner.java#L63 for instance; - from what I understand, there are 2 types of annotations in this module: @Generated and annotations related to injection/lifecycle. While I would agree to add a dependency for the latter, I find it pretty weird to add a dependency for @Generated. Or maybe, we should just say to the Java world "don't use the @Generated annotation when you generate code and please upgrade all the tooling out there to not depend on it". - fixing a mistake is always a good thing but as stated by Andrew, they were advertised as common annotations and part of the JDK so it's definitely a big change if they get deprecated and removed - even as a temporary workaround, it's really weird to have to require a module named java.xml.ws.annotation for that. It does not really make sense from an end user perspective. - as I understand it, the idea is that the new java.xml.ws.annotation module should basically be considered a private one and should not really be used anywhere thus its name? - the only future-proof solution proposed is to depend on the JSR 250 API jar - which doesn't look very cool just for @Generated - or get all the Java tooling out there to remove the usage of the @Generated annotation? Creating a new @Generated annotation will take years to be used in the real world, considering everyone will want to keep the backwards compatibility with Java 8 for a while. Not sure there's an easy way out but I think these are real concerns that should be addressed somehow. -- Guillaume From forax at univ-mlv.fr Mon Feb 13 15:45:41 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 13 Feb 2017 16:45:41 +0100 (CET) Subject: Java SE JSR 250 annotations module renamed to java.xml.ws.annotation? In-Reply-To: References: Message-ID: <911550935.440237.1487000741556.JavaMail.zimbra@u-pem.fr> Perhaps, it's a problem of communication, what about "As an effort to make Java on diet, Java 10 will not be shipped with modules corba, jaxb or common annnotations, for Java 9, you can use a command line option to have access to those deprecated modules." R?mi ----- Mail original ----- > De: "Andrew Haley" > ?: jigsaw-dev at openjdk.java.net > Envoy?: Lundi 13 F?vrier 2017 16:11:48 > Objet: Re: Java SE JSR 250 annotations module renamed to java.xml.ws.annotation? > On 13/02/17 14:34, Alan Bateman wrote: >> The small subset of the JSR-250 defined "Common Annotations" that you >> see in Java SE is part of the web services stack that was added in Java >> SE 6. If it weren't for JAX-WS then these annotations would have no >> business being in Java SE or the JDK. > > Well, okay, but they have been advertised as "Common Annotations" for > ten years now. It's a bit unconvincing to say "Yes, but we didn't > really mean it." > > Andrew. From Alan.Bateman at oracle.com Mon Feb 13 15:46:58 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 13 Feb 2017 15:46:58 +0000 Subject: Java SE JSR 250 annotations module renamed to java.xml.ws.annotation? In-Reply-To: References: Message-ID: On 13/02/2017 15:11, Andrew Haley wrote: > On 13/02/17 14:34, Alan Bateman wrote: >> The small subset of the JSR-250 defined "Common Annotations" that you >> see in Java SE is part of the web services stack that was added in Java >> SE 6. If it weren't for JAX-WS then these annotations would have no >> business being in Java SE or the JDK. > Well, okay, but they have been advertised as "Common Annotations" for > ten years now. It's a bit unconvincing to say "Yes, but we didn't > really mean it." > The name is unfortunate, a woeful choice, esp. in the context of Java SE and JDK where most of annotations are just not relevant. This is what lead to the defining the subset for JAX-WS. Anyway, the proposal is to deprecate this module in Java SE 9 and hopefully remove it in the future, Java SE 10 if possible. That is for JSR 379 and the JSR for Java SE 10 to decide of course. -Alan. From guillaume at hibernate.org Mon Feb 13 15:56:50 2017 From: guillaume at hibernate.org (Guillaume Smet) Date: Mon, 13 Feb 2017 16:56:50 +0100 Subject: Java SE JSR 250 annotations module renamed to java.xml.ws.annotation? In-Reply-To: References: Message-ID: Hi Alan, On Mon, Feb 13, 2017 at 4:46 PM, Alan Bateman wrote: > The name is unfortunate, a woeful choice, esp. in the context of Java SE > and JDK where most of annotations are just not relevant. This is what lead > to the defining the subset for JAX-WS. > > Anyway, the proposal is to deprecate this module in Java SE 9 and > hopefully remove it in the future, Java SE 10 if possible. That is for JSR > 379 and the JSR for Java SE 10 to decide of course. > So basically, your position is that we should update all the Java tooling out there to remove the usage of the @Generated annotation? Because I don't think introducing a dependency to the JSR 250 API jar everywhere is a good thing. If so, as mentioned by David, it would be nice to provide something else as it's considered a useful marker and is used by a lot of tools. And even if we do so, the transition will be chaotic to say the least. -- Guillaume From Alan.Bateman at oracle.com Mon Feb 13 16:12:43 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 13 Feb 2017 16:12:43 +0000 Subject: Java SE JSR 250 annotations module renamed to java.xml.ws.annotation? In-Reply-To: References: Message-ID: <6536d7a6-703f-4dcd-35e7-331e672ac5a9@oracle.com> On 13/02/2017 15:56, Guillaume Smet wrote: > > So basically, your position is that we should update all the Java > tooling out there to remove the usage of the @Generated annotation? > Because I don't think introducing a dependency to the JSR 250 API jar > everywhere is a good thing. > > If so, as mentioned by David, it would be nice to provide something > else as it's considered a useful marker and is used by a lot of tools. > And even if we do so, the transition will be chaotic to say the least. > I agree that @Generated is awkward but I haven't suggested removing it. It would be useful to go through a few examples as it may be that ACC_SYNTHETIC is more appropriate for some of these cases. -Alan From sundararajan.athijegannathan at oracle.com Mon Feb 13 17:03:31 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 13 Feb 2017 22:33:31 +0530 Subject: RFR 8174209: Renumber the compress levels Message-ID: <58A1E6E3.2070301@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8174209/webrev/ for https://bugs.openjdk.java.net/browse/JDK-8174209 Thanks, -Sundar From guillaume at hibernate.org Mon Feb 13 16:58:13 2017 From: guillaume at hibernate.org (Guillaume Smet) Date: Mon, 13 Feb 2017 17:58:13 +0100 Subject: Java SE JSR 250 annotations module renamed to java.xml.ws.annotation? In-Reply-To: <6536d7a6-703f-4dcd-35e7-331e672ac5a9@oracle.com> References: <6536d7a6-703f-4dcd-35e7-331e672ac5a9@oracle.com> Message-ID: On Mon, Feb 13, 2017 at 5:12 PM, Alan Bateman wrote: > I agree that @Generated is awkward but I haven't suggested removing it. What do you suggest then? As far as I understood you, you were suggesting removing the module in Java 10 so the @Generated annotation would also be gone? Or did I misunderstand? > It would be useful to go through a few examples as it may be that > ACC_SYNTHETIC is more appropriate for some of these cases. > Not really. == ACC_SYNTHETIC Quote from the doc: "A class may be marked with the ACC_SYNTHETIC flag to indicate that it was generated by a compiler and does not appear in source code." == @Generated >From the javadoc: * The Generated annotation is used to mark source code that has been generated. * It can also be used to differentiate user written code from generated code * in a single file. When used, the value element must have the name of the * code generator. The recommended convention is to use the fully qualified * name of the code generator in the value field . In our case, the class is not generated by the compiler and it does appear in the source code. So it's really @Generated that we want. It's a way to document which code generator has generated the code and when. It has been created for exactly this purpose. Here are a couple of projects using it: - QueryDSL - https://github.com/immutables/immutables - https://thrift.apache.org/ - JBoss Logging - jOOQ - Bindgen And, for instance, there are static analyzers which rely on it: e.g. with https://github.com/google/error-prone, classes marked with @Generated do not report warnings. This is from a 2 minutes search on the Internet and from tools used during my career. There are a lot more out there. -- Guillaume From forax at univ-mlv.fr Mon Feb 13 17:06:10 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 13 Feb 2017 18:06:10 +0100 (CET) Subject: Java SE JSR 250 annotations module renamed to java.xml.ws.annotation? In-Reply-To: <6536d7a6-703f-4dcd-35e7-331e672ac5a9@oracle.com> References: <6536d7a6-703f-4dcd-35e7-331e672ac5a9@oracle.com> Message-ID: <791080188.490519.1487005570743.JavaMail.zimbra@u-pem.fr> ACC_SYNTHETIC is a binary annotation/attribute/value, not a source one and synthetic members are not visible from the compiler point of view (think bridges by example). ACC_MANDATED can be used (again only in classfiles) but you have a good chance to be tracked and killed by Alex Buckley :) R?mi ----- Mail original ----- > De: "Alan Bateman" > ?: "Guillaume Smet" > Cc: jigsaw-dev at openjdk.java.net > Envoy?: Lundi 13 F?vrier 2017 17:12:43 > Objet: Re: Java SE JSR 250 annotations module renamed to java.xml.ws.annotation? > On 13/02/2017 15:56, Guillaume Smet wrote: > >> >> So basically, your position is that we should update all the Java >> tooling out there to remove the usage of the @Generated annotation? >> Because I don't think introducing a dependency to the JSR 250 API jar >> everywhere is a good thing. >> >> If so, as mentioned by David, it would be nice to provide something >> else as it's considered a useful marker and is used by a lot of tools. >> And even if we do so, the transition will be chaotic to say the least. >> > I agree that @Generated is awkward but I haven't suggested removing it. > It would be useful to go through a few examples as it may be that > ACC_SYNTHETIC is more appropriate for some of these cases. > > -Alan From peter.levart at gmail.com Mon Feb 13 17:08:00 2017 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 13 Feb 2017 18:08:00 +0100 Subject: Confusing error message for inner non-public service provider In-Reply-To: <92b56a2d-89ef-cb6d-82b7-d8efb928269e@oracle.com> References: <5898F31A.1010101@oracle.com> <589A1E45.3060604@oracle.com> <92b56a2d-89ef-cb6d-82b7-d8efb928269e@oracle.com> Message-ID: <9359b569-4a74-323c-03d7-4c36d4778429@gmail.com> Hi, Just wanted to note that the confusing javac error message is not specific to services and service providers. Take the following example: src/moda/module-info.java: module moda { exports pkga; } src/moda/pkga/Outer.java: package pkga; class Outer { public static class Untouchable { public static void touch() { throw new AssertionError("Can't touch this!"); } } } src/modb/module-info.java: module modb { requires moda; } src/modb/pkgb/Intruder.java: package pkgb; public class Intruder { public static void main(String[] args) { pkga.Outer.Untouchable.touch(); } } $ javac -d out --module-path out --module-source-path src `find src -name '*.java'` src/modb/pkgb/Intruder.java:6: error: package pkga is not visible pkga.Outer.Untouchable.touch(); ^ (package pkga is declared in module moda, which does not export it to module modb) 1 error Regards, Peter On 02/09/2017 11:49 PM, Vicente Romero wrote: > Hi Alex, > > Just to double check, the right javac behavior in this case should be > to issue similar errors in both cases like: > > some position here: error: ServiceImpl is not public in > com.example.internal; cannot be accessed from outside package > some other position here: error: Outer.ServiceImpl is not public in > com.example.internal; cannot be accessed from outside package > > without mentioning in any case anything about visibility right? > > Thanks, > Vicente > > > On 02/07/2017 02:21 PM, Alex Buckley wrote: >> On 2/7/2017 1:11 AM, Gunnar Morling wrote: >>> --- >>> package com.example; >>> public interface SomeService { >>> public void foo(); >>> } >>> --- >>> package com.example.internal; >>> class Outer { >>> >>> public static class ServiceImpl implements >>> com.example.SomeService { >>> public ServiceImpl() {} >>> public void foo() {} >>> } >>> } >>> --- >>> package com.example.internal; >>> class ServiceImpl implements com.example.SomeService { >>> public ServiceImpl() {} >>> public void foo() {} >>> } >>> --- >>> module com.example { >>> exports com.example; >>> provides com.example.SomeService with >>> com.example.internal.ServiceImpl; >>> provides com.example.SomeService with >>> com.example.internal.Outer.ServiceImpl; >>> } >>> --- >>> >>> Essentially, I'm wondering: >>> >>> * Why Outer.ServiceImpl triggers the error about package visibility >>> while ServiceImpl doesn't (I had a look at the EDR JLS, but I couldn't >>> find an explanation for that, happy about any specific pointers). >>> * Why Outer.ServiceImpl triggers "does not have a default constructor" >>> (ServiceImpl does not). Maybe a hint would be nice that is caused by >>> Outer not having public access. >> >> Thanks for showing the code. Since everything in the same module, >> package visibility is not relevant and javac shouldn't mention it. >> >> I suspect that javac is getting tripped up by the fact that >> Outer.ServiceImpl is declared 'public' (as the JLS and ServiceLoader >> both demand) but it isn't widely accessible, even within the >> com.example module, due to Outer's default (package) access. I >> believe the JLS and ServiceLoader rules are correct, so it's a javac >> bug. >> >> Alex > From Alan.Bateman at oracle.com Mon Feb 13 17:10:24 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 13 Feb 2017 17:10:24 +0000 Subject: Java SE JSR 250 annotations module renamed to java.xml.ws.annotation? In-Reply-To: References: <6536d7a6-703f-4dcd-35e7-331e672ac5a9@oracle.com> Message-ID: <2aaefa24-8f78-ce56-f5ee-8f1118fde506@oracle.com> On 13/02/2017 16:58, Guillaume Smet wrote: > On Mon, Feb 13, 2017 at 5:12 PM, Alan Bateman > wrote: > > I agree that @Generated is awkward but I haven't suggested > removing it. > > > What do you suggest then? As far as I understood you, you were > suggesting removing the module in Java 10 so the @Generated annotation > would also be gone? Or did I misunderstand? That is the proposal. If it goes ahead then it means that tools that rely on these annotations in the JDK would need to deploy the standalone version on the class path or as a module on the module path. -Alan From guillaume at hibernate.org Mon Feb 13 17:17:47 2017 From: guillaume at hibernate.org (Guillaume Smet) Date: Mon, 13 Feb 2017 18:17:47 +0100 Subject: Java SE JSR 250 annotations module renamed to java.xml.ws.annotation? In-Reply-To: <2aaefa24-8f78-ce56-f5ee-8f1118fde506@oracle.com> References: <6536d7a6-703f-4dcd-35e7-331e672ac5a9@oracle.com> <2aaefa24-8f78-ce56-f5ee-8f1118fde506@oracle.com> Message-ID: On Mon, Feb 13, 2017 at 6:10 PM, Alan Bateman wrote: > On 13/02/2017 16:58, Guillaume Smet wrote: > > On Mon, Feb 13, 2017 at 5:12 PM, Alan Bateman > wrote: > >> I agree that @Generated is awkward but I haven't suggested removing it. > > > What do you suggest then? As far as I understood you, you were suggesting > removing the module in Java 10 so the @Generated annotation would also be > gone? Or did I misunderstand? > > That is the proposal. If it goes ahead then it means that tools that rely > on these annotations in the JDK would need to deploy the standalone version > on the class path or as a module on the module path. > Yeah, so basically, it would end up with http://hg.openjdk.java.net/code-tools/jmh/rev/d74b2861222c . I don't think it's the best possible outcome for this useful annotation. -- Guillaume From Alan.Bateman at oracle.com Mon Feb 13 17:25:51 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 13 Feb 2017 17:25:51 +0000 Subject: RFR 8174209: Renumber the compress levels In-Reply-To: <58A1E6E3.2070301@oracle.com> References: <58A1E6E3.2070301@oracle.com> Message-ID: <53548e10-4444-ddd3-34e1-e1170779b7d6@oracle.com> On 13/02/2017 17:03, Sundararajan Athijegannathan wrote: > Please review http://cr.openjdk.java.net/~sundar/8174209/webrev/ for > https://bugs.openjdk.java.net/browse/JDK-8174209 This looks okay to me. -Alan From forax at univ-mlv.fr Mon Feb 13 17:30:30 2017 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Mon, 13 Feb 2017 18:30:30 +0100 (CET) Subject: Java SE JSR 250 annotations module renamed to java.xml.ws.annotation? In-Reply-To: References: <2016060755.369657.1486997998047.JavaMail.zimbra@u-pem.fr> Message-ID: <682261532.497891.1487007030352.JavaMail.zimbra@u-pem.fr> > De: "Guillaume Smet" > ?: "Remi Forax" > Cc: jigsaw-dev at openjdk.java.net > Envoy?: Lundi 13 F?vrier 2017 16:43:36 > Objet: Re: Java SE JSR 250 annotations module renamed to java.xml.ws.annotation? > Hi R?mi, > (replied to you but it's more of a general answer to the consensus) > On Mon, Feb 13, 2017 at 3:59 PM, Remi Forax < forax at univ-mlv.fr > wrote: >> so there are 3 cases: >> - your application is modular, in that case one module defines a dependency >> (with requires) on a module* containing the JSR 250 annotation and you have >> nothing to do. >> - your application uses a container that provides a jar containing the JSR 250 >> annotations in the classpath, you still have nothing to do. >> - your application uses the classpath and do not provide any jars containing the >> JSR 250 annotations, you can use --add-modules but be aware after some point >> the JDK will stop to provide this jar (the module is marked deprecated). >> perhaps another way to see this is to think that we made a mistake to include >> parts of the Java EE modules inside the JDK when releasing Java 6, and we are >> trying to fix that mistake now, which means removing those packages but because >> we are Java instead of removing them now, we made them accessible under a flag >> and we will remove them in Java 10. > I can understand this point of view but...: > - if we are willing to deprecate this, maybe it would be better not to let the > --add-modules fix spread in all the > projects everywhere and maybe a clear statement about the future of it would be > nice - I may have missed it though - see what they did for pax-exam for > instance: > https://github.com/ops4j/org.ops4j.pax.exam2/blob/master/containers/pax-exam-container-karaf/src/main/java/org/ops4j/pax/exam/karaf/container/internal/runner/KarafJavaRunner.java#L63 > for instance; i agree, > - from what I understand, there are 2 types of annotations in this module: > @Generated and annotations related to injection/lifecycle. While I would agree > to add a dependency for the latter, I find it pretty weird to add a dependency > for @Generated. Or maybe, we should just say to the Java world "don't use the > @Generated annotation when you generate code and please upgrade all the tooling > out there to not depend on it". > - fixing a mistake is always a good thing but as stated by Andrew, they were > advertised as common annotations and part of the JDK so it's definitely a big > change if they get deprecated and removed > - even as a temporary workaround, it's really weird to have to require a module > named java.xml.ws.annotation for that. It does not really make sense from an > end user perspective. the module name reflect the fact that it's a part of jax-ws and not annotations that you can use for other things. > - as I understand it, the idea is that the new java.xml.ws.annotation module > should basically be considered a private one and should not really be used > anywhere thus its name? > - the only future-proof solution proposed is to depend on the JSR 250 API jar - > which doesn't look very cool just for @Generated - or get all the Java tooling > out there to remove the usage of the @Generated annotation? > Creating a new @Generated annotation will take years to be used in the real > world, considering everyone will want to keep the backwards compatibility with > Java 8 for a while. > Not sure there's an easy way out but I think these are real concerns that should > be addressed somehow. I'm not sure we have to introduce a replacement for @Generated, i maybe wrong but the retention of this annotation is the source, so it's an indication for the developer more than anything else, so each framework can come with its own annotation and in my opinion, it will make the dependencies more clear. That's said i'm not a big fan of generated source codes, asking users to provide interfaces and implements the corresponding classes at runtime like by example spring boot does is more convenient IMO. > -- > Guillaume R?mi From gunnar at hibernate.org Mon Feb 13 17:49:05 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Mon, 13 Feb 2017 18:49:05 +0100 Subject: Compiling classes for multi-release JAR with module-info.java In-Reply-To: References: Message-ID: > the reason you are running into issues is > because the second javac command is essentially compiling a module with > references to types on the class path. Shouldn't this be supported, though? I.e. is the observed behavior a bug and the contents from the given classpath should actually be available for this compilation (this is how I interpret http://openjdk.java.net/jeps/261)? Or is this behavior intended and the given classpath is ignored in presence of a module-info.java? In that case a warning about the classpath being ignored would be nice. What you suggest works for the given example, I'm not sure how it'd look if the module-info.java had Java 9 specific references (e.g. a provided service). 2017-02-11 18:40 GMT+01:00 Alan Bateman : > On 10/02/2017 23:06, Gunnar Morling wrote: > >> : >> >> If I don't have a module descriptor things work fine: >> >> javac --source-path=src/main/java -d target/classes --release 8 >> $(find src/main/java -name "*.java") >> javac --source-path=src/main/java9 -cp target/classes -d >> target/classes-java9 --release 9 $(find src/main/java9 -name "*.java") >> jar --create --file mr.jar -C target/classes . --release 9 -C >> target/classes-java9 . >> >> Specifically, the second javac call picks up the (shared) class file >> for "Version" from the classpath by pointing to the output directory >> of the first compilation. >> >> Things fail when adding a module descriptor: >> >> --- src/main/java9/module-info.java >> module com.example { >> } >> --- > > It is complicated but I think the reason you are running into issues is > because the second javac command is essentially compiling a module with > references to types on the class path. > > If you move the module-info.java to the top-level directory directory then I > would expect this should work: > > javac --release 8 -d target/classes src/main/java/com/example/A.java > src/main/java/com/example/Version.java > javac -d target/classes src/main/java/module-info.java > javac -d target/classes-java9 -cp target/classes > src/main/java9/com/example/A.java > jar --create --file mr.jar -C target/classes . --release 9 -C > target/classes-java9 . > > Jon might have other suggestions. > > -Alan From guillaume at hibernate.org Mon Feb 13 17:55:33 2017 From: guillaume at hibernate.org (Guillaume Smet) Date: Mon, 13 Feb 2017 18:55:33 +0100 Subject: Java SE JSR 250 annotations module renamed to java.xml.ws.annotation? In-Reply-To: <682261532.497891.1487007030352.JavaMail.zimbra@u-pem.fr> References: <2016060755.369657.1486997998047.JavaMail.zimbra@u-pem.fr> <682261532.497891.1487007030352.JavaMail.zimbra@u-pem.fr> Message-ID: > > I'm not sure we have to introduce a replacement for @Generated, i maybe > wrong but the retention of this annotation is the source, so it's an > indication for the developer more than anything else, so each framework can > come with its own annotation and in my opinion, it will make the > dependencies more clear. > It's an indication for the developer, for the users of the library using it and for tools analyzing the source code. The whole point of it was to have a common annotation used by all code generators so that tools could rely on it. See my example about error-prone in a previous email. I don't see how having a gazillion of @Generated annotations - one per project - would help and would make it useful. See the introduction of the JSR, I can't paraphrase it better: it was the whole purpose of it. -- Guillaume From denis.kononenko at oracle.com Mon Feb 13 17:58:12 2017 From: denis.kononenko at oracle.com (Denis Kononenko) Date: Mon, 13 Feb 2017 09:58:12 -0800 (PST) Subject: [9] RFR: 8169715: jimage fails with IAE when attempts to inspect an empty file Message-ID: <9de28ff1-30b3-4a66-8b95-8469a58a55a0@default> Hi, Optimized buffer's capacity checks. WEBREV: http://cr.openjdk.java.net/~dkononenko/8169715/webrev.02 > > Could please someone review the fix for JDK-8169715. > > The problem occurs when jimage tool is attempting to read an empty or > incomplete image. The current implementation works with ByteBuffer and > always relies on that there's enough data to inspect the image. This > results in IAE inside of BasicImageReader.slice method when the buffer > is smaller then it's expected. > > I added a few checks to avoid IAE and throw IOException with a more > descriptive text. > > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8169715 > WEBREV: http://cr.openjdk.java.net/~dkononenko/8169715/webrev.01 > > Thank you, > Denis. Thank you, Denis. From james.laskey at oracle.com Mon Feb 13 18:01:44 2017 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Mon, 13 Feb 2017 14:01:44 -0400 Subject: [9] RFR: 8169715: jimage fails with IAE when attempts to inspect an empty file In-Reply-To: <9de28ff1-30b3-4a66-8b95-8469a58a55a0@default> References: <9de28ff1-30b3-4a66-8b95-8469a58a55a0@default> Message-ID: +1 > On Feb 13, 2017, at 1:58 PM, Denis Kononenko wrote: > > > Hi, > > Optimized buffer's capacity checks. > > WEBREV: http://cr.openjdk.java.net/~dkononenko/8169715/webrev.02 > >> >> Could please someone review the fix for JDK-8169715. >> >> The problem occurs when jimage tool is attempting to read an empty or >> incomplete image. The current implementation works with ByteBuffer and >> always relies on that there's enough data to inspect the image. This >> results in IAE inside of BasicImageReader.slice method when the buffer >> is smaller then it's expected. >> >> I added a few checks to avoid IAE and throw IOException with a more >> descriptive text. >> >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8169715 >> WEBREV: http://cr.openjdk.java.net/~dkononenko/8169715/webrev.01 >> >> Thank you, >> Denis. > > Thank you, > Denis. From andrey.x.nazarov at oracle.com Mon Feb 13 18:05:10 2017 From: andrey.x.nazarov at oracle.com (Andrey Nazarov) Date: Mon, 13 Feb 2017 21:05:10 +0300 Subject: [9] RFR: 8169715: jimage fails with IAE when attempts to inspect an empty file In-Reply-To: <9de28ff1-30b3-4a66-8b95-8469a58a55a0@default> References: <9de28ff1-30b3-4a66-8b95-8469a58a55a0@default> Message-ID: <619AD863-FF35-43DE-9A85-62034B43A049@oracle.com> Looks good > On 13 Feb 2017, at 20:58, Denis Kononenko wrote: > > > Hi, > > Optimized buffer's capacity checks. > > WEBREV: http://cr.openjdk.java.net/~dkononenko/8169715/webrev.02 > >> >> Could please someone review the fix for JDK-8169715. >> >> The problem occurs when jimage tool is attempting to read an empty or >> incomplete image. The current implementation works with ByteBuffer and >> always relies on that there's enough data to inspect the image. This >> results in IAE inside of BasicImageReader.slice method when the buffer >> is smaller then it's expected. >> >> I added a few checks to avoid IAE and throw IOException with a more >> descriptive text. >> >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8169715 >> WEBREV: http://cr.openjdk.java.net/~dkononenko/8169715/webrev.01 >> >> Thank you, >> Denis. > > Thank you, > Denis. From claes.redestad at oracle.com Mon Feb 13 18:10:16 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 13 Feb 2017 19:10:16 +0100 Subject: RFR 8174209: Renumber the compress levels In-Reply-To: <58A1E6E3.2070301@oracle.com> References: <58A1E6E3.2070301@oracle.com> Message-ID: <42cd21dd-8b5a-3a88-3592-9b45f6a23faa@oracle.com> +1! /Claes On 2017-02-13 18:03, Sundararajan Athijegannathan wrote: > Please review http://cr.openjdk.java.net/~sundar/8174209/webrev/ for > https://bugs.openjdk.java.net/browse/JDK-8174209 > > Thanks, > -Sundar From james.laskey at oracle.com Mon Feb 13 18:14:21 2017 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Mon, 13 Feb 2017 14:14:21 -0400 Subject: RFR 8174209: Renumber the compress levels In-Reply-To: <58A1E6E3.2070301@oracle.com> References: <58A1E6E3.2070301@oracle.com> Message-ID: +1 > On Feb 13, 2017, at 1:03 PM, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8174209/webrev/ for https://bugs.openjdk.java.net/browse/JDK-8174209 > > Thanks, > -Sundar From mandy.chung at oracle.com Mon Feb 13 18:18:01 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 13 Feb 2017 10:18:01 -0800 Subject: RFR 8174209: Renumber the compress levels In-Reply-To: <58A1E6E3.2070301@oracle.com> References: <58A1E6E3.2070301@oracle.com> Message-ID: <96AB4783-EF96-4A22-A31F-7BCFA9788343@oracle.com> > On Feb 13, 2017, at 9:03 AM, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8174209/webrev/ for https://bugs.openjdk.java.net/browse/JDK-8174209 Looks okay. Mandy From jonathan.gibbons at oracle.com Mon Feb 13 19:10:53 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 13 Feb 2017 11:10:53 -0800 Subject: Confusing error message for inner non-public service provider In-Reply-To: <9359b569-4a74-323c-03d7-4c36d4778429@gmail.com> References: <5898F31A.1010101@oracle.com> <589A1E45.3060604@oracle.com> <92b56a2d-89ef-cb6d-82b7-d8efb928269e@oracle.com> <9359b569-4a74-323c-03d7-4c36d4778429@gmail.com> Message-ID: <58A204BD.1070203@oracle.com> Peter, The circumstances of the analysis of service providers are very different to the normal JLS rules regarding visibility and accessibility of named items. I know that we have some cleanup to do, for javac to "catch up" with the latest updates to JLS, especially with regards to the difference between "visibility" and "accessibility". Is that the issue you concerned about, or is there something else about this message you find confusing. -- Jon On 02/13/2017 09:08 AM, Peter Levart wrote: > Hi, > > Just wanted to note that the confusing javac error message is not > specific to services and service providers. > > Take the following example: > > src/moda/module-info.java: > > module moda { > exports pkga; > } > > src/moda/pkga/Outer.java: > > package pkga; > class Outer { > public static class Untouchable { > public static void touch() { > throw new AssertionError("Can't touch this!"); > } > } > } > > src/modb/module-info.java: > > module modb { > requires moda; > } > > src/modb/pkgb/Intruder.java: > > package pkgb; > public class Intruder { > public static void main(String[] args) { > pkga.Outer.Untouchable.touch(); > } > } > > > $ javac -d out --module-path out --module-source-path src `find src > -name '*.java'` > src/modb/pkgb/Intruder.java:6: error: package pkga is not visible > pkga.Outer.Untouchable.touch(); > ^ > (package pkga is declared in module moda, which does not export it > to module modb) > 1 error > > > > Regards, Peter > > > On 02/09/2017 11:49 PM, Vicente Romero wrote: >> Hi Alex, >> >> Just to double check, the right javac behavior in this case should be >> to issue similar errors in both cases like: >> >> some position here: error: ServiceImpl is not public in >> com.example.internal; cannot be accessed from outside package >> some other position here: error: Outer.ServiceImpl is not public in >> com.example.internal; cannot be accessed from outside package >> >> without mentioning in any case anything about visibility right? >> >> Thanks, >> Vicente >> >> >> On 02/07/2017 02:21 PM, Alex Buckley wrote: >>> On 2/7/2017 1:11 AM, Gunnar Morling wrote: >>>> --- >>>> package com.example; >>>> public interface SomeService { >>>> public void foo(); >>>> } >>>> --- >>>> package com.example.internal; >>>> class Outer { >>>> >>>> public static class ServiceImpl implements >>>> com.example.SomeService { >>>> public ServiceImpl() {} >>>> public void foo() {} >>>> } >>>> } >>>> --- >>>> package com.example.internal; >>>> class ServiceImpl implements com.example.SomeService { >>>> public ServiceImpl() {} >>>> public void foo() {} >>>> } >>>> --- >>>> module com.example { >>>> exports com.example; >>>> provides com.example.SomeService with >>>> com.example.internal.ServiceImpl; >>>> provides com.example.SomeService with >>>> com.example.internal.Outer.ServiceImpl; >>>> } >>>> --- >>>> >>>> Essentially, I'm wondering: >>>> >>>> * Why Outer.ServiceImpl triggers the error about package visibility >>>> while ServiceImpl doesn't (I had a look at the EDR JLS, but I couldn't >>>> find an explanation for that, happy about any specific pointers). >>>> * Why Outer.ServiceImpl triggers "does not have a default constructor" >>>> (ServiceImpl does not). Maybe a hint would be nice that is caused by >>>> Outer not having public access. >>> >>> Thanks for showing the code. Since everything in the same module, >>> package visibility is not relevant and javac shouldn't mention it. >>> >>> I suspect that javac is getting tripped up by the fact that >>> Outer.ServiceImpl is declared 'public' (as the JLS and ServiceLoader >>> both demand) but it isn't widely accessible, even within the >>> com.example module, due to Outer's default (package) access. I >>> believe the JLS and ServiceLoader rules are correct, so it's a javac >>> bug. >>> >>> Alex >> > From james.connors at oracle.com Mon Feb 13 19:32:33 2017 From: james.connors at oracle.com (Jim Connors) Date: Mon, 13 Feb 2017 14:32:33 -0500 Subject: jlink RuntimeException: descriptor returns inconsistent package set In-Reply-To: References: <0ee41ff8-6682-fe7c-7ecc-315f430c8a09@oracle.com> <0a60f45d-1503-11f9-226f-a6fef296fc85@oracle.com> <19720521-df58-fe05-7864-b8ed6556fa69@oracle.com> <56e1f400-fe3a-c46e-ddf1-f1e8d10d3e88@oracle.com> <4e56d520-895b-b37f-2d94-8a66c0ec08c8@oracle.com> Message-ID: As a postscript to this entire thread, for what it's worth, here's a blog entry which presents a recipe for adding the necessary customization to NetBeans to enable it to automatically build JDK9 runtime images as part of the build process. Automating the Creation of JDK9 Reduced Runtime Images in NetBeans https://blogs.oracle.com/jtc/entry/automating_the_creation_of_jdk9 From david.lloyd at redhat.com Mon Feb 13 20:49:20 2017 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 13 Feb 2017 14:49:20 -0600 Subject: Java SE JSR 250 annotations module renamed to java.xml.ws.annotation? In-Reply-To: <682261532.497891.1487007030352.JavaMail.zimbra@u-pem.fr> References: <2016060755.369657.1486997998047.JavaMail.zimbra@u-pem.fr> <682261532.497891.1487007030352.JavaMail.zimbra@u-pem.fr> Message-ID: On 02/13/2017 11:30 AM, forax at univ-mlv.fr wrote: >> - even as a temporary workaround, it's really weird to have to require a module >> named java.xml.ws.annotation for that. It does not really make sense from an >> end user perspective. > > the module name reflect the fact that it's a part of jax-ws and not annotations that you can use for other things. And here is the problem: these are JSR 250 annotations and I guarantee you that >99% of Java users don't know (or care) why they were introduced in to the platform. The fact that they came in as part of JAX-WS cannot possibly be less relevant to their modern presence in the JDK. Trying to force people to care (by putting the annotations under an otherwise obscure module identifier) is neither helpful nor useful to just about anyone; no amount of pretending is going to convince anyone that these annotations belong to JAX-WS and not JSR 250. Nothing in this discussion has changed (at least) my position: the classes cannot be removed in the Java 9 time frame; JSR 250 should have its own identity regardless of why it was originally introduced; if it is to be removed later then there should be a platform replacement for @Generated in java.lang.annotation that is ideally introduced now so that there is an overlapping transition period. -- - DML From peter.levart at gmail.com Tue Feb 14 08:00:47 2017 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 14 Feb 2017 09:00:47 +0100 Subject: Confusing error message for inner non-public service provider In-Reply-To: <58A204BD.1070203@oracle.com> References: <5898F31A.1010101@oracle.com> <589A1E45.3060604@oracle.com> <92b56a2d-89ef-cb6d-82b7-d8efb928269e@oracle.com> <9359b569-4a74-323c-03d7-4c36d4778429@gmail.com> <58A204BD.1070203@oracle.com> Message-ID: <2fba3392-4ed2-dfd7-372a-40fc88e4d531@gmail.com> Hi Jon, I understand that service providers have a different set of rules (they are usually not universally accessible classes) and therefore the requirement for them to have public access modifier is merely a choice JLS made to enforce a certain degree of strictness. Classes with default (package-private) modifier could easily be allowed too, but I guess some strictness is welcome. I just wanted to share what I observed: that the javac error message is similar also when trying to access a public nested class in a package-private enclosing class in an exported package, from a different module, which has nothing to do with service providers. Regards, Peter On 02/13/2017 08:10 PM, Jonathan Gibbons wrote: > Peter, > > The circumstances of the analysis of service providers are very > different to the normal JLS rules regarding visibility and > accessibility of named items. > > I know that we have some cleanup to do, for javac to "catch up" with > the latest updates to JLS, especially with regards to the difference > between "visibility" and "accessibility". Is that the issue you > concerned about, or is there something else about this message you > find confusing. > > -- Jon > > On 02/13/2017 09:08 AM, Peter Levart wrote: >> Hi, >> >> Just wanted to note that the confusing javac error message is not >> specific to services and service providers. >> >> Take the following example: >> >> src/moda/module-info.java: >> >> module moda { >> exports pkga; >> } >> >> src/moda/pkga/Outer.java: >> >> package pkga; >> class Outer { >> public static class Untouchable { >> public static void touch() { >> throw new AssertionError("Can't touch this!"); >> } >> } >> } >> >> src/modb/module-info.java: >> >> module modb { >> requires moda; >> } >> >> src/modb/pkgb/Intruder.java: >> >> package pkgb; >> public class Intruder { >> public static void main(String[] args) { >> pkga.Outer.Untouchable.touch(); >> } >> } >> >> >> $ javac -d out --module-path out --module-source-path src `find src >> -name '*.java'` >> src/modb/pkgb/Intruder.java:6: error: package pkga is not visible >> pkga.Outer.Untouchable.touch(); >> ^ >> (package pkga is declared in module moda, which does not export it >> to module modb) >> 1 error >> >> >> >> Regards, Peter >> >> >> On 02/09/2017 11:49 PM, Vicente Romero wrote: >>> Hi Alex, >>> >>> Just to double check, the right javac behavior in this case should >>> be to issue similar errors in both cases like: >>> >>> some position here: error: ServiceImpl is not public in >>> com.example.internal; cannot be accessed from outside package >>> some other position here: error: Outer.ServiceImpl is not public in >>> com.example.internal; cannot be accessed from outside package >>> >>> without mentioning in any case anything about visibility right? >>> >>> Thanks, >>> Vicente >>> >>> >>> On 02/07/2017 02:21 PM, Alex Buckley wrote: >>>> On 2/7/2017 1:11 AM, Gunnar Morling wrote: >>>>> --- >>>>> package com.example; >>>>> public interface SomeService { >>>>> public void foo(); >>>>> } >>>>> --- >>>>> package com.example.internal; >>>>> class Outer { >>>>> >>>>> public static class ServiceImpl implements >>>>> com.example.SomeService { >>>>> public ServiceImpl() {} >>>>> public void foo() {} >>>>> } >>>>> } >>>>> --- >>>>> package com.example.internal; >>>>> class ServiceImpl implements com.example.SomeService { >>>>> public ServiceImpl() {} >>>>> public void foo() {} >>>>> } >>>>> --- >>>>> module com.example { >>>>> exports com.example; >>>>> provides com.example.SomeService with >>>>> com.example.internal.ServiceImpl; >>>>> provides com.example.SomeService with >>>>> com.example.internal.Outer.ServiceImpl; >>>>> } >>>>> --- >>>>> >>>>> Essentially, I'm wondering: >>>>> >>>>> * Why Outer.ServiceImpl triggers the error about package visibility >>>>> while ServiceImpl doesn't (I had a look at the EDR JLS, but I >>>>> couldn't >>>>> find an explanation for that, happy about any specific pointers). >>>>> * Why Outer.ServiceImpl triggers "does not have a default >>>>> constructor" >>>>> (ServiceImpl does not). Maybe a hint would be nice that is caused by >>>>> Outer not having public access. >>>> >>>> Thanks for showing the code. Since everything in the same module, >>>> package visibility is not relevant and javac shouldn't mention it. >>>> >>>> I suspect that javac is getting tripped up by the fact that >>>> Outer.ServiceImpl is declared 'public' (as the JLS and >>>> ServiceLoader both demand) but it isn't widely accessible, even >>>> within the com.example module, due to Outer's default (package) >>>> access. I believe the JLS and ServiceLoader rules are correct, so >>>> it's a javac bug. >>>> >>>> Alex >>> >> > From martin.lehmann at gmx.de Tue Feb 14 11:15:45 2017 From: martin.lehmann at gmx.de (Martin Lehmann) Date: Tue, 14 Feb 2017 12:15:45 +0100 Subject: Changed behaviour of ResourceBundle#getBundle() In-Reply-To: References: <08d2ba80-853f-a71c-c8c1-cd95860210f8@oracle.com> Message-ID: <000201d286b3$b0812f90$11838eb0$@gmx.de> Hi Alan, thanks for that explanation. If I understand this correctly: Assume that I have two modules M and N , both containing eg a properties file and both files need to get encapsulated. Then M and N have to choose *different* package names for where to put the file, right? Because of split package problem...?! Isn't Jigsaw's default to "encapsulate all" (so anything which is not explicitely exported or opened is per default encapsulated)? Why is this not also the default for resources in the unnamed package or in a "not-a-package place"? Sounds incosistent to me. Cheers, Martin -----Original Message----- From: jigsaw-dev [mailto:jigsaw-dev-bounces at openjdk.java.net] On Behalf Of Alan Bateman Sent: Monday, December 12, 2016 5:57 PM To: Gunnar Morling Cc: jigsaw-dev Subject: Re: Changed behaviour of ResourceBundle#getBundle() On 12/12/2016 15:29, Gunnar Morling wrote: > : > > It seems to be related to the fact that the bundle is located in the > default package, because the expected exception is raised if the > bundle is located in a proper package. > Right, resources in the unnamed package or with names that don't map to packages in the module are not encapsulated. So what you are seeing is correct. -Alan From Alan.Bateman at oracle.com Tue Feb 14 11:37:32 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 14 Feb 2017 11:37:32 +0000 Subject: Changed behaviour of ResourceBundle#getBundle() In-Reply-To: <000201d286b3$b0812f90$11838eb0$@gmx.de> References: <08d2ba80-853f-a71c-c8c1-cd95860210f8@oracle.com> <000201d286b3$b0812f90$11838eb0$@gmx.de> Message-ID: <8e20f8a9-157c-4da6-86fb-c38257557a19@oracle.com> On 14/02/2017 11:15, Martin Lehmann wrote: > Hi Alan, > > thanks for that explanation. > > If I understand this correctly: Assume that I have two modules M and N , both containing eg a properties file and both files need to get encapsulated. Then M and N have to choose *different* package names for where to put the file, right? Because of split package problem...?! > > Isn't Jigsaw's default to "encapsulate all" (so anything which is not explicitely exported or opened is per default encapsulated)? Why is this not also the default for resources in the unnamed package or in a "not-a-package place"? Sounds incosistent to me. > A named module contains a set of named packages. Only resources with names that map to those packages can be encapsulated, there is no support in the design for encapsulating other random resources that aren't in any of the module's packages. So resources in locations like the top-level directory of a JAR file or META-INF/mumble can never be encapsulated because these locations to not map to packages in a named module. For the M and N example then if they both contain the same package (assuming not-exported) then the only restriction is that they cannot be defined to the same class loader. -Alan From sundararajan.athijegannathan at oracle.com Tue Feb 14 13:52:50 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 14 Feb 2017 19:22:50 +0530 Subject: RFR 8174718: "Module 's descriptor returns inconsistent package set" confusing Message-ID: <58A30BB2.1060602@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8174718/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8174718 Thanks, -Sundar From aph at redhat.com Tue Feb 14 14:20:54 2017 From: aph at redhat.com (Andrew Haley) Date: Tue, 14 Feb 2017 14:20:54 +0000 Subject: Running jaotc with an external Graal In-Reply-To: <5EF9A80E-8E23-4DB5-96CB-38E861F6D4A0@oracle.com> References: <5EF9A80E-8E23-4DB5-96CB-38E861F6D4A0@oracle.com> Message-ID: <677898c0-cc47-cea4-355d-a72bbcf80f7b@redhat.com> On 14/02/17 13:34, Doug Simon wrote: > I don?t know how one patches a module in the middle of the module > graph. That is, we use --patch-module and --upgrade-module-path to > override the jdk.vm.compiler module in the JDK. I don?t know what > that means for modules such as jdk.aot that depend on > jdk.vm.compiler. Maybe someone from the AOT or jigsaw team can help. OK, thanks. I guess I could try to upgrade the copy of Graal that is contained in HotSpot. I'll have a look. Andrew. From Alan.Bateman at oracle.com Tue Feb 14 14:37:05 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 14 Feb 2017 14:37:05 +0000 Subject: Running jaotc with an external Graal In-Reply-To: <677898c0-cc47-cea4-355d-a72bbcf80f7b@redhat.com> References: <5EF9A80E-8E23-4DB5-96CB-38E861F6D4A0@oracle.com> <677898c0-cc47-cea4-355d-a72bbcf80f7b@redhat.com> Message-ID: <4dd82907-8da0-ac21-92f9-8c784ec2674a@oracle.com> On 14/02/2017 14:20, Andrew Haley wrote: > On 14/02/17 13:34, Doug Simon wrote: > >> I don?t know how one patches a module in the middle of the module >> graph. That is, we use --patch-module and --upgrade-module-path to >> override the jdk.vm.compiler module in the JDK. I don?t know what >> that means for modules such as jdk.aot that depend on >> jdk.vm.compiler. Maybe someone from the AOT or jigsaw team can help. > OK, thanks. I guess I could try to upgrade the copy of Graal that is > contained in HotSpot. I'll have a look. > > --patch-module can be used to patch any module in the boot layer. So if you are looking to override or add classes then --patch-module should work. -Alan From aph at redhat.com Tue Feb 14 14:38:35 2017 From: aph at redhat.com (Andrew Haley) Date: Tue, 14 Feb 2017 14:38:35 +0000 Subject: Running jaotc with an external Graal In-Reply-To: <4dd82907-8da0-ac21-92f9-8c784ec2674a@oracle.com> References: <5EF9A80E-8E23-4DB5-96CB-38E861F6D4A0@oracle.com> <677898c0-cc47-cea4-355d-a72bbcf80f7b@redhat.com> <4dd82907-8da0-ac21-92f9-8c784ec2674a@oracle.com> Message-ID: <933396d6-b5eb-290d-831c-b8883de8c025@redhat.com> On 14/02/17 14:37, Alan Bateman wrote: > --patch-module can be used to patch any module in the boot layer. So if > you are looking to override or add classes then --patch-module should work. Aha! Thanks, Andrew. From Alan.Bateman at oracle.com Tue Feb 14 15:38:22 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 14 Feb 2017 15:38:22 +0000 Subject: RFR 8174718: "Module 's descriptor returns inconsistent package set" confusing In-Reply-To: <58A30BB2.1060602@oracle.com> References: <58A30BB2.1060602@oracle.com> Message-ID: <91ab2875-e5fc-c0be-39b4-a7300b2112c5@oracle.com> On 14/02/2017 13:52, Sundararajan Athijegannathan wrote: > Please review http://cr.openjdk.java.net/~sundar/8174718/webrev.00/ > for https://bugs.openjdk.java.net/browse/JDK-8174718 Is the output matching in the test correct to check for "Module inconsistentJar's descriptor ..."? -Alan From sundararajan.athijegannathan at oracle.com Tue Feb 14 15:56:28 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 14 Feb 2017 21:26:28 +0530 Subject: RFR 8174718: "Module 's descriptor returns inconsistent package set" confusing In-Reply-To: <91ab2875-e5fc-c0be-39b4-a7300b2112c5@oracle.com> References: <58A30BB2.1060602@oracle.com> <91ab2875-e5fc-c0be-39b4-a7300b2112c5@oracle.com> Message-ID: <58A328AC.9080601@oracle.com> Yes - because the test module's name is "inconsistentJar" and jlink adds module name to the error message. -Sundar On 14/02/17, 9:08 PM, Alan Bateman wrote: > On 14/02/2017 13:52, Sundararajan Athijegannathan wrote: > >> Please review http://cr.openjdk.java.net/~sundar/8174718/webrev.00/ >> for https://bugs.openjdk.java.net/browse/JDK-8174718 > Is the output matching in the test correct to check for "Module > inconsistentJar's descriptor ..."? > > -Alan From Alan.Bateman at oracle.com Tue Feb 14 15:44:10 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 14 Feb 2017 15:44:10 +0000 Subject: RFR 8174718: "Module 's descriptor returns inconsistent package set" confusing In-Reply-To: <58A328AC.9080601@oracle.com> References: <58A30BB2.1060602@oracle.com> <91ab2875-e5fc-c0be-39b4-a7300b2112c5@oracle.com> <58A328AC.9080601@oracle.com> Message-ID: On 14/02/2017 15:56, Sundararajan Athijegannathan wrote: > Yes - because the test module's name is "inconsistentJar" and jlink > adds module name to the error message. > > -Sundar > Got it, I thought it was a typo initially. -Alan. From james.laskey at oracle.com Tue Feb 14 15:58:24 2017 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 14 Feb 2017 11:58:24 -0400 Subject: RFR 8174718: "Module 's descriptor returns inconsistent package set" confusing In-Reply-To: <58A30BB2.1060602@oracle.com> References: <58A30BB2.1060602@oracle.com> Message-ID: <1146E8B1-94E2-46FE-89A2-C01FCDE9E75C@oracle.com> +1 > On Feb 14, 2017, at 9:52 AM, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8174718/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8174718 > > Thanks, > -Sundar From mandy.chung at oracle.com Tue Feb 14 16:03:01 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 14 Feb 2017 08:03:01 -0800 Subject: RFR 8174718: "Module 's descriptor returns inconsistent package set" confusing In-Reply-To: <58A30BB2.1060602@oracle.com> References: <58A30BB2.1060602@oracle.com> Message-ID: > On Feb 14, 2017, at 5:52 AM, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8174718/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8174718 JLinkNegativeTest.java - line 352 is not really needed. Otherwise looks fine to me. Mandy From mark.reinhold at oracle.com Tue Feb 14 23:52:53 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 14 Feb 2017 15:52:53 -0800 Subject: Java SE JSR 250 annotations module renamed to java.xml.ws.annotation? In-Reply-To: References: <6536d7a6-703f-4dcd-35e7-331e672ac5a9@oracle.com> <2aaefa24-8f78-ce56-f5ee-8f1118fde506@oracle.com> Message-ID: <20170214155253.459594555@eggemoggin.niobe.net> 2017/2/13 9:17:47 -0800, Guillaume Smet : > On Mon, Feb 13, 2017 at 6:10 PM, alan.bateman at oracle.com wrote: >> On 13/02/2017 16:58, Guillaume Smet wrote: >>> On Mon, Feb 13, 2017 at 5:12 PM, alan.bateman at oracle.com wrote: >>>> >>>> I agree that @Generated is awkward but I haven't suggested removing it. >>> >>> What do you suggest then? As far as I understood you, you were suggesting >>> removing the module in Java 10 so the @Generated annotation would also be >>> gone? Or did I misunderstand? >> >> That is the proposal. If it goes ahead then it means that tools that rely >> on these annotations in the JDK would need to deploy the standalone version >> on the class path or as a module on the module path. > > Yeah, so basically, it would end up with > http://hg.openjdk.java.net/code-tools/jmh/rev/d74b2861222c . > > I don't think it's the best possible outcome for this useful annotation. I agree. The `@Generated` annotation falls outside the original charter of the `java.lang.annotation` package, which was meant for annotations that directly support the language's annotation facility, but we already added `@Native` in SE 8, so let's add `@Generated` in SE 9 as David suggests and encourage people to use it when running on this and later releases. The fact that `@Generated` is so widely used is new information to some of us, so thanks for bringing it up. - Mark From mandy.chung at oracle.com Wed Feb 15 00:28:16 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 14 Feb 2017 16:28:16 -0800 Subject: Review Request: JDK-8173374: Update GenGraphs tool to generate dot graph with requires transitive edges Message-ID: <2C639879-5087-4D66-93DB-039A4F2167E0@oracle.com> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173374/webrev.00/ This is the first step to enable generating dot graph to be included in module summary javadoc, if desired. jdeps already supports generating the dot graph for modules. This patch converts GenGraphs build tool to use jdeps implementation as well as fixes jdeps to work with -apionly to generate a dot graph containing `requires transitive` edges only. Mandy [1] https://bugs.openjdk.java.net/browse/JDK-8173303 From christoph.langer at sap.com Wed Feb 15 08:36:34 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 15 Feb 2017 08:36:34 +0000 Subject: Extending java.base module Message-ID: <923e234609234237bc42089c76b5c6c3@derote13de46.global.corp.sap> Hi Jigsaw experts, as you might or might not know, we have an own JDK implementation with some extension code that is quite interwoven with the jdk. Now I'm looking into how this coding can be spread into a good module structure for jdk9. And I'm not a crack yet on using the module system though I've read quite a bit into the spec documentation available so far;-) The first point for me is that we have to place some of our coding in the java.base module as we used to add private fields and methods to basic classes such as java.lang.Thread or java.lang.Exception. However, I don't want to have so much of our stuff in java.base and rather think that it should live in its own module. So the question here is if it is possible to call code of other modules from java.base, e.g. via the Service Provider interface? I see that I can define a service in java.base and specify some "uses" statement in module-info. But will my implementation of such a service from other modules be available to java.base? Also I'm contemplating about this requirement: I have a class which I would need somewhere in java.base but I'd also like to export it in the public API of my own extension module. So, if I create the class in java.base, I'm not allowed to export this class publicly, unqualified, right? But when I have it living in my extension module, then java.base would not see it. What can I do? Probably create some inherited class in my extension module that extends from the java.base impl and export this?? I'm hoping that those are easy questions for you and you can give me some helpful answers. Thanks a lot in advance!! Best regards Christoph From weijun.wang at oracle.com Wed Feb 15 08:51:56 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 15 Feb 2017 16:51:56 +0800 Subject: Extending java.base module In-Reply-To: <923e234609234237bc42089c76b5c6c3@derote13de46.global.corp.sap> References: <923e234609234237bc42089c76b5c6c3@derote13de46.global.corp.sap> Message-ID: <387c6a3c-3371-b6f6-4e01-65647a3ad812@oracle.com> Disclaimer: I am not a jigsaw expert. The provides/uses mechanism is certainly more formal, but you can also do http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d282c1a8d20b. --Max On 02/15/2017 04:36 PM, Langer, Christoph wrote: > Hi Jigsaw experts, > > as you might or might not know, we have an own JDK implementation with some extension code that is quite interwoven with the jdk. > > Now I'm looking into how this coding can be spread into a good module structure for jdk9. And I'm not a crack yet on using the module system though I've read quite a bit into the spec documentation available so far;-) > > The first point for me is that we have to place some of our coding in the java.base module as we used to add private fields and methods to basic classes such as java.lang.Thread or java.lang.Exception. However, I don't want to have so much of our stuff in java.base and rather think that it should live in its own module. So the question here is if it is possible to call code of other modules from java.base, e.g. via the Service Provider interface? I see that I can define a service in java.base and specify some "uses" statement in module-info. But will my implementation of such a service from other modules be available to java.base? > > Also I'm contemplating about this requirement: I have a class which I would need somewhere in java.base but I'd also like to export it in the public API of my own extension module. So, if I create the class in java.base, I'm not allowed to export this class publicly, unqualified, right? But when I have it living in my extension module, then java.base would not see it. What can I do? Probably create some inherited class in my extension module that extends from the java.base impl and export this?? > > I'm hoping that those are easy questions for you and you can give me some helpful answers. > > Thanks a lot in advance!! > > Best regards > Christoph > From chris.hegarty at oracle.com Wed Feb 15 09:04:06 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 15 Feb 2017 09:04:06 +0000 Subject: Extending java.base module In-Reply-To: <387c6a3c-3371-b6f6-4e01-65647a3ad812@oracle.com> References: <923e234609234237bc42089c76b5c6c3@derote13de46.global.corp.sap> <387c6a3c-3371-b6f6-4e01-65647a3ad812@oracle.com> Message-ID: <5620F80A-4484-4F94-9760-E75CC419C6DC@oracle.com> > On 15 Feb 2017, at 08:51, Weijun Wang wrote: > > Disclaimer: I am not a jigsaw expert. > > The provides/uses mechanism is certainly more formal, but you can also do http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d282c1a8d20b. This is, at best, a hack. The use of Services is a better approach, where possible. -Chris. From christoph.langer at sap.com Wed Feb 15 10:03:37 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 15 Feb 2017 10:03:37 +0000 Subject: Extending java.base module In-Reply-To: <5620F80A-4484-4F94-9760-E75CC419C6DC@oracle.com> References: <923e234609234237bc42089c76b5c6c3@derote13de46.global.corp.sap> <387c6a3c-3371-b6f6-4e01-65647a3ad812@oracle.com> <5620F80A-4484-4F94-9760-E75CC419C6DC@oracle.com> Message-ID: Hi Chris, Max, thanks for your quick answers. So the service approach seems to fit quite well. But can I assume that my service implementation will be available already at "bootstrap time" of the JDK? E.g. if I need to register/reach my service already at the early stages of JVM initialization, e.g. when a class java.lang.Thread gets initialized, can I assume a service from my extension module would be available? Thanks, Christoph > -----Original Message----- > From: Chris Hegarty [mailto:chris.hegarty at oracle.com] > Sent: Mittwoch, 15. Februar 2017 10:04 > To: Weijun Wang > Cc: Langer, Christoph ; jigsaw- > dev at openjdk.java.net > Subject: Re: Extending java.base module > > > > On 15 Feb 2017, at 08:51, Weijun Wang wrote: > > > > Disclaimer: I am not a jigsaw expert. > > > > The provides/uses mechanism is certainly more formal, but you can also do > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d282c1a8d20b. > > This is, at best, a hack. The use of Services is a better approach, where > possible. > > -Chris. From Alan.Bateman at oracle.com Wed Feb 15 10:55:16 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 15 Feb 2017 10:55:16 +0000 Subject: Extending java.base module In-Reply-To: <923e234609234237bc42089c76b5c6c3@derote13de46.global.corp.sap> References: <923e234609234237bc42089c76b5c6c3@derote13de46.global.corp.sap> Message-ID: On 15/02/2017 08:36, Langer, Christoph wrote: > Hi Jigsaw experts, > > as you might or might not know, we have an own JDK implementation with some extension code that is quite interwoven with the jdk. > > Now I'm looking into how this coding can be spread into a good module structure for jdk9. And I'm not a crack yet on using the module system though I've read quite a bit into the spec documentation available so far;-) > > The first point for me is that we have to place some of our coding in the java.base module as we used to add private fields and methods to basic classes such as java.lang.Thread or java.lang.Exception. However, I don't want to have so much of our stuff in java.base and rather think that it should live in its own module. So the question here is if it is possible to call code of other modules from java.base, e.g. via the Service Provider interface? I see that I can define a service in java.base and specify some "uses" statement in module-info. But will my implementation of such a service from other modules be available to java.base? > > Also I'm contemplating about this requirement: I have a class which I would need somewhere in java.base but I'd also like to export it in the public API of my own extension module. So, if I create the class in java.base, I'm not allowed to export this class publicly, unqualified, right? But when I have it living in my extension module, then java.base would not see it. What can I do? Probably create some inherited class in my extension module that extends from the java.base impl and export this?? > > I'm hoping that those are easy questions for you and you can give me some helpful answers. > Yes, services is the way to do this. The jdk.net module is one example, there are several others. The other thing to be aware of is the module-info.java.extra files to augment the module declarations during the build, I suspect you'll end up using that. -Alan From forax at univ-mlv.fr Wed Feb 15 11:43:39 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 15 Feb 2017 11:43:39 +0000 Subject: Java SE JSR 250 annotations module renamed to java.xml.ws.annotation? In-Reply-To: <20170214155253.459594555@eggemoggin.niobe.net> References: <6536d7a6-703f-4dcd-35e7-331e672ac5a9@oracle.com> <2aaefa24-8f78-ce56-f5ee-8f1118fde506@oracle.com> <20170214155253.459594555@eggemoggin.niobe.net> Message-ID: <0F294B1E-B8FD-42F0-B149-45F65172877E@univ-mlv.fr> I agree. Remi On February 15, 2017 12:52:53 AM GMT+01:00, mark.reinhold at oracle.com wrote: >2017/2/13 9:17:47 -0800, Guillaume Smet : >> On Mon, Feb 13, 2017 at 6:10 PM, alan.bateman at oracle.com wrote: >>> On 13/02/2017 16:58, Guillaume Smet wrote: >>>> On Mon, Feb 13, 2017 at 5:12 PM, alan.bateman at oracle.com wrote: >>>>> >>>>> I agree that @Generated is awkward but I haven't suggested >removing it. >>>> >>>> What do you suggest then? As far as I understood you, you were >suggesting >>>> removing the module in Java 10 so the @Generated annotation would >also be >>>> gone? Or did I misunderstand? >>> >>> That is the proposal. If it goes ahead then it means that tools that >rely >>> on these annotations in the JDK would need to deploy the standalone >version >>> on the class path or as a module on the module path. >> >> Yeah, so basically, it would end up with >> http://hg.openjdk.java.net/code-tools/jmh/rev/d74b2861222c . >> >> I don't think it's the best possible outcome for this useful >annotation. > >I agree. > >The `@Generated` annotation falls outside the original charter of the >`java.lang.annotation` package, which was meant for annotations that >directly support the language's annotation facility, but we already >added `@Native` in SE 8, so let's add `@Generated` in SE 9 as David >suggests and encourage people to use it when running on this and later >releases. > >The fact that `@Generated` is so widely used is new information to some >of us, so thanks for bringing it up. > >- Mark -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From david.holmes at oracle.com Wed Feb 15 12:10:26 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 Feb 2017 22:10:26 +1000 Subject: Extending java.base module In-Reply-To: References: <923e234609234237bc42089c76b5c6c3@derote13de46.global.corp.sap> <387c6a3c-3371-b6f6-4e01-65647a3ad812@oracle.com> <5620F80A-4484-4F94-9760-E75CC419C6DC@oracle.com> Message-ID: <8d0c7d86-8a6f-019f-08cf-f168a05b04bc@oracle.com> On 15/02/2017 8:03 PM, Langer, Christoph wrote: > Hi Chris, Max, > > thanks for your quick answers. So the service approach seems to fit quite well. > > But can I assume that my service implementation will be available already at "bootstrap time" of the JDK? E.g. if I need to register/reach my service already at the early stages of JVM initialization, e.g. when a class java.lang.Thread gets initialized, can I assume a service from my extension module would be available? I'm pretty sure the answer to that will be No! Thread is one of the earlier classes to be initialized, the module system is initialized much later. David ----- > Thanks, > Christoph > > >> -----Original Message----- >> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >> Sent: Mittwoch, 15. Februar 2017 10:04 >> To: Weijun Wang >> Cc: Langer, Christoph ; jigsaw- >> dev at openjdk.java.net >> Subject: Re: Extending java.base module >> >> >>> On 15 Feb 2017, at 08:51, Weijun Wang wrote: >>> >>> Disclaimer: I am not a jigsaw expert. >>> >>> The provides/uses mechanism is certainly more formal, but you can also do >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d282c1a8d20b. >> >> This is, at best, a hack. The use of Services is a better approach, where >> possible. >> >> -Chris. > From Alan.Bateman at oracle.com Wed Feb 15 12:22:07 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 15 Feb 2017 12:22:07 +0000 Subject: Extending java.base module In-Reply-To: <8d0c7d86-8a6f-019f-08cf-f168a05b04bc@oracle.com> References: <923e234609234237bc42089c76b5c6c3@derote13de46.global.corp.sap> <387c6a3c-3371-b6f6-4e01-65647a3ad812@oracle.com> <5620F80A-4484-4F94-9760-E75CC419C6DC@oracle.com> <8d0c7d86-8a6f-019f-08cf-f168a05b04bc@oracle.com> Message-ID: <254fc3e3-8f3a-9910-17e5-8dafd8175462@oracle.com> On 15/02/2017 12:10, David Holmes wrote: > On 15/02/2017 8:03 PM, Langer, Christoph wrote: >> Hi Chris, Max, >> >> thanks for your quick answers. So the service approach seems to fit >> quite well. >> >> But can I assume that my service implementation will be available >> already at "bootstrap time" of the JDK? E.g. if I need to >> register/reach my service already at the early stages of JVM >> initialization, e.g. when a class java.lang.Thread gets initialized, >> can I assume a service from my extension module would be available? > > I'm pretty sure the answer to that will be No! Thread is one of the > earlier classes to be initialized, the module system is initialized > much later. That's right as only classes in java.base can be loaded during startup. I don't know what services that Christoph is thinking of but hopefully they can be deferred until the VM is initialized. -Alan From michael.rasmussen at zeroturnaround.com Wed Feb 15 12:57:10 2017 From: michael.rasmussen at zeroturnaround.com (Michael Rasmussen) Date: Wed, 15 Feb 2017 14:57:10 +0200 Subject: Extending java.base module In-Reply-To: References: <923e234609234237bc42089c76b5c6c3@derote13de46.global.corp.sap> <387c6a3c-3371-b6f6-4e01-65647a3ad812@oracle.com> <5620F80A-4484-4F94-9760-E75CC419C6DC@oracle.com> Message-ID: > > E.g. if I need to register/reach my service already at the early stages of > JVM initialization, e.g. when a class java.lang.Thread gets initialized, > can I assume a service from my extension module would be available? > No. At that time only java.base classes can be loaded. If you look at the comments in the initPhase# methods in System, it gives some good info about when things are initialized. http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/tip/src/java.base/share/classes/java/lang/System.java#l1850 /Michael From christoph.langer at sap.com Wed Feb 15 13:21:38 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 15 Feb 2017 13:21:38 +0000 Subject: Extending java.base module In-Reply-To: <254fc3e3-8f3a-9910-17e5-8dafd8175462@oracle.com> References: <923e234609234237bc42089c76b5c6c3@derote13de46.global.corp.sap> <387c6a3c-3371-b6f6-4e01-65647a3ad812@oracle.com> <5620F80A-4484-4F94-9760-E75CC419C6DC@oracle.com> <8d0c7d86-8a6f-019f-08cf-f168a05b04bc@oracle.com> <254fc3e3-8f3a-9910-17e5-8dafd8175462@oracle.com> Message-ID: <440e057caca2463ea65bd4a2f83c1cbc@derote13de46.global.corp.sap> Hi, thanks all for your very helpful comments. So I see that I cannot rely on my Service implementation at an early stage. But I can imagine that I query for the service provider and if it's not there I have to be able to live without it. The question that remains is, when I query the ServiceLoader for my impl at a later time, then I would find it registered, right? I assume that if my module specifies "provides with ", the provider will automatically be registered once the module is loaded. Can you confirm that? Thanks Christoph > -----Original Message----- > From: Alan Bateman [mailto:Alan.Bateman at oracle.com] > Sent: Mittwoch, 15. Februar 2017 13:22 > To: David Holmes ; Langer, Christoph > ; Chris Hegarty ; > Weijun Wang > Cc: jigsaw-dev at openjdk.java.net > Subject: Re: Extending java.base module > > > > On 15/02/2017 12:10, David Holmes wrote: > > On 15/02/2017 8:03 PM, Langer, Christoph wrote: > >> Hi Chris, Max, > >> > >> thanks for your quick answers. So the service approach seems to fit > >> quite well. > >> > >> But can I assume that my service implementation will be available > >> already at "bootstrap time" of the JDK? E.g. if I need to > >> register/reach my service already at the early stages of JVM > >> initialization, e.g. when a class java.lang.Thread gets initialized, > >> can I assume a service from my extension module would be available? > > > > I'm pretty sure the answer to that will be No! Thread is one of the > > earlier classes to be initialized, the module system is initialized > > much later. > That's right as only classes in java.base can be loaded during startup. > I don't know what services that Christoph is thinking of but hopefully > they can be deferred until the VM is initialized. > > -Alan From claes.redestad at oracle.com Wed Feb 15 13:22:17 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 15 Feb 2017 14:22:17 +0100 Subject: RFR: 8175010: ImageReader is not thread-safe Message-ID: Hi, a few intermittent but rare test failures[1] that has appeared since the latest jake integration, and since one of the changes in there was to make initialization of the system ImageReader lazy there appears to be cases where ImageReaders are not safely published: - Ensure ImageReader::open is called only once per Path in ImageReaderFactory by using CHM.computeIfAbsent - Ensure ImageReader.reader is safely published to a final field and signal close using a volatile boolean instead webrev: http://cr.openjdk.java.net/~redestad/8175010/webrev.02/ bug: https://bugs.openjdk.java.net/browse/JDK-8175010 Testing shows no issues (which admittedly doesn't mean we're actually solving the root cause for JDK-8174817), and performance numbers from adding a volatile read indicate that any overhead is lost in the noise on ImageReader-heavy workloads. Thanks! /Claes [1] https://bugs.openjdk.java.net/browse/JDK-8174817 From Alan.Bateman at oracle.com Wed Feb 15 13:28:14 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 15 Feb 2017 13:28:14 +0000 Subject: Extending java.base module In-Reply-To: <440e057caca2463ea65bd4a2f83c1cbc@derote13de46.global.corp.sap> References: <923e234609234237bc42089c76b5c6c3@derote13de46.global.corp.sap> <387c6a3c-3371-b6f6-4e01-65647a3ad812@oracle.com> <5620F80A-4484-4F94-9760-E75CC419C6DC@oracle.com> <8d0c7d86-8a6f-019f-08cf-f168a05b04bc@oracle.com> <254fc3e3-8f3a-9910-17e5-8dafd8175462@oracle.com> <440e057caca2463ea65bd4a2f83c1cbc@derote13de46.global.corp.sap> Message-ID: <41c09a93-2240-a5bc-7cbe-c49d77e449e3@oracle.com> On 15/02/2017 13:21, Langer, Christoph wrote: > Hi, > > thanks all for your very helpful comments. > > So I see that I cannot rely on my Service implementation at an early stage. But I can imagine that I query for the service provider and if it's not there I have to be able to live without it. > > The question that remains is, when I query the ServiceLoader for my impl at a later time, then I would find it registered, right? I assume that if my module specifies "provides with ", the provider will automatically be registered once the module is loaded. Can you confirm that? > Yes. If you look in areas like JMX or networking then you'll see lots of examples where "extensions" are deployed as service providers. These should help you get started. -Alan From james.laskey at oracle.com Wed Feb 15 13:29:45 2017 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Wed, 15 Feb 2017 09:29:45 -0400 Subject: RFR: 8175010: ImageReader is not thread-safe In-Reply-To: References: Message-ID: <2A88FAD1-A2F1-4300-A41D-35CA83CC8D9D@oracle.com> +1 > On Feb 15, 2017, at 9:22 AM, Claes Redestad wrote: > > Hi, > > a few intermittent but rare test failures[1] that has appeared > since the latest jake integration, and since one of the changes > in there was to make initialization of the system ImageReader > lazy there appears to be cases where ImageReaders are not > safely published: > > - Ensure ImageReader::open is called only once per Path in > ImageReaderFactory by using CHM.computeIfAbsent > - Ensure ImageReader.reader is safely published to a > final field and signal close using a volatile boolean instead > > webrev: http://cr.openjdk.java.net/~redestad/8175010/webrev.02/ > bug: https://bugs.openjdk.java.net/browse/JDK-8175010 > > Testing shows no issues (which admittedly doesn't mean we're > actually solving the root cause for JDK-8174817), and performance > numbers from adding a volatile read indicate that any overhead > is lost in the noise on ImageReader-heavy workloads. > > Thanks! > > /Claes > > [1] https://bugs.openjdk.java.net/browse/JDK-8174817 From chris.hegarty at oracle.com Wed Feb 15 13:40:10 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 15 Feb 2017 13:40:10 +0000 Subject: RFR: 8175010: ImageReader is not thread-safe In-Reply-To: References: Message-ID: > On 15 Feb 2017, at 13:22, Claes Redestad wrote: > > Hi, > > a few intermittent but rare test failures[1] that has appeared > since the latest jake integration, and since one of the changes > in there was to make initialization of the system ImageReader > lazy there appears to be cases where ImageReaders are not > safely published: > > - Ensure ImageReader::open is called only once per Path in > ImageReaderFactory by using CHM.computeIfAbsent > - Ensure ImageReader.reader is safely published to a > final field and signal close using a volatile boolean instead > > webrev: http://cr.openjdk.java.net/~redestad/8175010/webrev.02/ Looks good Claes. -Chris. > bug: https://bugs.openjdk.java.net/browse/JDK-8175010 > > Testing shows no issues (which admittedly doesn't mean we're > actually solving the root cause for JDK-8174817), and performance > numbers from adding a volatile read indicate that any overhead > is lost in the noise on ImageReader-heavy workloads. > > Thanks! > > /Claes > > [1] https://bugs.openjdk.java.net/browse/JDK-8174817 From david.lloyd at redhat.com Wed Feb 15 13:47:10 2017 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 15 Feb 2017 07:47:10 -0600 Subject: Java SE JSR 250 annotations module renamed to java.xml.ws.annotation? In-Reply-To: <20170214155253.459594555@eggemoggin.niobe.net> References: <6536d7a6-703f-4dcd-35e7-331e672ac5a9@oracle.com> <2aaefa24-8f78-ce56-f5ee-8f1118fde506@oracle.com> <20170214155253.459594555@eggemoggin.niobe.net> Message-ID: <514173e9-edef-3a97-918e-e8321b91bcab@redhat.com> On 02/14/2017 05:52 PM, mark.reinhold at oracle.com wrote: > 2017/2/13 9:17:47 -0800, Guillaume Smet : >> On Mon, Feb 13, 2017 at 6:10 PM, alan.bateman at oracle.com wrote: >>> On 13/02/2017 16:58, Guillaume Smet wrote: >>>> On Mon, Feb 13, 2017 at 5:12 PM, alan.bateman at oracle.com wrote: >>>>> >>>>> I agree that @Generated is awkward but I haven't suggested removing it. >>>> >>>> What do you suggest then? As far as I understood you, you were suggesting >>>> removing the module in Java 10 so the @Generated annotation would also be >>>> gone? Or did I misunderstand? >>> >>> That is the proposal. If it goes ahead then it means that tools that rely >>> on these annotations in the JDK would need to deploy the standalone version >>> on the class path or as a module on the module path. >> >> Yeah, so basically, it would end up with >> http://hg.openjdk.java.net/code-tools/jmh/rev/d74b2861222c . >> >> I don't think it's the best possible outcome for this useful annotation. > > I agree. > > The `@Generated` annotation falls outside the original charter of the > `java.lang.annotation` package, which was meant for annotations that > directly support the language's annotation facility, but we already > added `@Native` in SE 8, so let's add `@Generated` in SE 9 as David > suggests and encourage people to use it when running on this and later > releases. > > The fact that `@Generated` is so widely used is new information to some > of us, so thanks for bringing it up. I'm glad to hear it... thanks! -- - DML From Alan.Bateman at oracle.com Wed Feb 15 13:56:18 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 15 Feb 2017 13:56:18 +0000 Subject: RFR: 8175010: ImageReader is not thread-safe In-Reply-To: References: Message-ID: On 15/02/2017 13:22, Claes Redestad wrote: > Hi, > > a few intermittent but rare test failures[1] that has appeared > since the latest jake integration, and since one of the changes > in there was to make initialization of the system ImageReader > lazy there appears to be cases where ImageReaders are not > safely published: > > - Ensure ImageReader::open is called only once per Path in > ImageReaderFactory by using CHM.computeIfAbsent > - Ensure ImageReader.reader is safely published to a > final field and signal close using a volatile boolean instead > > webrev: http://cr.openjdk.java.net/~redestad/8175010/webrev.02/ > bug: https://bugs.openjdk.java.net/browse/JDK-8175010 ImageReaderFactory looks good. The changes to ImageReader are okay too, always a bit odd that this code throw NPE when the reader was closed. There is still an issue with async close of course in that someone could close at the same time as an access. However that is a high-level issue for jrtfs, at run-time then the image file is opened once and is never closed. -Alan From claes.redestad at oracle.com Wed Feb 15 14:56:21 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 15 Feb 2017 15:56:21 +0100 Subject: RFR: 8175010: ImageReader is not thread-safe In-Reply-To: References: Message-ID: Jim, Chris, Alan, thanks for reviewing! On 02/15/2017 02:56 PM, Alan Bateman wrote: > On 15/02/2017 13:22, Claes Redestad wrote: > >> Hi, >> >> a few intermittent but rare test failures[1] that has appeared >> since the latest jake integration, and since one of the changes >> in there was to make initialization of the system ImageReader >> lazy there appears to be cases where ImageReaders are not >> safely published: >> >> - Ensure ImageReader::open is called only once per Path in >> ImageReaderFactory by using CHM.computeIfAbsent >> - Ensure ImageReader.reader is safely published to a >> final field and signal close using a volatile boolean instead >> >> webrev: http://cr.openjdk.java.net/~redestad/8175010/webrev.02/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8175010 > ImageReaderFactory looks good. > > The changes to ImageReader are okay too, always a bit odd that this > code throw NPE when the reader was closed. There is still an issue > with async close of course in that someone could close at the same > time as an access. However that is a high-level issue for jrtfs, at > run-time then the image file is opened once and is never closed. Yes, this patch doesn't attempt to improve on how races are handled when closing, but should help to avoid potential publication issues when opening. It seems it could be worthwhile to have a special implementation class for the system module, since we could make it perfectly shareable and non-closeable, thus avoid delegation and closed-checking overheads, but that'd be a larger endeavor, perhaps suitable as an RFE for 10. /Claes > > -Alan > > From volker.simonis at gmail.com Wed Feb 15 15:52:28 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 15 Feb 2017 16:52:28 +0100 Subject: Extending java.base module In-Reply-To: <387c6a3c-3371-b6f6-4e01-65647a3ad812@oracle.com> References: <923e234609234237bc42089c76b5c6c3@derote13de46.global.corp.sap> <387c6a3c-3371-b6f6-4e01-65647a3ad812@oracle.com> Message-ID: Hi Max, I'm not an jigsaw either, but wouldn't your solution break a tool like jlink? In other words, if an application uses your code and the developer uses jlink to create a run-time image, wouldn't that image fail to execute his application because jlink fails to see that java.base depends on java.security.jgss in that special case? Thanks, Volker On Wed, Feb 15, 2017 at 9:51 AM, Weijun Wang wrote: > Disclaimer: I am not a jigsaw expert. > > The provides/uses mechanism is certainly more formal, but you can also do > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d282c1a8d20b. > > --Max > > > On 02/15/2017 04:36 PM, Langer, Christoph wrote: >> >> Hi Jigsaw experts, >> >> as you might or might not know, we have an own JDK implementation with >> some extension code that is quite interwoven with the jdk. >> >> Now I'm looking into how this coding can be spread into a good module >> structure for jdk9. And I'm not a crack yet on using the module system >> though I've read quite a bit into the spec documentation available so far;-) >> >> The first point for me is that we have to place some of our coding in the >> java.base module as we used to add private fields and methods to basic >> classes such as java.lang.Thread or java.lang.Exception. However, I don't >> want to have so much of our stuff in java.base and rather think that it >> should live in its own module. So the question here is if it is possible to >> call code of other modules from java.base, e.g. via the Service Provider >> interface? I see that I can define a service in java.base and specify some >> "uses" statement in module-info. But will my implementation of such a >> service from other modules be available to java.base? >> >> Also I'm contemplating about this requirement: I have a class which I >> would need somewhere in java.base but I'd also like to export it in the >> public API of my own extension module. So, if I create the class in >> java.base, I'm not allowed to export this class publicly, unqualified, >> right? But when I have it living in my extension module, then java.base >> would not see it. What can I do? Probably create some inherited class in my >> extension module that extends from the java.base impl and export this?? >> >> I'm hoping that those are easy questions for you and you can give me some >> helpful answers. >> >> Thanks a lot in advance!! >> >> Best regards >> Christoph >> > From guillaume at hibernate.org Wed Feb 15 15:57:25 2017 From: guillaume at hibernate.org (Guillaume Smet) Date: Wed, 15 Feb 2017 16:57:25 +0100 Subject: Java SE JSR 250 annotations module renamed to java.xml.ws.annotation? In-Reply-To: <20170214155253.459594555@eggemoggin.niobe.net> References: <6536d7a6-703f-4dcd-35e7-331e672ac5a9@oracle.com> <2aaefa24-8f78-ce56-f5ee-8f1118fde506@oracle.com> <20170214155253.459594555@eggemoggin.niobe.net> Message-ID: Hi Mark, On Wed, Feb 15, 2017 at 12:52 AM, wrote: > The `@Generated` annotation falls outside the original charter of the > `java.lang.annotation` package, which was meant for annotations that > directly support the language's annotation facility, but we already > added `@Native` in SE 8, so let's add `@Generated` in SE 9 as David > suggests and encourage people to use it when running on this and later > releases. > Thanks for taking it into consideration. -- Guillaume From daniel.fuchs at oracle.com Wed Feb 15 16:01:45 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 15 Feb 2017 16:01:45 +0000 Subject: Extending java.base module In-Reply-To: References: <923e234609234237bc42089c76b5c6c3@derote13de46.global.corp.sap> <387c6a3c-3371-b6f6-4e01-65647a3ad812@oracle.com> Message-ID: Hi Volker, On 15/02/17 15:52, Volker Simonis wrote: > Hi Max, > > I'm not an jigsaw either, but wouldn't your solution break a tool like jlink? > > In other words, if an application uses your code and the developer > uses jlink to create a run-time image, wouldn't that image fail to > execute his application because jlink fails to see that java.base > depends on java.security.jgss in that special case? In that specific case it's not java.base that depends on java.security.jgss, but the application itself. So I would expect the application code to either require java.security.jgss, or some higher level module for that itself requires java.security.jgss, or jlink to be run with command line options that explicitly add java.security.jgss to the image. best regards, -- daniel > > Thanks, > Volker From mandy.chung at oracle.com Wed Feb 15 16:02:25 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 15 Feb 2017 08:02:25 -0800 Subject: RFR: 8175010: ImageReader is not thread-safe In-Reply-To: References: Message-ID: > On Feb 15, 2017, at 5:22 AM, Claes Redestad wrote: > > Hi, > > a few intermittent but rare test failures[1] that has appeared > since the latest jake integration, and since one of the changes > in there was to make initialization of the system ImageReader > lazy there appears to be cases where ImageReaders are not > safely published: > > - Ensure ImageReader::open is called only once per Path in > ImageReaderFactory by using CHM.computeIfAbsent > - Ensure ImageReader.reader is safely published to a > final field and signal close using a volatile boolean instead > > webrev: http://cr.openjdk.java.net/~redestad/8175010/webrev.02/ Looks good. Mandy From Alan.Bateman at oracle.com Wed Feb 15 16:16:10 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 15 Feb 2017 16:16:10 +0000 Subject: Extending java.base module In-Reply-To: References: <923e234609234237bc42089c76b5c6c3@derote13de46.global.corp.sap> <387c6a3c-3371-b6f6-4e01-65647a3ad812@oracle.com> Message-ID: <79cb413f-fd60-3a0a-7739-29ef06ad4a5e@oracle.com> On 15/02/2017 16:01, Daniel Fuchs wrote: > > In that specific case it's not java.base that depends > on java.security.jgss, but the application itself. > > So I would expect the application code to either require > java.security.jgss, or some higher level module for that > itself requires java.security.jgss, or jlink to be run with > command line options that explicitly add java.security.jgss > to the image. java.security.jgss exports an API so it will be resolved by default when the initial class is loaded from the class path. In addition, it provides a SecurityProvider implementation and so will be resolved because java.base `uses java.security.Provider`. For the jlink case then you are right, it needs someone to know that the application might need to do SPNEGO authentication. In any case, it's an example of how not to do things, and hopefully it will be cleaned up at some point. -Alan From volker.simonis at gmail.com Wed Feb 15 16:20:16 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 15 Feb 2017 17:20:16 +0100 Subject: Extending java.base module In-Reply-To: <79cb413f-fd60-3a0a-7739-29ef06ad4a5e@oracle.com> References: <923e234609234237bc42089c76b5c6c3@derote13de46.global.corp.sap> <387c6a3c-3371-b6f6-4e01-65647a3ad812@oracle.com> <79cb413f-fd60-3a0a-7739-29ef06ad4a5e@oracle.com> Message-ID: On Wed, Feb 15, 2017 at 5:16 PM, Alan Bateman wrote: > On 15/02/2017 16:01, Daniel Fuchs wrote: > >> >> In that specific case it's not java.base that depends >> on java.security.jgss, but the application itself. >> >> So I would expect the application code to either require >> java.security.jgss, or some higher level module for that >> itself requires java.security.jgss, or jlink to be run with >> command line options that explicitly add java.security.jgss >> to the image. > > java.security.jgss exports an API so it will be resolved by default when the > initial class is loaded from the class path. In addition, it provides a > SecurityProvider implementation and so will be resolved because java.base > `uses java.security.Provider`. For the jlink case then you are right, it > needs someone to know that the application might need to do SPNEGO > authentication. > > In any case, it's an example of how not to do things, and hopefully it will > be cleaned up at some point. > Daniel, Alan, thanks for the clarification. I didn't wanted to blame anybody - just looking for good arguments to prevent such code in our version of the JDK :) > -Alan > > From claes.redestad at oracle.com Wed Feb 15 17:12:01 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 15 Feb 2017 18:12:01 +0100 Subject: RFR: 8175026: Capture build-time parameters to --generate-jli-classes Message-ID: <7c594b2c-a89c-8715-e65d-9442cf6005a7@oracle.com> Hi, currently the file we generate at build time as input to --generate-jli-classes is lost when linking custom images, which means user generate images may perform worse in certain ways, mostly generating more classes during startup. Additionally, there's a strong assumption in --generate-jli-classes that the VM running jlink is going to generate compatible classes with the image being linked, which we can only really guarantee if the java.base in the linked image is of the same version as the java.base in the VM running jlink. This patch tightens these checks to ensure we have freedom to evolve and re-evaluate the implementation in future releases. JDK: http://cr.openjdk.java.net/~redestad/8175026/jdk.01/ Top: http://cr.openjdk.java.net/~redestad/8175026/top.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8175026 Thanks! /Claes From daniel.fuchs at oracle.com Wed Feb 15 18:29:13 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 15 Feb 2017 18:29:13 +0000 Subject: Review Request: JDK-8173374: Update GenGraphs tool to generate dot graph with requires transitive edges In-Reply-To: <2C639879-5087-4D66-93DB-039A4F2167E0@oracle.com> References: <2C639879-5087-4D66-93DB-039A4F2167E0@oracle.com> Message-ID: <60a144a8-8586-c908-d4c1-528c5848d14d@oracle.com> Hi Mandy, Some early comments: GenGraphs.java -------------- 58 dir = Paths.get(args[++i]); may produced ArrayOutOfBoundsException - should we have better error reporting? Or should it check && i < args.length - 1 so that it falls back to having dir == null below? 93 .resolve(ModuleFinder.ofSystem(), could that be: .resolve(finder, Graph.java ---------- 119 return builder.build().reduce(); 277 this.nodes.addAll(nodes); These were bugs, which you're taking this opportunity to fix - right? JdepsTask.java: --------------- 1027 // print module descriptor Is this comment accurate? DotFileTest.java ---------------- Missing @bug tag? best regards, -- daniel On 15/02/17 00:28, Mandy Chung wrote: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173374/webrev.00/ > > This is the first step to enable generating dot graph to be > included in module summary javadoc, if desired. jdeps already > supports generating the dot graph for modules. This patch > converts GenGraphs build tool to use jdeps implementation > as well as fixes jdeps to work with -apionly to generate > a dot graph containing `requires transitive` edges only. > > Mandy > [1] https://bugs.openjdk.java.net/browse/JDK-8173303 > From mandy.chung at oracle.com Wed Feb 15 19:09:36 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 15 Feb 2017 11:09:36 -0800 Subject: RFR: 8175026: Capture build-time parameters to --generate-jli-classes In-Reply-To: <7c594b2c-a89c-8715-e65d-9442cf6005a7@oracle.com> References: <7c594b2c-a89c-8715-e65d-9442cf6005a7@oracle.com> Message-ID: > On Feb 15, 2017, at 9:12 AM, Claes Redestad wrote: > > Hi, > > currently the file we generate at build time as input to > --generate-jli-classes is lost when linking custom images, which means > user generate images may perform worse in certain ways, mostly > generating more classes during startup. > > Additionally, there's a strong assumption in --generate-jli-classes that > the VM running jlink is going to generate compatible classes with the > image being linked, which we can only really guarantee if the java.base > in the linked image is of the same version as the java.base in the VM > running jlink. This patch tightens these checks to ensure we have > freedom to evolve and re-evaluate the implementation in future > releases. > > JDK: http://cr.openjdk.java.net/~redestad/8175026/jdk.01/ > Top: http://cr.openjdk.java.net/~redestad/8175026/top.01/ This restriction sounds reasonable and we can enhance this in a future release. I think the plugin can record the configuration in its own format to be independent of the trace output format. Instead of throwing ISA, you can have a test method to return a boolean to indicate if the default trace file should be read. Instead of running java.base from the runtime, you can use Runtime.version() instead and I think comparing Version::major should be adequate. This change disables this default setting entirely if the image being created is not the same version as this plugin (defaultSpecies and defaultInvokers, etc). Is it intended? In addition, if the main argument is specified but the version does not match, it will ignore the given argument. Should it be an error instead? We are the one who will generate a trace file and specify it in the jlink plugin option. It?s okay to ignore the default trace output if no plugin option is specified and I think no warning should be printed in this case. It?s just like this plugin is disabled. You may want to add a suboption to turn on verbose that will trace what is generated and what is ignored. Mandy From mandy.chung at oracle.com Wed Feb 15 19:32:04 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 15 Feb 2017 11:32:04 -0800 Subject: Review Request: JDK-8173374: Update GenGraphs tool to generate dot graph with requires transitive edges In-Reply-To: <60a144a8-8586-c908-d4c1-528c5848d14d@oracle.com> References: <2C639879-5087-4D66-93DB-039A4F2167E0@oracle.com> <60a144a8-8586-c908-d4c1-528c5848d14d@oracle.com> Message-ID: <2754C848-4663-4E7E-B415-7715F8F1629C@oracle.com> > On Feb 15, 2017, at 10:29 AM, Daniel Fuchs wrote: > > Hi Mandy, > > Some early comments: > > GenGraphs.java > -------------- > > 58 dir = Paths.get(args[++i]); > > may produced ArrayOutOfBoundsException - should we have better > error reporting? > Or should it check && i < args.length - 1 so that it falls back > to having dir == null below? > Good catch. Fixed to: i++; dir = i < args.length ? Paths.get(args[i]) : null; > 93 .resolve(ModuleFinder.ofSystem(), > > could that be: .resolve(finder, > Fixed. > > Graph.java > ---------- > > 119 return builder.build().reduce(); > 277 this.nodes.addAll(nodes); > > > These were bugs, which you're taking this opportunity to fix - right? > Yes. 119 is caught by this change. 277 is caught by code inspection. > > JdepsTask.java: > --------------- > > 1027 // print module descriptor > > Is this comment accurate? > I updated the comment: // generate dot graph from the resolved graph from module // resolution. No class dependency analysis is performed. > DotFileTest.java > ---------------- > > Missing @bug tag? > Fixed. Updated webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173374/webrev.01/ Mandy From daniel.fuchs at oracle.com Wed Feb 15 20:27:24 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 15 Feb 2017 20:27:24 +0000 Subject: Review Request: JDK-8173374: Update GenGraphs tool to generate dot graph with requires transitive edges In-Reply-To: <2754C848-4663-4E7E-B415-7715F8F1629C@oracle.com> References: <2C639879-5087-4D66-93DB-039A4F2167E0@oracle.com> <60a144a8-8586-c908-d4c1-528c5848d14d@oracle.com> <2754C848-4663-4E7E-B415-7715F8F1629C@oracle.com> Message-ID: <01155702-0a6e-afc0-23cf-fd872407edae@oracle.com> Hi Mandy, > Updated webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173374/webrev.01/ Looks good. I haven't reviewed the build changes. I assume they're OK if you managed to build ;-) best regards, -- daniel On 15/02/17 19:32, Mandy Chung wrote: > >> On Feb 15, 2017, at 10:29 AM, Daniel Fuchs wrote: >> >> Hi Mandy, >> >> Some early comments: >> >> GenGraphs.java >> -------------- >> >> 58 dir = Paths.get(args[++i]); >> >> may produced ArrayOutOfBoundsException - should we have better >> error reporting? >> Or should it check && i < args.length - 1 so that it falls back >> to having dir == null below? >> > > Good catch. Fixed to: > > i++; > dir = i < args.length ? Paths.get(args[i]) : null; > > >> 93 .resolve(ModuleFinder.ofSystem(), >> >> could that be: .resolve(finder, >> > > Fixed. > >> >> Graph.java >> ---------- >> >> 119 return builder.build().reduce(); >> 277 this.nodes.addAll(nodes); >> >> >> These were bugs, which you're taking this opportunity to fix - right? >> > > Yes. 119 is caught by this change. 277 is caught by code inspection. > >> >> JdepsTask.java: >> --------------- >> >> 1027 // print module descriptor >> >> Is this comment accurate? >> > > I updated the comment: > > // generate dot graph from the resolved graph from module > // resolution. No class dependency analysis is performed. > >> DotFileTest.java >> ---------------- >> >> Missing @bug tag? >> > > Fixed. > > > Updated webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173374/webrev.01/ > > Mandy > From peter.levart at gmail.com Wed Feb 15 20:52:48 2017 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 15 Feb 2017 21:52:48 +0100 Subject: RFR: 8175010: ImageReader is not thread-safe In-Reply-To: References: Message-ID: Hi Claes, Reading the https://bugs.openjdk.java.net/browse/JDK-8174817 and then the change that was just pushed, I can't seem to figure out what was the problem with original code. I can't find evidence for claims in https://bugs.openjdk.java.net/browse/JDK-8175010 . Is the problem publication of ImageReader via ImageReaderFactory? That can't be it, since ImageReaderFactory is using ConcurrentHashMap which ensures happens before relationships. Is there any place else where ImageReader.open(Path) is called and then the instance unsafely published to other threads? The only place I could find is in jdk.internal.jrtfs.SystemImage.open(): static SystemImage open() throws IOException { if (modulesImageExists) { // open a .jimage and build directory structure final ImageReader image = ImageReader.open(moduleImageFile); image.getRootDirectory(); return new SystemImage() { @Override Node findNode(String path) throws IOException { return image.findNode(path); } @Override byte[] getResource(Node node) throws IOException { return image.getResource(node); } @Override void close() throws IOException { image.close(); } }; } ...here the final 'image' local variable is captured by anonymous inner SystemImage subclass into a synthetic final field, so this final field ensures that ImageReader is published safely as a delegate of SystemImage. ImageReader.open(Path) factory method delegates to ImageReader.SharedImageReader.open(Path, ByteOrder) which creates a new instance of ImageReader encapsulating a SharedImageReader object: public static ImageReader open(Path imagePath, ByteOrder byteOrder) throws IOException { Objects.requireNonNull(imagePath); Objects.requireNonNull(byteOrder); synchronized (OPEN_FILES) { SharedImageReader reader = OPEN_FILES.get(imagePath); if (reader == null) { // Will fail with an IOException if wrong byteOrder. reader = new SharedImageReader(imagePath, byteOrder); OPEN_FILES.put(imagePath, reader); } else if (reader.getByteOrder() != byteOrder) { throw new IOException("\"" + reader.getName() + "\" is not an image file"); } ImageReader image = new ImageReader(reader); // <<-- HERE reader.openers.add(image); return image; } } ...the ImageReader returned from this method is not safe to publish via data race, but as far as I can see, there is no such publishing going on. So am I right in that all this patch solves is it eliminates a possibility of NPE when ImageReader is close()-d concurrently with being used from some other thread. If such NPE was observed, it means that close() is being called concurrently with access and there are still races possible which can cause undesired effects. For example: calling ImageReader.close() while using it concurrently may close underlying SharedImageReader and then after closing, access it. So is there a concurrent ImageReader.close() possible? The only place I see ImageReader.close() being invoked is from SystemImage.close() in the anonymous inner class implementation which wraps ImageReader. SystemImage.close() is only being invoked from JrtFileSystem.cleanup(), which is called from JrtFileSystem.close() and JrtFileSystem.finalize(). The following is theoretically possible: FileSystem fs = FileSystems.newFileSystem(URI.create("jrt:/"), ...); Path p = fs.getPath(...); FileSystemProvider provider = fs.provider(); InputStream is = provider.newInputStream(p, ...); // 'fs' and 'p' (which has a reference to 'fs') may be found finalizable and be finalized while the call to obtain content of input stream is in progress For this to be prevented, the following method in JrtFileSystem: // returns the content of the file resource specified by the path byte[] getFileContent(JrtPath path) throws IOException { Node node = checkNode(path); if (node.isDirectory()) { throw new FileSystemException(path + " is a directory"); } //assert node.isResource() : "resource node expected here"; return image.getResource(node); } ...would have to be changed to: byte[] getFileContent(JrtPath path) throws IOException { Node node = checkNode(path); if (node.isDirectory()) { throw new FileSystemException(path + " is a directory"); } //assert node.isResource() : "resource node expected here"; byte[] content = image.getResource(node); Reference.reachabilityFence(this); return content; } I don't claim that this is what causes the problems and I haven't found any such usages, but this is theoretically possible. Regards, Peter On 02/15/2017 02:22 PM, Claes Redestad wrote: > Hi, > > a few intermittent but rare test failures[1] that has appeared > since the latest jake integration, and since one of the changes > in there was to make initialization of the system ImageReader > lazy there appears to be cases where ImageReaders are not > safely published: > > - Ensure ImageReader::open is called only once per Path in > ImageReaderFactory by using CHM.computeIfAbsent > - Ensure ImageReader.reader is safely published to a > final field and signal close using a volatile boolean instead > > webrev: http://cr.openjdk.java.net/~redestad/8175010/webrev.02/ > bug: https://bugs.openjdk.java.net/browse/JDK-8175010 > > Testing shows no issues (which admittedly doesn't mean we're > actually solving the root cause for JDK-8174817), and performance > numbers from adding a volatile read indicate that any overhead > is lost in the noise on ImageReader-heavy workloads. > > Thanks! > > /Claes > > [1] https://bugs.openjdk.java.net/browse/JDK-8174817 From mandy.chung at oracle.com Wed Feb 15 21:08:08 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 15 Feb 2017 13:08:08 -0800 Subject: Review Request: JDK-8173374: Update GenGraphs tool to generate dot graph with requires transitive edges In-Reply-To: <01155702-0a6e-afc0-23cf-fd872407edae@oracle.com> References: <2C639879-5087-4D66-93DB-039A4F2167E0@oracle.com> <60a144a8-8586-c908-d4c1-528c5848d14d@oracle.com> <2754C848-4663-4E7E-B415-7715F8F1629C@oracle.com> <01155702-0a6e-afc0-23cf-fd872407edae@oracle.com> Message-ID: <2534D0B6-6E60-46F0-82F1-56A1351B0EF7@oracle.com> > On Feb 15, 2017, at 12:27 PM, Daniel Fuchs wrote: > > Hi Mandy, > > > Updated webrev: > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173374/webrev.01/ > > Looks good. I haven't reviewed the build changes. > I assume they're OK if you managed to build ;-) Thanks. The build change is trivial adding ?-add-exports for compiling and running GenGraphs build tool. Also add a new target to generate spec-only module graphs. Mandy From mandy.chung at oracle.com Wed Feb 15 21:23:21 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 15 Feb 2017 13:23:21 -0800 Subject: Review Request: JDK-8173374: Update GenGraphs tool to generate dot graph with requires transitive edges In-Reply-To: <2534D0B6-6E60-46F0-82F1-56A1351B0EF7@oracle.com> References: <2C639879-5087-4D66-93DB-039A4F2167E0@oracle.com> <60a144a8-8586-c908-d4c1-528c5848d14d@oracle.com> <2754C848-4663-4E7E-B415-7715F8F1629C@oracle.com> <01155702-0a6e-afc0-23cf-fd872407edae@oracle.com> <2534D0B6-6E60-46F0-82F1-56A1351B0EF7@oracle.com> Message-ID: > On Feb 15, 2017, at 1:08 PM, Mandy Chung wrote: >> >>> Updated webrev: >>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173374/webrev.01/ You may be interested in the module graphs generated from this change. http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173374/spec-dotfiles/ http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173374/gengraphs/ Open jdk.graph.html if you want to view all .png files. Mandy From claes.redestad at oracle.com Wed Feb 15 21:41:46 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 15 Feb 2017 22:41:46 +0100 Subject: RFR: 8175010: ImageReader is not thread-safe In-Reply-To: References: Message-ID: Hi Peter, are you suggesting that if I have class Foo { Bar b; }, then creating and putting Foo b in a CHM before returning it to a consumer which is then read from another thread is enough to force b to be safely published even when the other thread does *not* get the object via a call to the same CHM (which would go via the same volatile read and add the necessary happens before relationship)? I recalled having seen examples to the effect that a non-volatile b isn't safely published in this case. The (very shaky) hypothesis is thus that this could be what's happening in any of the places which load and locally cache the system ImageReader for anyone to use, e.g., SystemModuleFinder.SystemImage or JavaRuntimeURLConnection (which is implicitly called when there's a security manager installed). I might be (in fact likely am) wrong, but we discussed this offline and came to the conclusion that there was no harm in implementing these improvements regardless of whether they actually resolve 8174817 or not. I think prior to this patch a concurrent ImageReader.close() could happen if there was a race between 3 or more threads to resolve the same Path from ImageReaderFactory.get (especially since there might be a longish time window there since we might block to load a library etc), so I don't think we lose anything from plugging that hole by using computeIfAbsent here. I think your observations about potential issues in JRTFS is correct, but there was nothing to suggest JRTFS code was involved in JDK-8174817 (as it's not code that's used by the BuiltinClassLoader). Thanks! /Claes On 2017-02-15 21:52, Peter Levart wrote: > Hi Claes, > > Reading the https://bugs.openjdk.java.net/browse/JDK-8174817 and then > the change that was just pushed, I can't seem to figure out what was the > problem with original code. I can't find evidence for claims in > https://bugs.openjdk.java.net/browse/JDK-8175010 . Is the problem > publication of ImageReader via ImageReaderFactory? That can't be it, > since ImageReaderFactory is using ConcurrentHashMap which ensures > happens before relationships. > > Is there any place else where ImageReader.open(Path) is called and then > the instance unsafely published to other threads? The only place I could > find is in jdk.internal.jrtfs.SystemImage.open(): > > static SystemImage open() throws IOException { > if (modulesImageExists) { > // open a .jimage and build directory structure > final ImageReader image = ImageReader.open(moduleImageFile); > image.getRootDirectory(); > return new SystemImage() { > @Override > Node findNode(String path) throws IOException { > return image.findNode(path); > } > @Override > byte[] getResource(Node node) throws IOException { > return image.getResource(node); > } > @Override > void close() throws IOException { > image.close(); > } > }; > } > > ...here the final 'image' local variable is captured by anonymous inner > SystemImage subclass into a synthetic final field, so this final field > ensures that ImageReader is published safely as a delegate of SystemImage. > > ImageReader.open(Path) factory method delegates to > ImageReader.SharedImageReader.open(Path, ByteOrder) which creates a new > instance of ImageReader encapsulating a SharedImageReader object: > > public static ImageReader open(Path imagePath, ByteOrder > byteOrder) throws IOException { > Objects.requireNonNull(imagePath); > Objects.requireNonNull(byteOrder); > > synchronized (OPEN_FILES) { > SharedImageReader reader = OPEN_FILES.get(imagePath); > > if (reader == null) { > // Will fail with an IOException if wrong byteOrder. > reader = new SharedImageReader(imagePath, byteOrder); > OPEN_FILES.put(imagePath, reader); > } else if (reader.getByteOrder() != byteOrder) { > throw new IOException("\"" + reader.getName() + "\" > is not an image file"); > } > > ImageReader image = new ImageReader(reader); // <<-- HERE > reader.openers.add(image); > > return image; > } > } > > ...the ImageReader returned from this method is not safe to publish via > data race, but as far as I can see, there is no such publishing going > on. So am I right in that all this patch solves is it eliminates a > possibility of NPE when ImageReader is close()-d concurrently with being > used from some other thread. If such NPE was observed, it means that > close() is being called concurrently with access and there are still > races possible which can cause undesired effects. For example: calling > ImageReader.close() while using it concurrently may close underlying > SharedImageReader and then after closing, access it. > > So is there a concurrent ImageReader.close() possible? The only place I > see ImageReader.close() being invoked is from SystemImage.close() in the > anonymous inner class implementation which wraps ImageReader. > SystemImage.close() is only being invoked from JrtFileSystem.cleanup(), > which is called from JrtFileSystem.close() and JrtFileSystem.finalize(). > > The following is theoretically possible: > > FileSystem fs = FileSystems.newFileSystem(URI.create("jrt:/"), ...); > > Path p = fs.getPath(...); > FileSystemProvider provider = fs.provider(); > InputStream is = provider.newInputStream(p, ...); > // 'fs' and 'p' (which has a reference to 'fs') may be found finalizable > and be finalized while the call to obtain content of input stream is in > progress > > For this to be prevented, the following method in JrtFileSystem: > > // returns the content of the file resource specified by the path > byte[] getFileContent(JrtPath path) throws IOException { > Node node = checkNode(path); > if (node.isDirectory()) { > throw new FileSystemException(path + " is a directory"); > } > //assert node.isResource() : "resource node expected here"; > return image.getResource(node); > } > > ...would have to be changed to: > > byte[] getFileContent(JrtPath path) throws IOException { > Node node = checkNode(path); > if (node.isDirectory()) { > throw new FileSystemException(path + " is a directory"); > } > //assert node.isResource() : "resource node expected here"; > byte[] content = image.getResource(node); > Reference.reachabilityFence(this); > return content; > } > > > I don't claim that this is what causes the problems and I haven't found > any such usages, but this is theoretically possible. > > Regards, Peter > > On 02/15/2017 02:22 PM, Claes Redestad wrote: >> Hi, >> >> a few intermittent but rare test failures[1] that has appeared >> since the latest jake integration, and since one of the changes >> in there was to make initialization of the system ImageReader >> lazy there appears to be cases where ImageReaders are not >> safely published: >> >> - Ensure ImageReader::open is called only once per Path in >> ImageReaderFactory by using CHM.computeIfAbsent >> - Ensure ImageReader.reader is safely published to a >> final field and signal close using a volatile boolean instead >> >> webrev: http://cr.openjdk.java.net/~redestad/8175010/webrev.02/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8175010 >> >> Testing shows no issues (which admittedly doesn't mean we're >> actually solving the root cause for JDK-8174817), and performance >> numbers from adding a volatile read indicate that any overhead >> is lost in the noise on ImageReader-heavy workloads. >> >> Thanks! >> >> /Claes >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8174817 > From doug.simon at oracle.com Tue Feb 14 13:34:47 2017 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 14 Feb 2017 14:34:47 +0100 Subject: Running jaotc with an external Graal In-Reply-To: References: Message-ID: <5EF9A80E-8E23-4DB5-96CB-38E861F6D4A0@oracle.com> I don?t know how one patches a module in the middle of the module graph. That is, we use --patch-module and --upgrade-module-path to override the jdk.vm.compiler module in the JDK. I don?t know what that means for modules such as jdk.aot that depend on jdk.vm.compiler. Maybe someone from the AOT or jigsaw team can help. -Doug > On 14 Feb 2017, at 12:26, Andrew Haley wrote: > > Is this possible? Seems that no matter what I do, aotc always prefers to > use the internal version of org.graalvm.compiler which is in HotSpot. > > I don't quite get why this is: I can run an external Graal using JVMCI > with no problems. I saw "8145337: [JVMCI] JVMCI initialization with > SecurityManager installed fails:" which might be related, but perhaps > it's not. > > So, why is it possible to use an external Graal with JVMCI, but > apparently not with jaotc? And is there anything I can do to make > progress? > > Thanks, > > Andrew. From cthalinger at twitter.com Wed Feb 15 21:56:41 2017 From: cthalinger at twitter.com (Christian Thalinger) Date: Wed, 15 Feb 2017 11:56:41 -1000 Subject: Running jaotc with an external Graal In-Reply-To: <933396d6-b5eb-290d-831c-b8883de8c025@redhat.com> References: <5EF9A80E-8E23-4DB5-96CB-38E861F6D4A0@oracle.com> <677898c0-cc47-cea4-355d-a72bbcf80f7b@redhat.com> <4dd82907-8da0-ac21-92f9-8c784ec2674a@oracle.com> <933396d6-b5eb-290d-831c-b8883de8c025@redhat.com> Message-ID: <4674B2C0-9C4C-4B99-AF04-84A1AA39015A@twitter.com> > On Feb 14, 2017, at 4:38 AM, Andrew Haley wrote: > > On 14/02/17 14:37, Alan Bateman wrote: >> --patch-module can be used to patch any module in the boot layer. So if >> you are looking to override or add classes then --patch-module should work. > > Aha! Thanks, Does it? From mandy.chung at oracle.com Wed Feb 15 22:44:19 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 15 Feb 2017 14:44:19 -0800 Subject: Running jaotc with an external Graal In-Reply-To: <4674B2C0-9C4C-4B99-AF04-84A1AA39015A@twitter.com> References: <5EF9A80E-8E23-4DB5-96CB-38E861F6D4A0@oracle.com> <677898c0-cc47-cea4-355d-a72bbcf80f7b@redhat.com> <4dd82907-8da0-ac21-92f9-8c784ec2674a@oracle.com> <933396d6-b5eb-290d-831c-b8883de8c025@redhat.com> <4674B2C0-9C4C-4B99-AF04-84A1AA39015A@twitter.com> Message-ID: <9AFEE7EF-BCB8-47E3-B8D7-0BF1E2274805@oracle.com> > On Feb 15, 2017, at 1:56 PM, Christian Thalinger wrote: > > >> On Feb 14, 2017, at 4:38 AM, Andrew Haley wrote: >> >> On 14/02/17 14:37, Alan Bateman wrote: >>> --patch-module can be used to patch any module in the boot layer. So if >>> you are looking to override or add classes then --patch-module should work. >> >> Aha! Thanks, > > Does it? Yes it does except that module-info.class can?t be patched. You will get a warning if the patched path contains module-info.class. Are you seeing the otherwise? Mandy From claes.redestad at oracle.com Wed Feb 15 22:46:40 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 15 Feb 2017 23:46:40 +0100 Subject: Review Request: JDK-8173374: Update GenGraphs tool to generate dot graph with requires transitive edges In-Reply-To: <2534D0B6-6E60-46F0-82F1-56A1351B0EF7@oracle.com> References: <2C639879-5087-4D66-93DB-039A4F2167E0@oracle.com> <60a144a8-8586-c908-d4c1-528c5848d14d@oracle.com> <2754C848-4663-4E7E-B415-7715F8F1629C@oracle.com> <01155702-0a6e-afc0-23cf-fd872407edae@oracle.com> <2534D0B6-6E60-46F0-82F1-56A1351B0EF7@oracle.com> Message-ID: On 2017-02-15 22:08, Mandy Chung wrote: > >> On Feb 15, 2017, at 12:27 PM, Daniel Fuchs wrote: >> >> Hi Mandy, >> >>> Updated webrev: >>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173374/webrev.01/ >> >> Looks good. I haven't reviewed the build changes. >> I assume they're OK if you managed to build ;-) > > Thanks. > > The build change is trivial adding ?-add-exports for compiling and running GenGraphs build tool. Also add a new target to generate spec-only module graphs. +1 /Claes > > Mandy > From forax at univ-mlv.fr Wed Feb 15 23:43:40 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 16 Feb 2017 00:43:40 +0100 (CET) Subject: Running jaotc with an external Graal In-Reply-To: <9AFEE7EF-BCB8-47E3-B8D7-0BF1E2274805@oracle.com> References: <5EF9A80E-8E23-4DB5-96CB-38E861F6D4A0@oracle.com> <677898c0-cc47-cea4-355d-a72bbcf80f7b@redhat.com> <4dd82907-8da0-ac21-92f9-8c784ec2674a@oracle.com> <933396d6-b5eb-290d-831c-b8883de8c025@redhat.com> <4674B2C0-9C4C-4B99-AF04-84A1AA39015A@twitter.com> <9AFEE7EF-BCB8-47E3-B8D7-0BF1E2274805@oracle.com> Message-ID: <716343417.1404138.1487202220423.JavaMail.zimbra@u-pem.fr> Can i say again that when using --patch-module, module-info.class should be merged instead of having a warning ? R?mi ----- Mail original ----- > De: "Mandy Chung" > ?: "Christian Thalinger" > Cc: jigsaw-dev at openjdk.java.net, "hotspot compiler" , graal-dev at openjdk.java.net > Envoy?: Mercredi 15 F?vrier 2017 23:44:19 > Objet: Re: Running jaotc with an external Graal >> On Feb 15, 2017, at 1:56 PM, Christian Thalinger wrote: >> >> >>> On Feb 14, 2017, at 4:38 AM, Andrew Haley wrote: >>> >>> On 14/02/17 14:37, Alan Bateman wrote: >>>> --patch-module can be used to patch any module in the boot layer. So if >>>> you are looking to override or add classes then --patch-module should work. >>> >>> Aha! Thanks, >> >> Does it? > > Yes it does except that module-info.class can?t be patched. You will get a > warning if the patched path contains module-info.class. Are you seeing the > otherwise? > > Mandy From magnus.ihse.bursie at oracle.com Thu Feb 16 08:01:06 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 16 Feb 2017 09:01:06 +0100 Subject: RFR: 8175026: Capture build-time parameters to --generate-jli-classes In-Reply-To: <7c594b2c-a89c-8715-e65d-9442cf6005a7@oracle.com> References: <7c594b2c-a89c-8715-e65d-9442cf6005a7@oracle.com> Message-ID: <498526b6-79bb-ca0d-cb7f-536f4360a7a4@oracle.com> On 2017-02-15 18:12, Claes Redestad wrote: > Hi, > > currently the file we generate at build time as input to > --generate-jli-classes is lost when linking custom images, which means > user generate images may perform worse in certain ways, mostly > generating more classes during startup. > > Additionally, there's a strong assumption in --generate-jli-classes that > the VM running jlink is going to generate compatible classes with the > image being linked, which we can only really guarantee if the java.base > in the linked image is of the same version as the java.base in the VM > running jlink. This patch tightens these checks to ensure we have > freedom to evolve and re-evaluate the implementation in future > releases. > > JDK: http://cr.openjdk.java.net/~redestad/8175026/jdk.01/ > Top: http://cr.openjdk.java.net/~redestad/8175026/top.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8175026 > > Thanks! Build changes look good. /Magnus From david.holmes at oracle.com Thu Feb 16 08:08:20 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 Feb 2017 18:08:20 +1000 Subject: RFR: 8175010: ImageReader is not thread-safe In-Reply-To: References: Message-ID: <6094bb65-d5d2-dc9d-97b3-e5aacd8b6d28@oracle.com> Hi Claes, On 15/02/2017 11:22 PM, Claes Redestad wrote: > Hi, > > a few intermittent but rare test failures[1] that has appeared > since the latest jake integration, and since one of the changes > in there was to make initialization of the system ImageReader > lazy there appears to be cases where ImageReaders are not > safely published: I find it very hard to discern exactly how these classes are intended to be used concurrently. Is there some lifecycle description of the ImageReader and how it is intended to be used? Without any synchronization I still see lots of not-thread-safe code. Simple example: 75 public void close() throws IOException { 76 if (closed) { 77 throw new IOException("image file already closed"); 78 } 79 reader.close(this); 80 closed = true; 81 } two threads can still both call reader.close(this) concurrently. And if the new closed volatile boolean solves something then wouldn't making the reader variable volatile achieve the same JMM affects? David ----- > - Ensure ImageReader::open is called only once per Path in > ImageReaderFactory by using CHM.computeIfAbsent > - Ensure ImageReader.reader is safely published to a > final field and signal close using a volatile boolean instead > > webrev: http://cr.openjdk.java.net/~redestad/8175010/webrev.02/ > bug: https://bugs.openjdk.java.net/browse/JDK-8175010 > > Testing shows no issues (which admittedly doesn't mean we're > actually solving the root cause for JDK-8174817), and performance > numbers from adding a volatile read indicate that any overhead > is lost in the noise on ImageReader-heavy workloads. > > Thanks! > > /Claes > > [1] https://bugs.openjdk.java.net/browse/JDK-8174817 From jzaugg at gmail.com Thu Feb 16 08:15:33 2017 From: jzaugg at gmail.com (Jason Zaugg) Date: Thu, 16 Feb 2017 08:15:33 +0000 Subject: Performance of JrtFileSystemProvider.exists Message-ID: Recently I modified the Scala compiler to read class files jrt:/ filesystem, rather than relying on rt.jar. I noticed a slowdown when running on JDK 9 ea and exercising this code. Profiles suggest that the bottleneck is in calls to Files.exists. JrtFileSystemProvider inherits an implementation which needs to construct, throw and catch NoSuchFileException to answer in the negative. It is possible that I'm calling this more often than needed, and could implement a caching layer. But it seems worthwhile for jrtfs to implement a fast path for exists, as is done in UnixFileSystemProvider. Possibly related bug "Startup regression with Jython": https://bugs.openjdk.java.net/browse/JDK-8166236 Regards, Jason Zaugg From peter.levart at gmail.com Thu Feb 16 08:17:15 2017 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 16 Feb 2017 09:17:15 +0100 Subject: RFR: 8175010: ImageReader is not thread-safe In-Reply-To: References: Message-ID: <46f932d2-426a-7134-70b0-383597b79e7b@gmail.com> Hi Claes, On 02/15/2017 10:41 PM, Claes Redestad wrote: > Hi Peter, > > are you suggesting that if I have class Foo { Bar b; }, then creating > and putting Foo b in a CHM before returning it to a consumer which is > then read from another thread is enough to force b to be safely > published even when the other thread does *not* get the object via a > call to the same CHM (which would go via the same volatile read and add > the necessary happens before relationship)? I recalled having seen > examples to the effect that a non-volatile b isn't safely published in > this case. No, I'm not suggesting that. I'm merely observing (and hoping that my IDE didn't miss places in code where this is not the case) that there is no unsafe publication going on here. Obtaining ImageReader from ImageReaderFactory.get() is safe as it either returns an instance constructed in the same thread or it returns an instance constructed in a different thread, but in that case, the instance is handed through CHM.set/get which enforces ordering. The only other place where I found ImageReader.open() call is in constructing the SystemImage implementation as an anonymous inner instance which holds an ImageReader in its synthetic final field which ensures safe publication of ImageReader even if SystemImage instance is published unsafely. > > The (very shaky) hypothesis is thus that this could be what's happening > in any of the places which load and locally cache the system ImageReader > for anyone to use, e.g., SystemModuleFinder.SystemImage ...here the ImageReader instance is obtained via ImageReaderFactory.getImageReader(): /** * Holder class for the ImageReader */ private static class SystemImage { static final ImageReader READER; static { long t0 = System.nanoTime(); READER = ImageReaderFactory.getImageReader(); initTime.addElapsedTimeFrom(t0); } static ImageReader reader() { return READER; } } ...which is just a shortcut for ImageReaderFactory.get(BOOT_MODULES_JIMAGE) and I believe ImageReaderFactory.get() publishes (and did publish even before the patch) ImageReader instances safely (old code): 52 private static final Map readers = new ConcurrentHashMap<>(); 53 54 /** 55 * Returns an {@code ImageReader} to read from the given image file 56 */ 57 public static ImageReader get(Path jimage) throws IOException { 58 Objects.requireNonNull(jimage); 59 ImageReader reader = readers.get(jimage); 60 if (reader != null) { 61 return reader; // <<-- HERE the instance was handed through CHM 62 } 63 reader = ImageReader.open(jimage); 64 // potential race with other threads opening the same URL 65 ImageReader r = readers.putIfAbsent(jimage, reader); 66 if (r == null) { 67 return reader; // <<-- HERE the instance was constructed in same thread 68 } else { 69 reader.close(); 70 return r; // <<-- HERE the instance was handed through CHM 71 } 72 } > or > JavaRuntimeURLConnection (which is implicitly called when there's a > security manager installed). ...here the instance is also obtained via ImageReaderFactory.getImageReader(): // ImageReader to access resources in jimage private static final ImageReader reader; static { PrivilegedAction pa = ImageReaderFactory::getImageReader; reader = AccessController.doPrivileged(pa); } In both above places the ImageReader instance is obtained in and this is another "layer" of synchronization between consumer and producer threads. > I might be (in fact likely am) wrong, but > we discussed this offline and came to the conclusion that there was no > harm in implementing these improvements regardless of whether they > actually resolve 8174817 or not. No, there's no harm and I support the changes. It's just that they might not help in resolving the problem. > > I think prior to this patch a concurrent ImageReader.close() could > happen if there was a race between 3 or more threads to resolve the > same Path from ImageReaderFactory.get (especially since there might be > a longish time window there since we might block to load a library > etc), so I don't think we lose anything from plugging that hole by > using computeIfAbsent here. I don't believe this was the the source of concurrent close(). If you look at the code (above), you can see that reader.close() (line 69) is called only if the reader was not successfully published and it is called by the thread that constructed it. But computeIfAbsent is a good choice here to avoid optimistic constructions followed by close(s) when there is concurrency. > > I think your observations about potential issues in JRTFS is correct, > but there was nothing to suggest JRTFS code was involved in JDK-8174817 > (as it's not code that's used by the BuiltinClassLoader). The only remaining ImageReader.close() invocation is now in jdk.internal.jrtfs.SystemImage anonymous inner class delegated from SystemImage.close(), which is only called from JrtFileSystem.close() or .finalize(). So you think JRTFS is not the source of the problem? What if JRTFS is accessing the same image as JavaRuntimeURLConnection in the same VM. Different instances of ImageReader would be used for them, but they would share the same underlying SharedImageReader. Currently I don't see a problem in SharedImageReader code, but I haven't studied it carefully yet. Maybe there is something to be found there... Regards, Peter > > Thanks! > > /Claes > > On 2017-02-15 21:52, Peter Levart wrote: >> Hi Claes, >> >> Reading the https://bugs.openjdk.java.net/browse/JDK-8174817 and then >> the change that was just pushed, I can't seem to figure out what was the >> problem with original code. I can't find evidence for claims in >> https://bugs.openjdk.java.net/browse/JDK-8175010 . Is the problem >> publication of ImageReader via ImageReaderFactory? That can't be it, >> since ImageReaderFactory is using ConcurrentHashMap which ensures >> happens before relationships. >> >> Is there any place else where ImageReader.open(Path) is called and then >> the instance unsafely published to other threads? The only place I could >> find is in jdk.internal.jrtfs.SystemImage.open(): >> >> static SystemImage open() throws IOException { >> if (modulesImageExists) { >> // open a .jimage and build directory structure >> final ImageReader image = ImageReader.open(moduleImageFile); >> image.getRootDirectory(); >> return new SystemImage() { >> @Override >> Node findNode(String path) throws IOException { >> return image.findNode(path); >> } >> @Override >> byte[] getResource(Node node) throws IOException { >> return image.getResource(node); >> } >> @Override >> void close() throws IOException { >> image.close(); >> } >> }; >> } >> >> ...here the final 'image' local variable is captured by anonymous inner >> SystemImage subclass into a synthetic final field, so this final field >> ensures that ImageReader is published safely as a delegate of >> SystemImage. >> >> ImageReader.open(Path) factory method delegates to >> ImageReader.SharedImageReader.open(Path, ByteOrder) which creates a new >> instance of ImageReader encapsulating a SharedImageReader object: >> >> public static ImageReader open(Path imagePath, ByteOrder >> byteOrder) throws IOException { >> Objects.requireNonNull(imagePath); >> Objects.requireNonNull(byteOrder); >> >> synchronized (OPEN_FILES) { >> SharedImageReader reader = OPEN_FILES.get(imagePath); >> >> if (reader == null) { >> // Will fail with an IOException if wrong byteOrder. >> reader = new SharedImageReader(imagePath, >> byteOrder); >> OPEN_FILES.put(imagePath, reader); >> } else if (reader.getByteOrder() != byteOrder) { >> throw new IOException("\"" + reader.getName() + "\" >> is not an image file"); >> } >> >> ImageReader image = new ImageReader(reader); // <<-- >> HERE >> reader.openers.add(image); >> >> return image; >> } >> } >> >> ...the ImageReader returned from this method is not safe to publish via >> data race, but as far as I can see, there is no such publishing going >> on. So am I right in that all this patch solves is it eliminates a >> possibility of NPE when ImageReader is close()-d concurrently with being >> used from some other thread. If such NPE was observed, it means that >> close() is being called concurrently with access and there are still >> races possible which can cause undesired effects. For example: calling >> ImageReader.close() while using it concurrently may close underlying >> SharedImageReader and then after closing, access it. >> >> So is there a concurrent ImageReader.close() possible? The only place I >> see ImageReader.close() being invoked is from SystemImage.close() in the >> anonymous inner class implementation which wraps ImageReader. >> SystemImage.close() is only being invoked from JrtFileSystem.cleanup(), >> which is called from JrtFileSystem.close() and JrtFileSystem.finalize(). >> >> The following is theoretically possible: >> >> FileSystem fs = FileSystems.newFileSystem(URI.create("jrt:/"), ...); >> >> Path p = fs.getPath(...); >> FileSystemProvider provider = fs.provider(); >> InputStream is = provider.newInputStream(p, ...); >> // 'fs' and 'p' (which has a reference to 'fs') may be found finalizable >> and be finalized while the call to obtain content of input stream is in >> progress >> >> For this to be prevented, the following method in JrtFileSystem: >> >> // returns the content of the file resource specified by the path >> byte[] getFileContent(JrtPath path) throws IOException { >> Node node = checkNode(path); >> if (node.isDirectory()) { >> throw new FileSystemException(path + " is a directory"); >> } >> //assert node.isResource() : "resource node expected here"; >> return image.getResource(node); >> } >> >> ...would have to be changed to: >> >> byte[] getFileContent(JrtPath path) throws IOException { >> Node node = checkNode(path); >> if (node.isDirectory()) { >> throw new FileSystemException(path + " is a directory"); >> } >> //assert node.isResource() : "resource node expected here"; >> byte[] content = image.getResource(node); >> Reference.reachabilityFence(this); >> return content; >> } >> >> >> I don't claim that this is what causes the problems and I haven't found >> any such usages, but this is theoretically possible. >> >> Regards, Peter >> >> On 02/15/2017 02:22 PM, Claes Redestad wrote: >>> Hi, >>> >>> a few intermittent but rare test failures[1] that has appeared >>> since the latest jake integration, and since one of the changes >>> in there was to make initialization of the system ImageReader >>> lazy there appears to be cases where ImageReaders are not >>> safely published: >>> >>> - Ensure ImageReader::open is called only once per Path in >>> ImageReaderFactory by using CHM.computeIfAbsent >>> - Ensure ImageReader.reader is safely published to a >>> final field and signal close using a volatile boolean instead >>> >>> webrev: http://cr.openjdk.java.net/~redestad/8175010/webrev.02/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8175010 >>> >>> Testing shows no issues (which admittedly doesn't mean we're >>> actually solving the root cause for JDK-8174817), and performance >>> numbers from adding a volatile read indicate that any overhead >>> is lost in the noise on ImageReader-heavy workloads. >>> >>> Thanks! >>> >>> /Claes >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8174817 >> From Alan.Bateman at oracle.com Thu Feb 16 08:44:20 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 16 Feb 2017 08:44:20 +0000 Subject: Performance of JrtFileSystemProvider.exists In-Reply-To: References: Message-ID: On 16/02/2017 08:15, Jason Zaugg wrote: > Recently I modified the Scala compiler to read class files > jrt:/ filesystem, rather than relying on rt.jar. > > I noticed a slowdown when running on JDK 9 ea and exercising this code. > Profiles suggest that the bottleneck is in calls to Files.exists. > JrtFileSystemProvider inherits an implementation which needs to construct, > throw and catch NoSuchFileException to answer in the negative. > > It is possible that I'm calling this more often than needed, and could > implement a caching layer. But it seems worthwhile for jrtfs to implement a > fast path for exists, as is done in UnixFileSystemProvider. > > Possibly related bug "Startup regression with Jython": > https://bugs.openjdk.java.net/browse/JDK-8166236 > As it happens, we a similar issue with the zip provider. It's something that I was looking at with Sherman recently and we have a proposal to push the exists down to the provider interface so that it can be overridden. So a different issues to JDK-8166236 - that one is that Jython seems to create a cache on first usage of all classes that it finds in rt.jar. I assume that if/when Jython adds support for JDK 9 and jrtfs that they will be able to integrate it with their caching. -Alan From claes.redestad at oracle.com Thu Feb 16 08:47:32 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 16 Feb 2017 09:47:32 +0100 Subject: RFR: 8175010: ImageReader is not thread-safe In-Reply-To: <46f932d2-426a-7134-70b0-383597b79e7b@gmail.com> References: <46f932d2-426a-7134-70b0-383597b79e7b@gmail.com> Message-ID: On 2017-02-16 09:17, Peter Levart wrote: >> I think your observations about potential issues in JRTFS is correct, >> but there was nothing to suggest JRTFS code was involved in JDK-8174817 >> (as it's not code that's used by the BuiltinClassLoader). > > The only remaining ImageReader.close() invocation is now in > jdk.internal.jrtfs.SystemImage anonymous inner class delegated from > SystemImage.close(), which is only called from JrtFileSystem.close() or > .finalize(). So you think JRTFS is not the source of the problem? What > if JRTFS is accessing the same image as JavaRuntimeURLConnection in the > same VM. Different instances of ImageReader would be used for them, but > they would share the same underlying SharedImageReader. Currently I > don't see a problem in SharedImageReader code, but I haven't studied it > carefully yet. Maybe there is something to be found there... > Nothing is impossible, there was simply no breadcrumbs to suggest this was happening. One thing I think we should do to rule this out is to make sure that the SharedImageReader representing the system image simply can't be closed, which would really be an error. /Claes From claes.redestad at oracle.com Thu Feb 16 08:50:44 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 16 Feb 2017 09:50:44 +0100 Subject: RFR: 8175010: ImageReader is not thread-safe In-Reply-To: <6094bb65-d5d2-dc9d-97b3-e5aacd8b6d28@oracle.com> References: <6094bb65-d5d2-dc9d-97b3-e5aacd8b6d28@oracle.com> Message-ID: Hi David, On 2017-02-16 09:08, David Holmes wrote: > Hi Claes, > > On 15/02/2017 11:22 PM, Claes Redestad wrote: >> Hi, >> >> a few intermittent but rare test failures[1] that has appeared >> since the latest jake integration, and since one of the changes >> in there was to make initialization of the system ImageReader >> lazy there appears to be cases where ImageReaders are not >> safely published: > > I find it very hard to discern exactly how these classes are intended to > be used concurrently. Is there some lifecycle description of the > ImageReader and how it is intended to be used? Without any > synchronization I still see lots of not-thread-safe code. Simple example: > > 75 public void close() throws IOException { > 76 if (closed) { > 77 throw new IOException("image file already closed"); > 78 } > 79 reader.close(this); > 80 closed = true; > 81 } > > two threads can still both call reader.close(this) concurrently. And if > the new closed volatile boolean solves something then wouldn't making > the reader variable volatile achieve the same JMM affects? reader.close(this) calls will synchronize on SharedImageReader.OPEN_FILES, so concurrent calls on the same ImageReader should be OK. We should add a comment to point this out. /Claes > > David > ----- > >> - Ensure ImageReader::open is called only once per Path in >> ImageReaderFactory by using CHM.computeIfAbsent >> - Ensure ImageReader.reader is safely published to a >> final field and signal close using a volatile boolean instead >> >> webrev: http://cr.openjdk.java.net/~redestad/8175010/webrev.02/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8175010 >> >> Testing shows no issues (which admittedly doesn't mean we're >> actually solving the root cause for JDK-8174817), and performance >> numbers from adding a volatile read indicate that any overhead >> is lost in the noise on ImageReader-heavy workloads. >> >> Thanks! >> >> /Claes >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8174817 From Alan.Bateman at oracle.com Thu Feb 16 08:59:14 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 16 Feb 2017 08:59:14 +0000 Subject: RFR: 8175010: ImageReader is not thread-safe In-Reply-To: <6094bb65-d5d2-dc9d-97b3-e5aacd8b6d28@oracle.com> References: <6094bb65-d5d2-dc9d-97b3-e5aacd8b6d28@oracle.com> Message-ID: <0bf888a2-f1f3-7991-e200-d73e429ea3b6@oracle.com> On 16/02/2017 08:08, David Holmes wrote: > > I find it very hard to discern exactly how these classes are intended > to be used concurrently. Is there some lifecycle description of the > ImageReader and how it is intended to be used? Without any > synchronization I still see lots of not-thread-safe code. Simple example: > > 75 public void close() throws IOException { > 76 if (closed) { > 77 throw new IOException("image file already closed"); > 78 } > 79 reader.close(this); > 80 closed = true; > 81 } > > two threads can still both call reader.close(this) concurrently. And > if the new closed volatile boolean solves something then wouldn't > making the reader variable volatile achieve the same JMM affects? There are essentially two usages: 1. At run-time then the jimage file is memory mapped and that mapping is shared between the VM and libraries. There should be one ImageReader and it should never be closed. If it accidentally closed then it leads to spurious NCDFE and a painful death. The patch that Claes pushed to move to computeIfAbsent ensures that we only create the ImageReader once. It's possible this will mask the issue that is lurking we don't know yet. 2. jrtfs, used by javac and other tools. It's not in current picture but with jrtfs then jimage files will be opened + closed. The close method that you pasted in clearly doesn't handle async close but it requires going into the reader implementations to see if there are issues or not. -Alan From aph at redhat.com Thu Feb 16 09:17:12 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 16 Feb 2017 09:17:12 +0000 Subject: Running jaotc with an external Graal In-Reply-To: <4674B2C0-9C4C-4B99-AF04-84A1AA39015A@twitter.com> References: <5EF9A80E-8E23-4DB5-96CB-38E861F6D4A0@oracle.com> <677898c0-cc47-cea4-355d-a72bbcf80f7b@redhat.com> <4dd82907-8da0-ac21-92f9-8c784ec2674a@oracle.com> <933396d6-b5eb-290d-831c-b8883de8c025@redhat.com> <4674B2C0-9C4C-4B99-AF04-84A1AA39015A@twitter.com> Message-ID: <3570b9d9-aeb3-bff1-e38b-d473d8b41474@redhat.com> On 15/02/17 21:56, Christian Thalinger wrote: > >> On Feb 14, 2017, at 4:38 AM, Andrew Haley wrote: >> >> On 14/02/17 14:37, Alan Bateman wrote: >>> --patch-module can be used to patch any module in the boot layer. So if >>> you are looking to override or add classes then --patch-module should work. >> >> Aha! Thanks, > > Does it? Not quite. The problem is that the service loader finds classes in the Hotspot copy of Graal which don't exist in the external copy, and chaos ensues. I suppose the only way to make it work is to replace the copy of Graal in HotSpot, but I don't think that's a trivial thing to do. Andrew. From doug.simon at oracle.com Thu Feb 16 09:33:42 2017 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 16 Feb 2017 10:33:42 +0100 Subject: Running jaotc with an external Graal In-Reply-To: <3570b9d9-aeb3-bff1-e38b-d473d8b41474@redhat.com> References: <5EF9A80E-8E23-4DB5-96CB-38E861F6D4A0@oracle.com> <677898c0-cc47-cea4-355d-a72bbcf80f7b@redhat.com> <4dd82907-8da0-ac21-92f9-8c784ec2674a@oracle.com> <933396d6-b5eb-290d-831c-b8883de8c025@redhat.com> <4674B2C0-9C4C-4B99-AF04-84A1AA39015A@twitter.com> <3570b9d9-aeb3-bff1-e38b-d473d8b41474@redhat.com> Message-ID: <455F160E-8154-4C93-8555-626289BC2BB3@oracle.com> With the current bits in jdk9/hs and graal-core, the following bootstrapping command works in terms of replacing Graal in the JDK: java -server -XX:+UnlockExperimentalVMOptions --module-path=/Users/dsimon/hs/truffle/mxbuild/modules/com.oracle.truffle.truffle_api.jar --upgrade-module-path=/Users/dsimon/hs/graal-core/mxbuild/modules/jdk.vm.compiler.jar --patch-module=jdk.vm.compiler=.jar -XX:+UseJVMCICompiler -XX:+BootstrapJVMCI -version However, the --patch-module + --upgrade-module-path trick[1] we?re using to replace the version of Graal in the JDK apparently only works due to a bug that will be fixed at some point. From Mandy Chung: "-?patch-module is to patch a module to replace or add content of that module and yes it disables the hash checking on the patched module. However, it?s not intended to allow it to combine with ?-upgrade-module-path as you did, to change the module dependences." Given all the continuing flux around jigsaw, we cannot be sure that developing and using GitHub Graal on JDK 9 is stable until jigsaw is stable. -Doug [1] https://bugs.openjdk.java.net/browse/JDK-8171448?focusedCommentId=14046154&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14046154 > On 16 Feb 2017, at 10:17, Andrew Haley wrote: > > On 15/02/17 21:56, Christian Thalinger wrote: >> >>> On Feb 14, 2017, at 4:38 AM, Andrew Haley wrote: >>> >>> On 14/02/17 14:37, Alan Bateman wrote: >>>> --patch-module can be used to patch any module in the boot layer. So if >>>> you are looking to override or add classes then --patch-module should work. >>> >>> Aha! Thanks, >> >> Does it? > > Not quite. The problem is that the service loader finds classes in > the Hotspot copy of Graal which don't exist in the external copy, and > chaos ensues. > > I suppose the only way to make it work is to replace the copy of Graal > in HotSpot, but I don't think that's a trivial thing to do. > > Andrew. > From aph at redhat.com Thu Feb 16 12:25:04 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 16 Feb 2017 12:25:04 +0000 Subject: Running jaotc with an external Graal In-Reply-To: <455F160E-8154-4C93-8555-626289BC2BB3@oracle.com> References: <5EF9A80E-8E23-4DB5-96CB-38E861F6D4A0@oracle.com> <677898c0-cc47-cea4-355d-a72bbcf80f7b@redhat.com> <4dd82907-8da0-ac21-92f9-8c784ec2674a@oracle.com> <933396d6-b5eb-290d-831c-b8883de8c025@redhat.com> <4674B2C0-9C4C-4B99-AF04-84A1AA39015A@twitter.com> <3570b9d9-aeb3-bff1-e38b-d473d8b41474@redhat.com> <455F160E-8154-4C93-8555-626289BC2BB3@oracle.com> Message-ID: <8093ab13-e039-c03c-136d-4518e46e1d81@redhat.com> On 16/02/17 09:33, Doug Simon wrote: > With the current bits in jdk9/hs and graal-core, the following bootstrapping command works in terms of replacing Graal in the JDK: > > java -server -XX:+UnlockExperimentalVMOptions --module-path=/Users/dsimon/hs/truffle/mxbuild/modules/com.oracle.truffle.truffle_api.jar --upgrade-module-path=/Users/dsimon/hs/graal-core/mxbuild/modules/jdk.vm.compiler.jar --patch-module=jdk.vm.compiler=.jar -XX:+UseJVMCICompiler -XX:+BootstrapJVMCI -version > > However, the --patch-module + --upgrade-module-path trick[1] we?re using to replace the version of Graal in the JDK apparently only works due to a bug that will be fixed at some point. From Mandy Chung: Magic, thank you. This works: ~/jdk10/hs/build/linux-aarch64-normal-server-release/jdk/bin/java \ -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI \ --add-exports=java.base/jdk.internal.module=jdk.vm.compiler \ --upgrade-module-path=/nfs/zebedee/home/graal/aph/graal-core/mxbuild/modules/jdk.vm.compiler.jar \ --patch-module=jdk.vm.compiler=.jar \ --module-path=/nfs/zebedee/home/graal/aph/truffle/mxbuild/modules/com.oracle.truffle.truffle_api.jar:/nfs/zebedee/home/graal/aph/graal-core/mxbuild/modules/jdk.vm.compiler.jar \ -XX:+UseAOT -Djvmci.UseProfilingInformation=false \ -Dgraal.UseExceptionProbability=false -Djvmci.Compiler=graal \ --add-modules ALL-DEFAULT -m jdk.aot/jdk.tools.jaotc.Main ~/Hello.jar \ --output libHello.so I'm posting it here for posterity. It would indeed be very bad if we could not do something at least equivalent to this. Andrew. From claes.redestad at oracle.com Thu Feb 16 13:20:26 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 16 Feb 2017 14:20:26 +0100 Subject: RFR: 8175026: Capture build-time parameters to --generate-jli-classes In-Reply-To: References: <7c594b2c-a89c-8715-e65d-9442cf6005a7@oracle.com> Message-ID: Hi Mandy, On 02/15/2017 08:09 PM, Mandy Chung wrote: >> On Feb 15, 2017, at 9:12 AM, Claes Redestad wrote: >> >> Hi, >> >> currently the file we generate at build time as input to >> --generate-jli-classes is lost when linking custom images, which means >> user generate images may perform worse in certain ways, mostly >> generating more classes during startup. >> >> Additionally, there's a strong assumption in --generate-jli-classes that >> the VM running jlink is going to generate compatible classes with the >> image being linked, which we can only really guarantee if the java.base >> in the linked image is of the same version as the java.base in the VM >> running jlink. This patch tightens these checks to ensure we have >> freedom to evolve and re-evaluate the implementation in future >> releases. >> >> JDK: http://cr.openjdk.java.net/~redestad/8175026/jdk.01/ >> Top: http://cr.openjdk.java.net/~redestad/8175026/top.01/ > > This restriction sounds reasonable and we can enhance this in a future release. I think the plugin can record the configuration in its own format to be independent of the trace output format. > > Instead of throwing ISA, you can have a test method to return a boolean to indicate if the default trace file should be read. > > Instead of running java.base from the runtime, you can use Runtime.version() instead and I think comparing Version::major should be adequate. Sure, I've changed to compare Runtime.Version.major and minor. While minor differences should be fine, the plugin depends on internals that are subject to change in minor releases. To support experimentation and testing I've added a ignore-version suboption to override this. > This change disables this default setting entirely if the image being created is not the same version as this plugin (defaultSpecies and defaultInvokers, etc). Is it intended? Yes, this is intended, as we can't guarantee the code generated using one version of jlink will be compatible with the next; the format of the trace is also subject to change. > > In addition, if the main argument is specified but the version does not match, it will ignore the given argument. Should it be an error instead? We are the one who will generate a trace file and specify it in the jlink plugin option. It?s okay to ignore the default trace output if no plugin option is specified and I think no warning should be printed in this case. It?s just like this plugin is disabled. You may want to add a suboption to turn on verbose that will trace what is generated and what is ignored. I think a warning is reasonable in all cases: Using a different version of jlink than the java.base you're linking will lose some optimizations and the user would be none the wiser as to why, verbosity helps avoid surprises. http://cr.openjdk.java.net/~redestad/8175026/jdk.02/ More verbosity control would be great, but that seems like a good fit for a JDK 10 RFE. Thanks! /Claes > > Mandy > > > From mandy.chung at oracle.com Thu Feb 16 15:57:08 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 16 Feb 2017 07:57:08 -0800 Subject: Running jaotc with an external Graal In-Reply-To: <455F160E-8154-4C93-8555-626289BC2BB3@oracle.com> References: <5EF9A80E-8E23-4DB5-96CB-38E861F6D4A0@oracle.com> <677898c0-cc47-cea4-355d-a72bbcf80f7b@redhat.com> <4dd82907-8da0-ac21-92f9-8c784ec2674a@oracle.com> <933396d6-b5eb-290d-831c-b8883de8c025@redhat.com> <4674B2C0-9C4C-4B99-AF04-84A1AA39015A@twitter.com> <3570b9d9-aeb3-bff1-e38b-d473d8b41474@redhat.com> <455F160E-8154-4C93-8555-626289BC2BB3@oracle.com> Message-ID: <5DEE9908-53E3-4B4D-82A9-EE2A8D7D4DFB@oracle.com> > On Feb 16, 2017, at 1:33 AM, Doug Simon wrote: > > With the current bits in jdk9/hs and graal-core, the following bootstrapping command works in terms of replacing Graal in the JDK: > > java -server -XX:+UnlockExperimentalVMOptions --module-path=/Users/dsimon/hs/truffle/mxbuild/modules/com.oracle.truffle.truffle_api.jar --upgrade-module-path=/Users/dsimon/hs/graal-core/mxbuild/modules/jdk.vm.compiler.jar --patch-module=jdk.vm.compiler=.jar -XX:+UseJVMCICompiler -XX:+BootstrapJVMCI -version > > However, the --patch-module + --upgrade-module-path trick[1] we?re using to replace the version of Graal in the JDK apparently only works due to a bug that will be fixed at some point. From Mandy Chung: > > "-?patch-module is to patch a module to replace or add content of that module and yes it disables the hash checking on the patched module. However, it?s not intended to allow it to combine with ?-upgrade-module-path as you did, to change the module dependences.? > It?s a bug that --patch-module + --upgrade-module-path work as described above. I have a patch to fix ?-patch-module that no longer has to disable the hash checking but allow patching the content of the mdoule. I think we will need to look into the alternatives how Graal can be upgraded to a different version of module-info.class. Mandy > Given all the continuing flux around jigsaw, we cannot be sure that developing and using GitHub Graal on JDK 9 is stable until jigsaw is stable. > > -Doug > > [1] https://bugs.openjdk.java.net/browse/JDK-8171448?focusedCommentId=14046154&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14046154 > >> On 16 Feb 2017, at 10:17, Andrew Haley wrote: >> >> On 15/02/17 21:56, Christian Thalinger wrote: >>> >>>> On Feb 14, 2017, at 4:38 AM, Andrew Haley wrote: >>>> >>>> On 14/02/17 14:37, Alan Bateman wrote: >>>>> --patch-module can be used to patch any module in the boot layer. So if >>>>> you are looking to override or add classes then --patch-module should work. >>>> >>>> Aha! Thanks, >>> >>> Does it? >> >> Not quite. The problem is that the service loader finds classes in >> the Hotspot copy of Graal which don't exist in the external copy, and >> chaos ensues. >> >> I suppose the only way to make it work is to replace the copy of Graal >> in HotSpot, but I don't think that's a trivial thing to do. >> >> Andrew. >> > From claes.redestad at oracle.com Thu Feb 16 16:24:27 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 16 Feb 2017 17:24:27 +0100 Subject: RFR: 8175079: Lazy initialization of ImageReader breaks rmid Message-ID: Hi, please review this simple backout of a startup optimization that has proven to destabilize things like rmid. Patch inline.. Bug: https://bugs.openjdk.java.net/browse/JDK-8175079 diff -r 87f2a6fb4b9a src/java.base/share/classes/java/lang/System.java --- a/src/java.base/share/classes/java/lang/System.java Wed Feb 15 15:57:18 2017 +0100 +++ b/src/java.base/share/classes/java/lang/System.java Thu Feb 16 17:18:49 2017 +0100 @@ -1945,9 +1945,6 @@ // set security manager String cn = System.getProperty("java.security.manager"); if (cn != null) { - // ensure image reader for java.base is initialized before security manager - Object.class.getResource("module-info.class"); - if (cn.isEmpty() || "default".equals(cn)) { System.setSecurityManager(new SecurityManager()); } else { diff -r 87f2a6fb4b9a src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java --- a/src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java Wed Feb 15 15:57:18 2017 +0100 +++ b/src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java Thu Feb 16 17:18:49 2017 +0100 @@ -115,12 +115,7 @@ long t0 = System.nanoTime(); // system modules (may be patched) - ModuleFinder systemModules; - if (SystemModules.MODULE_NAMES.length > 0) { - systemModules = SystemModuleFinder.getInstance(); - } else { - systemModules = ModuleFinder.ofSystem(); - } + ModuleFinder systemModules = ModuleFinder.ofSystem(); PerfCounters.systemModulesTime.addElapsedTimeFrom(t0); An alternative patch is to move the force initialization of the image reader from initPhase3 to SecurityManager, which ensures it's initialized before a security manager is installed. This preserves the startup optimization in case a SM is not installed: diff -r 87f2a6fb4b9a src/java.base/share/classes/java/lang/SecurityManager.java --- a/src/java.base/share/classes/java/lang/SecurityManager.java Wed Feb 15 15:57:18 2017 +0100 +++ b/src/java.base/share/classes/java/lang/SecurityManager.java Thu Feb 16 17:23:57 2017 +0100 @@ -233,6 +233,11 @@ public class SecurityManager { + static { + // ensure image reader for java.base is initialized before security + // manager is installed + Object.class.getResource("module-info.class"); + } /** * This field is true if there is a security check in * progress; false otherwise. Thanks! /Claes From Alan.Bateman at oracle.com Thu Feb 16 16:27:00 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 16 Feb 2017 16:27:00 +0000 Subject: RFR: 8175079: Lazy initialization of ImageReader breaks rmid In-Reply-To: References: Message-ID: <0e5e4613-add1-8df9-3ea9-45a2a0907921@oracle.com> I think go with the first for now. -Alan On 16/02/2017 16:24, Claes Redestad wrote: > Hi, > > please review this simple backout of a startup optimization that has > proven to destabilize things like rmid. Patch inline.. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8175079 > > diff -r 87f2a6fb4b9a src/java.base/share/classes/java/lang/System.java > --- a/src/java.base/share/classes/java/lang/System.java Wed Feb 15 > 15:57:18 2017 +0100 > +++ b/src/java.base/share/classes/java/lang/System.java Thu Feb 16 > 17:18:49 2017 +0100 > @@ -1945,9 +1945,6 @@ > // set security manager > String cn = System.getProperty("java.security.manager"); > if (cn != null) { > - // ensure image reader for java.base is initialized > before security manager > - Object.class.getResource("module-info.class"); > - > if (cn.isEmpty() || "default".equals(cn)) { > System.setSecurityManager(new SecurityManager()); > } else { > diff -r 87f2a6fb4b9a > src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java > --- > a/src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java > Wed Feb 15 15:57:18 2017 +0100 > +++ > b/src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java > Thu Feb 16 17:18:49 2017 +0100 > @@ -115,12 +115,7 @@ > long t0 = System.nanoTime(); > > // system modules (may be patched) > - ModuleFinder systemModules; > - if (SystemModules.MODULE_NAMES.length > 0) { > - systemModules = SystemModuleFinder.getInstance(); > - } else { > - systemModules = ModuleFinder.ofSystem(); > - } > + ModuleFinder systemModules = ModuleFinder.ofSystem(); > > PerfCounters.systemModulesTime.addElapsedTimeFrom(t0); > > > An alternative patch is to move the force initialization of the image > reader from initPhase3 to SecurityManager, > which ensures it's initialized before a security manager is installed. > This preserves the startup optimization in > case a SM is not installed: > > diff -r 87f2a6fb4b9a > src/java.base/share/classes/java/lang/SecurityManager.java > --- a/src/java.base/share/classes/java/lang/SecurityManager.java Wed > Feb 15 15:57:18 2017 +0100 > +++ b/src/java.base/share/classes/java/lang/SecurityManager.java Thu > Feb 16 17:23:57 2017 +0100 > @@ -233,6 +233,11 @@ > public > class SecurityManager { > > + static { > + // ensure image reader for java.base is initialized before > security > + // manager is installed > + Object.class.getResource("module-info.class"); > + } > /** > * This field is true if there is a security check in > * progress; false otherwise. > > > Thanks! > > /Claes From claes.redestad at oracle.com Thu Feb 16 16:30:14 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 16 Feb 2017 17:30:14 +0100 Subject: RFR: 8175079: Lazy initialization of ImageReader breaks rmid In-Reply-To: <0e5e4613-add1-8df9-3ea9-45a2a0907921@oracle.com> References: <0e5e4613-add1-8df9-3ea9-45a2a0907921@oracle.com> Message-ID: Done! On 02/16/2017 05:27 PM, Alan Bateman wrote: > I think go with the first for now. > > -Alan > > > On 16/02/2017 16:24, Claes Redestad wrote: > >> Hi, >> >> please review this simple backout of a startup optimization that has >> proven to destabilize things like rmid. Patch inline.. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8175079 >> >> diff -r 87f2a6fb4b9a src/java.base/share/classes/java/lang/System.java >> --- a/src/java.base/share/classes/java/lang/System.java Wed Feb 15 >> 15:57:18 2017 +0100 >> +++ b/src/java.base/share/classes/java/lang/System.java Thu Feb 16 >> 17:18:49 2017 +0100 >> @@ -1945,9 +1945,6 @@ >> // set security manager >> String cn = System.getProperty("java.security.manager"); >> if (cn != null) { >> - // ensure image reader for java.base is initialized >> before security manager >> - Object.class.getResource("module-info.class"); >> - >> if (cn.isEmpty() || "default".equals(cn)) { >> System.setSecurityManager(new SecurityManager()); >> } else { >> diff -r 87f2a6fb4b9a >> src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java >> --- >> a/src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java >> Wed Feb 15 15:57:18 2017 +0100 >> +++ >> b/src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java >> Thu Feb 16 17:18:49 2017 +0100 >> @@ -115,12 +115,7 @@ >> long t0 = System.nanoTime(); >> >> // system modules (may be patched) >> - ModuleFinder systemModules; >> - if (SystemModules.MODULE_NAMES.length > 0) { >> - systemModules = SystemModuleFinder.getInstance(); >> - } else { >> - systemModules = ModuleFinder.ofSystem(); >> - } >> + ModuleFinder systemModules = ModuleFinder.ofSystem(); >> >> PerfCounters.systemModulesTime.addElapsedTimeFrom(t0); >> >> >> An alternative patch is to move the force initialization of the image >> reader from initPhase3 to SecurityManager, >> which ensures it's initialized before a security manager is >> installed. This preserves the startup optimization in >> case a SM is not installed: >> >> diff -r 87f2a6fb4b9a >> src/java.base/share/classes/java/lang/SecurityManager.java >> --- a/src/java.base/share/classes/java/lang/SecurityManager.java Wed >> Feb 15 15:57:18 2017 +0100 >> +++ b/src/java.base/share/classes/java/lang/SecurityManager.java Thu >> Feb 16 17:23:57 2017 +0100 >> @@ -233,6 +233,11 @@ >> public >> class SecurityManager { >> >> + static { >> + // ensure image reader for java.base is initialized before >> security >> + // manager is installed >> + Object.class.getResource("module-info.class"); >> + } >> /** >> * This field is true if there is a security check in >> * progress; false otherwise. >> >> >> Thanks! >> >> /Claes > From mark.reinhold at oracle.com Thu Feb 16 16:48:58 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 16 Feb 2017 08:48:58 -0800 Subject: How to name modules, automatic and otherwise Message-ID: <20170216084858.56860104@eggemoggin.niobe.net> Thanks to everyone for all the feedback on this topic. I've posted my conclusions here: http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-February/000582.html - Mark From brianf at infinity.nu Thu Feb 16 18:14:45 2017 From: brianf at infinity.nu (Brian Fox) Date: Thu, 16 Feb 2017 13:14:45 -0500 Subject: How to name modules, automatic and otherwise In-Reply-To: <20170216084858.56860104@eggemoggin.niobe.net> References: <20170216084858.56860104@eggemoggin.niobe.net> Message-ID: Thanks for the follow up Mark. I obviously don't completely agree with all of the assumptions and that's ok. I do however applaud the inclusion of the Module-Name into the algorithm. This gives enough of a hook that tools like Maven can hopefully send the ecosystem down a smooth transition path, avoiding or reducing many of the concerns we raised. --Brian On Thu, Feb 16, 2017 at 11:48 AM, wrote: > Thanks to everyone for all the feedback on this topic. I've posted my > conclusions here: > > http://mail.openjdk.java.net/pipermail/jpms-spec-experts/ > 2017-February/000582.html > > - Mark > From alan.bateman at oracle.com Thu Feb 16 18:59:13 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 16 Feb 2017 18:59:13 +0000 Subject: hg: jigsaw/jake/corba: 2 new changesets Message-ID: <201702161859.v1GIxD4K014190@aojmv0008.oracle.com> Changeset: de6bdf38935f Author: lana Date: 2017-02-16 17:12 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/de6bdf38935f Added tag jdk-9+157 for changeset 9383da04b385 ! .hgtags Changeset: a3f338a105fa Author: alanb Date: 2017-02-16 18:02 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/a3f338a105fa Merge ! .hgtags From alan.bateman at oracle.com Thu Feb 16 18:59:12 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 16 Feb 2017 18:59:12 +0000 Subject: hg: jigsaw/jake/jaxp: 2 new changesets Message-ID: <201702161859.v1GIxCVe014160@aojmv0008.oracle.com> Changeset: 80143dad68ba Author: lana Date: 2017-02-16 17:12 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/80143dad68ba Added tag jdk-9+157 for changeset 412df235a8a2 ! .hgtags Changeset: 78a99c5871b1 Author: alanb Date: 2017-02-16 18:02 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/78a99c5871b1 Merge ! .hgtags From alan.bateman at oracle.com Thu Feb 16 18:59:13 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 16 Feb 2017 18:59:13 +0000 Subject: hg: jigsaw/jake: 2 new changesets Message-ID: <201702161859.v1GIxDcO014186@aojmv0008.oracle.com> Changeset: 72761323ba0a Author: lana Date: 2017-02-16 17:12 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/72761323ba0a Added tag jdk-9+157 for changeset 4eb77fb98952 ! .hgtags Changeset: d3c64c12b7c0 Author: alanb Date: 2017-02-16 18:00 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/d3c64c12b7c0 Merge ! .hgtags From alan.bateman at oracle.com Thu Feb 16 18:59:14 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 16 Feb 2017 18:59:14 +0000 Subject: hg: jigsaw/jake/jaxws: 2 new changesets Message-ID: <201702161859.v1GIxEJC014194@aojmv0008.oracle.com> Changeset: 2dbdf7460052 Author: lana Date: 2017-02-16 17:12 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/2dbdf7460052 Added tag jdk-9+157 for changeset b7e70e1e0154 ! .hgtags Changeset: 2caee4d0ea4f Author: alanb Date: 2017-02-16 18:03 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/2caee4d0ea4f Merge ! .hgtags From alan.bateman at oracle.com Thu Feb 16 18:59:17 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 16 Feb 2017 18:59:17 +0000 Subject: hg: jigsaw/jake/hotspot: 2 new changesets Message-ID: <201702161859.v1GIxHLq014212@aojmv0008.oracle.com> Changeset: 4e78f3093522 Author: lana Date: 2017-02-16 17:12 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4e78f3093522 Added tag jdk-9+157 for changeset b2d0a906afd7 ! .hgtags Changeset: f06b24e86ca5 Author: alanb Date: 2017-02-16 18:10 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f06b24e86ca5 Merge ! .hgtags From alan.bateman at oracle.com Thu Feb 16 18:59:16 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 16 Feb 2017 18:59:16 +0000 Subject: hg: jigsaw/jake/langtools: 4 new changesets Message-ID: <201702161859.v1GIxGel014209@aojmv0008.oracle.com> Changeset: 8be741555fa6 Author: jlahoda Date: 2017-02-13 09:37 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/8be741555fa6 8173777: Merge javac -Xmodule into javac--patch-module Summary: Merging -Xmodule: functionality into --patch-module. Reviewed-by: jjg, mchung, rfield ! src/java.compiler/share/classes/javax/tools/StandardLocation.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/ClientCodeWrapper.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/ClassFinder.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/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/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.javadoc/share/classes/com/sun/tools/javadoc/main/ToolOption.java ! src/jdk.javadoc/share/classes/com/sun/tools/javadoc/resources/javadoc.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ToolOption.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/resources/javadoc.properties ! src/jdk.jshell/share/classes/jdk/jshell/MemoryFileManager.java ! test/tools/javac/6627362/T6627362.java - test/tools/javac/6627362/x/Object.java + test/tools/javac/6627362/x/java/lang/Object.java ! test/tools/javac/diags/Example.java ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/diags/examples/ModuleInfoWithPatchedModuleClassoutput/ModuleInfoWithPatchedModuleClassoutput.java + test/tools/javac/diags/examples/ModuleInfoWithPatchedModuleClassoutput/additional/module-info.java + test/tools/javac/diags/examples/ModuleInfoWithPatchedModuleClassoutput/patchmodule/java.compiler/javax/lang/model/element/Extra.java + test/tools/javac/diags/examples/ModuleInfoWithPatchedModuleSourcepath/ModuleInfoWithPatchedModule.java + test/tools/javac/diags/examples/ModuleInfoWithPatchedModuleSourcepath/patchmodule/java.compiler/javax/lang/model/element/Extra.java + test/tools/javac/diags/examples/ModuleInfoWithPatchedModuleSourcepath/patchmodule/java.compiler/module-info.java - test/tools/javac/diags/examples/ModuleInfoWithXModuleSourcePath/Extra.java - test/tools/javac/diags/examples/ModuleInfoWithXModuleSourcePath/module-info.java - test/tools/javac/diags/examples/ModuleInfoWithXmoduleClasspath/ModuleInfoWithXmoduleClasspath.java - test/tools/javac/diags/examples/ModuleInfoWithXmoduleClasspath/additional/module-info.java - test/tools/javac/diags/examples/NoSuperclass.java + test/tools/javac/diags/examples/NoSuperclass/NoSuperclass.java + test/tools/javac/diags/examples/NoSuperclass/patchmodule/java.base/java/lang/Object.java + test/tools/javac/diags/examples/TooManyPatchedModules/TooManyPatchedModules.java + test/tools/javac/diags/examples/TooManyPatchedModules/patchmodule/java.compiler/p/C.java + test/tools/javac/diags/examples/TooManyPatchedModules/patchmodule/jdk.compiler/p/C.java - test/tools/javac/diags/examples/XModuleWithModulePath/XModuleWithModulePath.java - test/tools/javac/meth/BadPolySig.java + test/tools/javac/meth/BadPolySig/BadPolySig.java + test/tools/javac/meth/BadPolySig/java.base/java/lang/invoke/MethodHandle.java ! test/tools/javac/modules/AddLimitMods.java ! test/tools/javac/modules/AddReadsTest.java + test/tools/javac/modules/CompileModulePatchTest.java ! test/tools/javac/modules/InheritRuntimeEnvironmentTest.java ! test/tools/javac/modules/PatchModulesTest.java - test/tools/javac/modules/XModuleTest.java ! test/tools/javac/synthesize/Main.java ! test/tools/jdeps/jdkinternals/RemovedJDKInternals.java Changeset: 162b521af7bb Author: jlahoda Date: 2017-02-13 11:57 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/162b521af7bb 8174245: Javadoc is not working for some methods Summary: Parsing source file as if they were part of their corresponding modules. Reviewed-by: rfield ! src/jdk.compiler/share/classes/jdk/internal/shellsupport/doc/JavadocHelper.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java ! test/jdk/jshell/JavadocTest.java Changeset: f9168e271f7d Author: lana Date: 2017-02-16 17:13 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/f9168e271f7d Added tag jdk-9+157 for changeset 162b521af7bb ! .hgtags Changeset: 33de8aa75ab9 Author: alanb Date: 2017-02-16 18:01 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/33de8aa75ab9 Merge ! .hgtags ! src/java.compiler/share/classes/javax/tools/StandardLocation.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/ClientCodeWrapper.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/ClassFinder.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/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/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.javadoc/share/classes/com/sun/tools/javadoc/main/ToolOption.java ! src/jdk.javadoc/share/classes/com/sun/tools/javadoc/resources/javadoc.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ToolOption.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/resources/javadoc.properties ! test/tools/javac/6627362/T6627362.java - test/tools/javac/6627362/x/Object.java ! test/tools/javac/diags/Example.java - test/tools/javac/diags/examples/ModuleInfoWithXModuleSourcePath/Extra.java - test/tools/javac/diags/examples/ModuleInfoWithXModuleSourcePath/module-info.java - test/tools/javac/diags/examples/ModuleInfoWithXmoduleClasspath/ModuleInfoWithXmoduleClasspath.java - test/tools/javac/diags/examples/ModuleInfoWithXmoduleClasspath/additional/module-info.java - test/tools/javac/diags/examples/NoSuperclass.java - test/tools/javac/diags/examples/XModuleWithModulePath/XModuleWithModulePath.java - test/tools/javac/meth/BadPolySig.java ! test/tools/javac/modules/AddLimitMods.java ! test/tools/javac/modules/AddReadsTest.java + test/tools/javac/modules/CompileModulePatchTest.java ! test/tools/javac/modules/PatchModulesTest.java - test/tools/javac/modules/XModuleTest.java ! test/tools/javac/synthesize/Main.java From alan.bateman at oracle.com Thu Feb 16 18:59:15 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 16 Feb 2017 18:59:15 +0000 Subject: hg: jigsaw/jake/nashorn: 2 new changesets Message-ID: <201702161859.v1GIxFDx014206@aojmv0008.oracle.com> Changeset: 13ae2480a4c3 Author: lana Date: 2017-02-16 17:13 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/13ae2480a4c3 Added tag jdk-9+157 for changeset f6070efba6af ! .hgtags Changeset: a71b174558de Author: alanb Date: 2017-02-16 18:02 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/a71b174558de Merge ! .hgtags From alan.bateman at oracle.com Thu Feb 16 18:59:17 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 16 Feb 2017 18:59:17 +0000 Subject: hg: jigsaw/jake/jdk: 4 new changesets Message-ID: <201702161859.v1GIxIaA014220@aojmv0008.oracle.com> Changeset: 96748d4b1204 Author: jlahoda Date: 2017-02-13 09:41 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/96748d4b1204 8173777: Merge javac -Xmodule into javac--patch-module Summary: Converting uses of -Xmodule: to --patch-module. Reviewed-by: alanb, mchung - test/javax/xml/jaxp/common/8035437/Document.java - test/javax/xml/jaxp/common/8035437/DocumentImpl.java - test/javax/xml/jaxp/common/8035437/Node.java + test/javax/xml/jaxp/common/8035437/patch-src1/org/w3c/dom/Document.java + test/javax/xml/jaxp/common/8035437/patch-src1/org/w3c/dom/Node.java + test/javax/xml/jaxp/common/8035437/patch-src2/com/sun/org/apache/xerces/internal/dom/DocumentImpl.java ! test/javax/xml/jaxp/common/8035437/run.sh - test/sun/text/IntHashtable/Bug4170614Test.java ! test/sun/text/IntHashtable/Bug4170614Test.sh + test/sun/text/IntHashtable/patch-src/java/text/Bug4170614Test.java ! test/tools/launcher/ToolsOpts.java ! test/tools/launcher/modules/patch/basic/PatchTest.java ! test/tools/launcher/modules/patch/basic/PatchTestWarningError.java ! test/tools/launcher/modules/patch/systemmodules/PatchSystemModules.java Changeset: fdfa7b2fe9a7 Author: mullan Date: 2017-02-13 11:35 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fdfa7b2fe9a7 8174837: Add "since=9" to deprecated ContentSigner and ContentSignerParameters classes Reviewed-by: vinnie ! src/jdk.jartool/share/classes/com/sun/jarsigner/ContentSigner.java ! src/jdk.jartool/share/classes/com/sun/jarsigner/ContentSignerParameters.java Changeset: bdf3d3a46863 Author: lana Date: 2017-02-16 17:13 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/bdf3d3a46863 Added tag jdk-9+157 for changeset fdfa7b2fe9a7 ! .hgtags Changeset: d67bb2021453 Author: alanb Date: 2017-02-16 18:01 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d67bb2021453 Merge ! .hgtags - test/javax/xml/jaxp/common/8035437/Document.java - test/javax/xml/jaxp/common/8035437/DocumentImpl.java - test/javax/xml/jaxp/common/8035437/Node.java ! test/javax/xml/jaxp/common/8035437/run.sh - test/sun/text/IntHashtable/Bug4170614Test.java ! test/tools/launcher/ToolsOpts.java ! test/tools/launcher/modules/patch/basic/PatchTest.java ! test/tools/launcher/modules/patch/systemmodules/PatchSystemModules.java From Martin.Balin at Oracle.COM Thu Feb 16 19:23:57 2017 From: Martin.Balin at Oracle.COM (Martin Balin) Date: Thu, 16 Feb 2017 20:23:57 +0100 Subject: How to name modules, automatic and otherwise In-Reply-To: <20170216084858.56860104@eggemoggin.niobe.net> References: <20170216084858.56860104@eggemoggin.niobe.net> Message-ID: <1982a4ff-2e86-ae39-abab-a3d907a776b4@Oracle.COM> Hello, This looks reasonable. Is it going to be implemented in JDK9 prior GA date? Martin On 16.2.2017 17:48, mark.reinhold at oracle.com wrote: > Thanks to everyone for all the feedback on this topic. I've posted my > conclusions here: > > http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-February/000582.html > > - Mark From mandy.chung at oracle.com Thu Feb 16 20:04:04 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 16 Feb 2017 12:04:04 -0800 Subject: RFR: 8175026: Capture build-time parameters to --generate-jli-classes In-Reply-To: References: <7c594b2c-a89c-8715-e65d-9442cf6005a7@oracle.com> Message-ID: <1093432B-E232-4311-A023-8DFA3F61038C@oracle.com> > On Feb 16, 2017, at 5:20 AM, Claes Redestad wrote: > >> >> In addition, if the main argument is specified but the version does not match, it will ignore the given argument. Should it be an error instead? We are the one who will generate a trace file and specify it in the jlink plugin option. It?s okay to ignore the default trace output if no plugin option is specified and I think no warning should be printed in this case. It?s just like this plugin is disabled. You may want to add a suboption to turn on verbose that will trace what is generated and what is ignored. > > I think a warning is reasonable in all cases: Using a different version of jlink than the java.base you're linking will lose some optimizations and the user would be none the wiser as to why, verbosity helps avoid surprises. The plugin is enabled by default. With this change, I consider this plugin is "auto-enabled" when it?s creating the image of the version that this plugin supports (i.e. matching major.minor version). So if the ?generate-jli-classes option is not specified, it might be confusing when I get this warning. I would prefer in this case no warning should be emitted and the plugin is not enabled. If the option is specified on the command-line, it should emit the warning. > > http://cr.openjdk.java.net/~redestad/8175026/jdk.02/ 322 if (!initialize(in)) { Maybe refactor line 175-190 in a new method and something like this: if (!checkVersion(getLinkedVersion(in))) : } Then follow with initialize(in) here. That?d make it explicit. One thing to handle is when exception is thrown when reading the trace file (default or mainArgument). Maybe that part can be done early in configure method and store the lines for later consumption. line 235-238: you may use orThrow in this case. Mandy From mandy.chung at oracle.com Thu Feb 16 21:24:28 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 16 Feb 2017 13:24:28 -0800 Subject: RFR: 8175026: Capture build-time parameters to --generate-jli-classes In-Reply-To: <1093432B-E232-4311-A023-8DFA3F61038C@oracle.com> References: <7c594b2c-a89c-8715-e65d-9442cf6005a7@oracle.com> <1093432B-E232-4311-A023-8DFA3F61038C@oracle.com> Message-ID: <5519300A-05A1-4A97-906D-53B109CC5167@oracle.com> One more thing: the warning message should be in plugin.properties to be localized. Mandy > On Feb 16, 2017, at 12:04 PM, Mandy Chung wrote: > > >> On Feb 16, 2017, at 5:20 AM, Claes Redestad wrote: >> >>> >>> In addition, if the main argument is specified but the version does not match, it will ignore the given argument. Should it be an error instead? We are the one who will generate a trace file and specify it in the jlink plugin option. It?s okay to ignore the default trace output if no plugin option is specified and I think no warning should be printed in this case. It?s just like this plugin is disabled. You may want to add a suboption to turn on verbose that will trace what is generated and what is ignored. >> >> I think a warning is reasonable in all cases: Using a different version of jlink than the java.base you're linking will lose some optimizations and the user would be none the wiser as to why, verbosity helps avoid surprises. > > The plugin is enabled by default. With this change, I consider > this plugin is "auto-enabled" when it?s creating the image of > the version that this plugin supports (i.e. matching major.minor > version). > > So if the ?generate-jli-classes option is not specified, it might > be confusing when I get this warning. I would prefer in this case > no warning should be emitted and the plugin is not enabled. > > If the option is specified on the command-line, it should emit > the warning. > >> >> http://cr.openjdk.java.net/~redestad/8175026/jdk.02/ > > 322 if (!initialize(in)) { > > Maybe refactor line 175-190 in a new method and something like this: > if (!checkVersion(getLinkedVersion(in))) > : > } > > Then follow with initialize(in) here. That?d make it explicit. > One thing to handle is when exception is thrown when reading > the trace file (default or mainArgument). Maybe that part can > be done early in configure method and store the lines for later > consumption. > > line 235-238: you may use orThrow in this case. > > Mandy From jzaugg at gmail.com Thu Feb 16 22:43:55 2017 From: jzaugg at gmail.com (Jason Zaugg) Date: Thu, 16 Feb 2017 22:43:55 +0000 Subject: Performance of JrtFileSystemProvider.exists In-Reply-To: References: Message-ID: Thanks, Alan. Good to hear that this is on the radar. In the meantime, I think I can solve our performance problem by using the /packages namespace to route lookups to the relevant module(s) to avoid so many negative lookups in the first place. Regards, Jason On Thu, 16 Feb 2017 at 18:44 Alan Bateman wrote: > On 16/02/2017 08:15, Jason Zaugg wrote: > > > Recently I modified the Scala compiler to read class files > > jrt:/ filesystem, rather than relying on rt.jar. > > > > I noticed a slowdown when running on JDK 9 ea and exercising this code. > > Profiles suggest that the bottleneck is in calls to Files.exists. > > JrtFileSystemProvider inherits an implementation which needs to > construct, > > throw and catch NoSuchFileException to answer in the negative. > > > > It is possible that I'm calling this more often than needed, and could > > implement a caching layer. But it seems worthwhile for jrtfs to > implement a > > fast path for exists, as is done in UnixFileSystemProvider. > > > > Possibly related bug "Startup regression with Jython": > > https://bugs.openjdk.java.net/browse/JDK-8166236 > > > As it happens, we a similar issue with the zip provider. It's something > that I was looking at with Sherman recently and we have a proposal to > push the exists down to the provider interface so that it can be > overridden. > > So a different issues to JDK-8166236 - that one is that Jython seems to > create a cache on first usage of all classes that it finds in rt.jar. I > assume that if/when Jython adds support for JDK 9 and jrtfs that they > will be able to integrate it with their caching. > > -Alan > From scolebourne at joda.org Thu Feb 16 23:19:43 2017 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 16 Feb 2017 23:19:43 +0000 Subject: How to name modules, automatic and otherwise In-Reply-To: <20170216164827.A309F65E1B@eggemoggin.niobe.net> References: <20170216164827.A309F65E1B@eggemoggin.niobe.net> Message-ID: On 16 February 2017 at 16:48, wrote: > This can be done very simply, with a single new JAR-file manifest `Module-Name` attribute I welcome this. > The reversed domain-name approach was sensible in the early days of Java, > before we had development tools sophisticated enough to help us deal with > the occasional conflict. We have such tools now, so going forward the > superior readability of short module and package names that start with > project or product names is preferable to the onerous verbosity of those > that start with reversed domain names. What tools? With short identifiers clashes are inevitable. Because the module name is baked inside the module in binary format, the only way to resolve the clash is to rewrite the module. The Java platform has not demanded anything like this before, and I can't see how it meets the reliable configuration requirement. Rewriting modules as part of the build system is a red line for me. I need to be able to see that the module on the module path is the same bits as that from the source of jars. The standard case to consider is as follows: - In 2017, a company creates an internal foundation library called "willow" and it becomes very popular within the company and is used 100s of times - In 2018, an unrelated open source project starts up with the name "willow" and becomes very popular. Both now publish modules with the name "willow" (one privately, one publicly). - In 2019, the company wants to use the open source "willow" library (directly or indirectly), but can't due to name clash - In 2020, the company wants to open source their "willow" library, but can't due to name clash The plan outlined, favouring short IDs, provides no solution to this problem that I can see. There simply isn't the breadth of identifier to avoid clashes like this (you can't possibly predict the future where you might need to coexist with an open source module that doesn't even exist yet). Proposal (A) only tackles automatic modules, and not the bigger problem where names are baked into the module itself. The simplest and most consistent option is reverse DNS everywhere. Everyone understand it and few will object! An alternative option would be that open source can use short names, but companies "must" use reverse DNS. But this is far from ideal given how projects move from private to public, or how companies merge. Another alternative is some form of group, that may or may not map onto maven's group, where most of the time it does not have to be specified: module mainlib from com.mycompany { requires base; // implicit, favours group 'com.mycompany' if there is a clash requires willow; // uses 'com.mycompany' because there is a clash requires willow from org.joda; // explicitly specified, but only needed to resolve a clash } With this approach, the clash can be resolved, but only needs to be by the first module in the graph to pull both in. Any transitive use of the two willow modules would be fine. In summary, I recognise the desire for short, pretty identifiers. However, I remain of the opinion that they are highly dangerous for the wider ecosystem without some additional ability to qualify them. The are many more private jars than public jars, and the clashes seen today on Maven Central are just the tip of the iceberg of this problem. Stephen From stephan.herrmann at berlin.de Fri Feb 17 00:15:20 2017 From: stephan.herrmann at berlin.de (Stephan Herrmann) Date: Fri, 17 Feb 2017 01:15:20 +0100 Subject: How to name modules, automatic and otherwise In-Reply-To: References: <20170216164827.A309F65E1B@eggemoggin.niobe.net> Message-ID: On 02/17/2017 12:19 AM, Stephen Colebourne wrote: > The simplest and most consistent option is reverse DNS everywhere. > Everyone understand it and few will object! > > An alternative option would be that open source can use short names, > but companies "must" use reverse DNS. But this is far from ideal given > how projects move from private to public, or how companies merge. > > Another alternative is some form of group, that may or may not map > onto maven's group, where most of the time it does not have to be > specified: > > module mainlib from com.mycompany { > requires base; // implicit, favours group 'com.mycompany' if there is a clash > requires willow; // uses 'com.mycompany' because there is a clash > requires willow from org.joda; // explicitly specified, but only > needed to resolve a clash > } From here, wouldn't it be trivial to change Mark's counter example: module com.bar:foo.data { exports com.bar.foo.data; requires org.hibernate:hibernate.core; requires org.hibernate:hibernate.jcache; requires org.hibernate:hibernate.validator; } into a positive example: import org.hibernate:*; module com.bar:foo.data { exports com.bar.foo.data; requires hibernate.core; requires hibernate.jcache; requires hibernate.validator; } best, Stephan From scolebourne at joda.org Fri Feb 17 08:37:50 2017 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 17 Feb 2017 08:37:50 +0000 Subject: How to name modules, automatic and otherwise In-Reply-To: References: <20170216164827.A309F65E1B@eggemoggin.niobe.net> Message-ID: On 17 February 2017 at 00:15, Stephan Herrmann wrote: >> module mainlib from com.mycompany { >> requires base; // implicit, favours group 'com.mycompany' if there is a >> clash >> requires willow; // uses 'com.mycompany' because there is a clash >> requires willow from org.joda; // explicitly specified, but only >> needed to resolve a clash >> } > > > From here, wouldn't it be trivial to change Mark's counter example: > > module com.bar:foo.data { > exports com.bar.foo.data; > requires org.hibernate:hibernate.core; > requires org.hibernate:hibernate.jcache; > requires org.hibernate:hibernate.validator; > } > > into a positive example: > > import org.hibernate:*; > module com.bar:foo.data { > exports com.bar.foo.data; > requires hibernate.core; > requires hibernate.jcache; > requires hibernate.validator; > } There is a subtle difference through. With the two layouts above, the groupId is always specified. With what I suggested, the groupId is late binding in the common case, giving a degree of flexibility to find the matching module. module com.bar:foo.data { exports com.bar.foo.data; requires hibernate.core; requires hibernate.jcache; requires hibernate.validator; } ie. this looks for hibernate.core on the module path and might find it from group org.hibernate or from another group. Finding it twice = error. This flexibility may be good or bad depending on how you view the world. BTW, one advantage of groups over reverse DNS is that it forces a consistent naming scheme on everyone, whereas the current proposal could well result in a mismash of styles. Stephen From gunnar at hibernate.org Fri Feb 17 08:45:17 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Fri, 17 Feb 2017 09:45:17 +0100 Subject: jlink - excluding optional dependencies Message-ID: Hi, How can I exclude optional dependencies when creating a runtime image using jlink? In more detail, I have a module A which declares an optional dependency to another module B via "requires static". I'd like to create a runtime image which only contains A. When running jlink with "--add-modules A", I'm getting "Error: B not found". jlink finishes when I run it with "--add-modules A,B" but then B is part of the image, too, as per the images release file. Thanks, --Gunnar From michael.rasmussen at zeroturnaround.com Fri Feb 17 09:07:43 2017 From: michael.rasmussen at zeroturnaround.com (Michael Rasmussen) Date: Fri, 17 Feb 2017 11:07:43 +0200 Subject: How to name modules, automatic and otherwise In-Reply-To: References: <20170216164827.A309F65E1B@eggemoggin.niobe.net> Message-ID: On 17 February 2017 at 01:19, Stephen Colebourne wrote: > > However, I remain of the opinion that they are highly dangerous for > the wider ecosystem without some additional ability to qualify them. > The are many more private jars than public jars, and the clashes seen > today on Maven Central are just the tip of the iceberg of this > problem. > I can only agree with this. s/willow/spark/ and we have an example of such a situation in maven already today, of two different libraries with the same name. With the options to specify group, no problem, then I could just write: requires spark-core from com.sparkjava or requires spark-core from org.apache.spark in order to clarify which was intended. /Michael From Alan.Bateman at oracle.com Fri Feb 17 09:46:26 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 17 Feb 2017 09:46:26 +0000 Subject: jlink - excluding optional dependencies In-Reply-To: References: Message-ID: <647ab898-ff83-f13f-08f1-1cb933c94b0e@oracle.com> On 17/02/2017 08:45, Gunnar Morling wrote: > Hi, > > How can I exclude optional dependencies when creating a runtime image > using jlink? > > In more detail, I have a module A which declares an optional > dependency to another module B via "requires static". I'd like to > create a runtime image which only contains A. > > When running jlink with "--add-modules A", I'm getting "Error: B not > found". jlink finishes when I run it with "--add-modules A,B" but then > B is part of the image, too, as per the images release file. > Thanks for bringing this up, it's something that was kicked around when `requires static` was added and I think dropped off the radar. To re-cap, one question at the time was how well jlink plugins will cope with "dangling references". It's not an issue for the plugins that are currently enabled by default. There is another question on whether the module in the generated image retains the `requires static` or not. -Alan From Alan.Bateman at oracle.com Fri Feb 17 09:49:13 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 17 Feb 2017 09:49:13 +0000 Subject: How to name modules, automatic and otherwise In-Reply-To: References: <20170216164827.A309F65E1B@eggemoggin.niobe.net> Message-ID: On 17/02/2017 09:07, Michael Rasmussen wrote: > : > I can only agree with this. s/willow/spark/ and we have an example of such > a situation in maven already today, of two different libraries with the > same name. > With the options to specify group, no problem, then I could just write: > requires spark-core from com.sparkjava or requires spark-core from > org.apache.spark in order to clarify which was intended. > Are these two libraries exporting the same API? -Alan From forax at univ-mlv.fr Fri Feb 17 09:58:20 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 17 Feb 2017 10:58:20 +0100 (CET) Subject: How to name modules, automatic and otherwise In-Reply-To: References: <20170216164827.A309F65E1B@eggemoggin.niobe.net> Message-ID: <336533903.1980976.1487325500994.JavaMail.zimbra@u-pem.fr> No, both are two unrelated projects, https://spark.apache.org/ http://sparkjava.com/ R?mi ----- Mail original ----- > De: "Alan Bateman" > ?: "Michael Rasmussen" > Cc: "jigsaw-dev" > Envoy?: Vendredi 17 F?vrier 2017 10:49:13 > Objet: Re: How to name modules, automatic and otherwise > On 17/02/2017 09:07, Michael Rasmussen wrote: > >> : >> I can only agree with this. s/willow/spark/ and we have an example of such >> a situation in maven already today, of two different libraries with the >> same name. >> With the options to specify group, no problem, then I could just write: >> requires spark-core from com.sparkjava or requires spark-core from >> org.apache.spark in order to clarify which was intended. >> > Are these two libraries exporting the same API? > > -Alan From Alan.Bateman at oracle.com Fri Feb 17 11:45:47 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 17 Feb 2017 11:45:47 +0000 Subject: How to name modules, automatic and otherwise In-Reply-To: <336533903.1980976.1487325500994.JavaMail.zimbra@u-pem.fr> References: <20170216164827.A309F65E1B@eggemoggin.niobe.net> <336533903.1980976.1487325500994.JavaMail.zimbra@u-pem.fr> Message-ID: <913bc922-203e-f7e5-7522-17d81ac6375c@oracle.com> On 17/02/2017 09:58, Remi Forax wrote: > No, > both are two unrelated projects, > https://spark.apache.org/ > http://sparkjava.com/ > > Right, I can write code that make use of types in org.apache.spark.** or spark.** without any issue as there are no overlapping packages. If both projects release modules, spark.core and sparkjava.core for example, then there I could develop a module that requires both. If both projects choose the same name, spark.core or org.spark.core, then I'm out of luck. -Alan From reto.merz at abacus.ch Fri Feb 17 12:01:45 2017 From: reto.merz at abacus.ch (Reto Merz) Date: Fri, 17 Feb 2017 13:01:45 +0100 Subject: AW: How to name modules, automatic and otherwise In-Reply-To: References: <20170216164827.A309F65E1B@eggemoggin.niobe.net> Message-ID: I like the approach with "from" syntax. It would also great to support from-grouping like this: module mainlib from com.mycompany { requires base; requires willow; from org.joda { requires willow; requires willow-one-more; } } The project I'm working on consists of 187 Maven modules and has 348 dependencies to external 3th party libs in total. Some core module will have large module-info files, grouping would help us to maintain and keep the overview without additional tools. Regards Reto On 02/17/2017 01:15 AM, Stephan Herrmann wrote: > On 02/17/2017 12:19 AM, Stephen Colebourne wrote: > > The simplest and most consistent option is reverse DNS everywhere. > > Everyone understand it and few will object! > > > > An alternative option would be that open source can use short names, > > but companies "must" use reverse DNS. But this is far from ideal given > > how projects move from private to public, or how companies merge. > > > > Another alternative is some form of group, that may or may not map > > onto maven's group, where most of the time it does not have to be > > specified: > > > > module mainlib from com.mycompany { > > requires base; // implicit, favours group 'com.mycompany' if there is a > clash > > requires willow; // uses 'com.mycompany' because there is a clash > > requires willow from org.joda; // explicitly specified, but only > > needed to resolve a clash > > } > > From here, wouldn't it be trivial to change Mark's counter example: > > module com.bar:foo.data { > exports com.bar.foo.data; > requires org.hibernate:hibernate.core; > requires org.hibernate:hibernate.jcache; > requires org.hibernate:hibernate.validator; > } > > into a positive example: > > import org.hibernate:*; > module com.bar:foo.data { > exports com.bar.foo.data; > requires hibernate.core; > requires hibernate.jcache; > requires hibernate.validator; > } > > best, > Stephan From brianf at infinity.nu Fri Feb 17 14:03:32 2017 From: brianf at infinity.nu (Brian Fox) Date: Fri, 17 Feb 2017 09:03:32 -0500 Subject: How to name modules, automatic and otherwise In-Reply-To: References: <20170216164827.A309F65E1B@eggemoggin.niobe.net> Message-ID: This seems sensible and not unfamiliar with how import statements already work in Java to determine the fqn to search for a given class. On Fri, Feb 17, 2017 at 4:07 AM, Michael Rasmussen < michael.rasmussen at zeroturnaround.com> wrote: > On 17 February 2017 at 01:19, Stephen Colebourne > wrote: > > > > However, I remain of the opinion that they are highly dangerous for > > the wider ecosystem without some additional ability to qualify them. > > The are many more private jars than public jars, and the clashes seen > > today on Maven Central are just the tip of the iceberg of this > > problem. > > > I can only agree with this. s/willow/spark/ and we have an example of such > a situation in maven already today, of two different libraries with the > same name. > With the options to specify group, no problem, then I could just write: > requires spark-core from com.sparkjava or requires spark-core from > org.apache.spark in order to clarify which was intended. > > /Michael > From claes.redestad at oracle.com Fri Feb 17 14:08:43 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 17 Feb 2017 15:08:43 +0100 Subject: RFR: 8175026: Capture build-time parameters to --generate-jli-classes In-Reply-To: <5519300A-05A1-4A97-906D-53B109CC5167@oracle.com> References: <7c594b2c-a89c-8715-e65d-9442cf6005a7@oracle.com> <1093432B-E232-4311-A023-8DFA3F61038C@oracle.com> <5519300A-05A1-4A97-906D-53B109CC5167@oracle.com> Message-ID: <892b0e6f-593d-37c4-f14a-dddaa17fd2b4@oracle.com> On 02/16/2017 10:24 PM, Mandy Chung wrote: > One more thing: the warning message should be in plugin.properties > to be localized. Done: http://cr.openjdk.java.net/~redestad/8175026/jdk.03/ /Claes > > Mandy > >> On Feb 16, 2017, at 12:04 PM, Mandy Chung wrote: >> >> >>> On Feb 16, 2017, at 5:20 AM, Claes Redestad wrote: >>> >>>> In addition, if the main argument is specified but the version does not match, it will ignore the given argument. Should it be an error instead? We are the one who will generate a trace file and specify it in the jlink plugin option. It?s okay to ignore the default trace output if no plugin option is specified and I think no warning should be printed in this case. It?s just like this plugin is disabled. You may want to add a suboption to turn on verbose that will trace what is generated and what is ignored. >>> I think a warning is reasonable in all cases: Using a different version of jlink than the java.base you're linking will lose some optimizations and the user would be none the wiser as to why, verbosity helps avoid surprises. >> The plugin is enabled by default. With this change, I consider >> this plugin is "auto-enabled" when it?s creating the image of >> the version that this plugin supports (i.e. matching major.minor >> version). >> >> So if the ?generate-jli-classes option is not specified, it might >> be confusing when I get this warning. I would prefer in this case >> no warning should be emitted and the plugin is not enabled. >> >> If the option is specified on the command-line, it should emit >> the warning. >> >>> http://cr.openjdk.java.net/~redestad/8175026/jdk.02/ >> 322 if (!initialize(in)) { >> >> Maybe refactor line 175-190 in a new method and something like this: >> if (!checkVersion(getLinkedVersion(in))) >> : >> } >> >> Then follow with initialize(in) here. That?d make it explicit. >> One thing to handle is when exception is thrown when reading >> the trace file (default or mainArgument). Maybe that part can >> be done early in configure method and store the lines for later >> consumption. >> >> line 235-238: you may use orThrow in this case. >> >> Mandy From mandy.chung at oracle.com Fri Feb 17 16:50:00 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 17 Feb 2017 08:50:00 -0800 Subject: RFR: 8175026: Capture build-time parameters to --generate-jli-classes In-Reply-To: <892b0e6f-593d-37c4-f14a-dddaa17fd2b4@oracle.com> References: <7c594b2c-a89c-8715-e65d-9442cf6005a7@oracle.com> <1093432B-E232-4311-A023-8DFA3F61038C@oracle.com> <5519300A-05A1-4A97-906D-53B109CC5167@oracle.com> <892b0e6f-593d-37c4-f14a-dddaa17fd2b4@oracle.com> Message-ID: > On Feb 17, 2017, at 6:08 AM, Claes Redestad wrote: > > > http://cr.openjdk.java.net/~redestad/8175026/jdk.03/ > Looks good. 82 pre-generate, otherwise the list used to build the host JDK image wil\n\ typo: s/wil/will Minor suggestion to the wording to "generate-jli-classes.description? message: Specify a file listing the java.lang.invoke classes to pre-generate as a hint to this plugin. By default the plugin will use a builtin list of pre-generated classes if the image being created matches the runtime version of this plugin; otherwise, this plugin will be No need to generate a webrev. thanks Mandy From gunnar at hibernate.org Fri Feb 17 19:40:09 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Fri, 17 Feb 2017 20:40:09 +0100 Subject: jlink - excluding optional dependencies In-Reply-To: <647ab898-ff83-f13f-08f1-1cb933c94b0e@oracle.com> References: <647ab898-ff83-f13f-08f1-1cb933c94b0e@oracle.com> Message-ID: > There is another question on whether the > module in the generated image retains the `requires static` or not. What would be the rational for removing it? On first thought I'd say keep the descriptor as it is. One could envision a tool for updating existing images, e.g. adding an optional dependency originally omitted when creating the image. 2017-02-17 10:46 GMT+01:00 Alan Bateman : > On 17/02/2017 08:45, Gunnar Morling wrote: > >> Hi, >> >> How can I exclude optional dependencies when creating a runtime image >> using jlink? >> >> In more detail, I have a module A which declares an optional >> dependency to another module B via "requires static". I'd like to >> create a runtime image which only contains A. >> >> When running jlink with "--add-modules A", I'm getting "Error: B not >> found". jlink finishes when I run it with "--add-modules A,B" but then >> B is part of the image, too, as per the images release file. >> > Thanks for bringing this up, it's something that was kicked around when > `requires static` was added and I think dropped off the radar. > > To re-cap, one question at the time was how well jlink plugins will cope > with "dangling references". It's not an issue for the plugins that are > currently enabled by default. There is another question on whether the > module in the generated image retains the `requires static` or not. > > -Alan From alan.bateman at oracle.com Sun Feb 19 19:47:31 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 19 Feb 2017 19:47:31 +0000 Subject: hg: jigsaw/jake: Drop OS version from ModuleTarget Message-ID: <201702191947.v1JJlV5E004185@aojmv0008.oracle.com> Changeset: 4784877b1442 Author: alanb Date: 2017-02-19 19:46 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/4784877b1442 Drop OS version from ModuleTarget ! make/CreateJmods.gmk From alan.bateman at oracle.com Sun Feb 19 19:47:48 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 19 Feb 2017 19:47:48 +0000 Subject: hg: jigsaw/jake/langtools: Drop OS version from ModuleTarget Message-ID: <201702191947.v1JJlmXt004433@aojmv0008.oracle.com> Changeset: cc6ddb75f5ad Author: alanb Date: 2017-02-19 19:46 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/cc6ddb75f5ad Drop OS version from ModuleTarget ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/ClassWriter.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/ModuleTarget_attribute.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java From alan.bateman at oracle.com Sun Feb 19 19:48:06 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 19 Feb 2017 19:48:06 +0000 Subject: hg: jigsaw/jake/jdk: Drop OS version from ModuleTarget Message-ID: <201702191948.v1JJm6HN004569@aojmv0008.oracle.com> Changeset: 0027ff89a29d Author: alanb Date: 2017-02-19 19:46 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0027ff89a29d Drop OS version from ModuleTarget Update ModuleReader implementations to allow resource names locate directories Add rawVersion/rawCompiledVersion Change initPhase2 to not print stack trace ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/lang/module/Configuration.java ! src/java.base/share/classes/java/lang/module/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/jmod/JmodFile.java ! src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java ! src/java.base/share/classes/jdk/internal/loader/Loader.java - src/java.base/share/classes/jdk/internal/loader/ResourceHelper.java ! src/java.base/share/classes/jdk/internal/misc/JavaLangModuleAccess.java ! src/java.base/share/classes/jdk/internal/module/Builder.java ! src/java.base/share/classes/jdk/internal/module/ClassFileAttributes.java ! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java ! src/java.base/share/classes/jdk/internal/module/ModuleInfo.java ! src/java.base/share/classes/jdk/internal/module/ModuleInfoExtender.java ! src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java ! src/java.base/share/classes/jdk/internal/module/ModulePatcher.java ! src/java.base/share/classes/jdk/internal/module/ModulePath.java ! src/java.base/share/classes/jdk/internal/module/ModuleReferenceImpl.java ! src/java.base/share/classes/jdk/internal/module/ModuleReferences.java + src/java.base/share/classes/jdk/internal/module/ModuleTarget.java ! src/java.base/share/classes/jdk/internal/module/Modules.java + src/java.base/share/classes/jdk/internal/module/Resources.java ! src/java.base/share/classes/jdk/internal/module/SystemModuleFinder.java ! src/java.base/share/classes/jdk/internal/module/SystemModules.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java ! src/java.base/share/classes/module-info.java ! src/jdk.jartool/share/classes/sun/tools/jar/Main.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/builder/DefaultImageBuilder.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ResourcePoolConfiguration.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ResourcePoolManager.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ExcludeVMPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ReleaseInfoPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java ! src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod.properties ! test/ProblemList.txt ! test/java/lang/module/AutomaticModulesTest.java ! test/java/lang/module/ConfigurationTest.java ! test/java/lang/module/ModuleDescriptorTest.java ! test/java/lang/module/ModuleReader/ModuleReaderTest.java ! test/tools/jlink/JLinkNegativeTest.java ! test/tools/launcher/modules/addexports/AddExportsTestWarningError.java ! test/tools/launcher/modules/addreads/AddReadsTestWarningError.java ! test/tools/launcher/modules/patch/basic/PatchTestWarningError.java ! test/tools/pack200/pack200-verifier/src/xmlkit/ClassReader.java From alan.bateman at oracle.com Sun Feb 19 19:48:20 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 19 Feb 2017 19:48:20 +0000 Subject: hg: jigsaw/jake/hotspot: Change initPhase2 to not print stack trace Message-ID: <201702191948.v1JJmKrr004702@aojmv0008.oracle.com> Changeset: 671540dfcfd2 Author: alanb Date: 2017-02-19 19:46 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/671540dfcfd2 Change initPhase2 to not print stack trace ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/java.hpp ! src/share/vm/runtime/thread.cpp From rfscholte at apache.org Mon Feb 20 18:07:03 2017 From: rfscholte at apache.org (Robert Scholte) Date: Mon, 20 Feb 2017 19:07:03 +0100 Subject: How to name modules, automatic and otherwise In-Reply-To: References: <20170216164827.A309F65E1B@eggemoggin.niobe.net> Message-ID: On Fri, 17 Feb 2017 00:19:43 +0100, Stephen Colebourne wrote: > On 16 February 2017 at 16:48, wrote: >> This can be done very simply, with a single new JAR-file manifest >> `Module-Name` attribute > > I welcome this. > >> The reversed domain-name approach was sensible in the early days of >> Java, >> before we had development tools sophisticated enough to help us deal >> with >> the occasional conflict. We have such tools now, so going forward the >> superior readability of short module and package names that start with >> project or product names is preferable to the onerous verbosity of those >> that start with reversed domain names. > > What tools? > > With short identifiers clashes are inevitable. Because the module name > is baked inside the module in binary format, the only way to resolve > the clash is to rewrite the module. The Java platform has not demanded > anything like this before, and I can't see how it meets the reliable > configuration requirement. Rewriting modules as part of the build > system is a red line for me. I need to be able to see that the module > on the module path is the same bits as that from the source of jars. > > The standard case to consider is as follows: > > - In 2017, a company creates an internal foundation library called > "willow" and it becomes very popular within the company and is used > 100s of times > - In 2018, an unrelated open source project starts up with the name > "willow" and becomes very popular. Both now publish modules with the > name "willow" (one privately, one publicly). > - In 2019, the company wants to use the open source "willow" library > (directly or indirectly), but can't due to name clash > - In 2020, the company wants to open source their "willow" library, > but can't due to name clash > > The plan outlined, favouring short IDs, provides no solution to this > problem that I can see. There simply isn't the breadth of identifier > to avoid clashes like this (you can't possibly predict the future > where you might need to coexist with an open source module that > doesn't even exist yet). Proposal (A) only tackles automatic modules, > and not the bigger problem where names are baked into the module > itself. > > The simplest and most consistent option is reverse DNS everywhere. > Everyone understand it and few will object! > > An alternative option would be that open source can use short names, > but companies "must" use reverse DNS. But this is far from ideal given > how projects move from private to public, or how companies merge. > > Another alternative is some form of group, that may or may not map > onto maven's group, where most of the time it does not have to be > specified: > > module mainlib from com.mycompany { > requires base; // implicit, favours group 'com.mycompany' if there is > a clash > requires willow; // uses 'com.mycompany' because there is a clash > requires willow from org.joda; // explicitly specified, but only > needed to resolve a clash > } what I like about this idea is that people are forced to define the 'from', making it less likely to have collisions, even when the result is something like com.mycompany.mainlib. What is required is that the first two requirements (base and willow) must be transformed to their FQN by the compiler. Assume 'requires base' is actually 'requires base from com.thatcompany' and mainlib is used together with bootlib, which also has 'requires base' (but in fact from com.bootcompany). At this time base will become ambiguous, unless the correct "from" was appended during compilation. This proposal would likely prevent quite some collisions. thanks, Robert > > With this approach, the clash can be resolved, but only needs to be by > the first module in the graph to pull both in. Any transitive use of > the two willow modules would be fine. > > In summary, I recognise the desire for short, pretty identifiers. > However, I remain of the opinion that they are highly dangerous for > the wider ecosystem without some additional ability to qualify them. > The are many more private jars than public jars, and the clashes seen > today on Maven Central are just the tip of the iceberg of this > problem. > > Stephen From christoph.langer at sap.com Mon Feb 20 19:15:51 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 20 Feb 2017 19:15:51 +0000 Subject: Another module system question Message-ID: <9c102e80668549cba532eb9a0a79e6ee@derote13de46.global.corp.sap> Hi, here is another question which generates out of my attempts to refactor our code into modules. My design idea currently is to have a module for the API and another module which implements it. The API has a package where service interfaces are defined and the implementation will implement these service interfaces. Let's say it looks like this: a) module my.api exports the.api.package.services b) module my.impl requires my.api provides the.api.package.services.Service1 with the.impl.package.providers.Service1Impl This seems obvious to me as the impl needs to know the service interfaces. Anyway, maybe you could comment on this idea if this sounds like a reasonable pattern. However, the main issue I have with this approach is: When is the time that my service from the second module 'b' will be available and registered? I assume, module 'a' will load first, then 'b'. So, when I use some static class initialization as the place in 'a' where I try to load the service from 'b', I guess the service couldn't be available yet. Is there some module system initialization hook, where I could plug in and then assume the service from 'b' is ready? Or should I maybe add a static class initializer in 'a' which would try to resolve the implementing service from 'b' in a loop until it is ready? Looking forward to some suggestions here. Thanks and best regards Christoph From Alan.Bateman at oracle.com Mon Feb 20 19:48:47 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 20 Feb 2017 19:48:47 +0000 Subject: Another module system question In-Reply-To: <9c102e80668549cba532eb9a0a79e6ee@derote13de46.global.corp.sap> References: <9c102e80668549cba532eb9a0a79e6ee@derote13de46.global.corp.sap> Message-ID: <5089fa1f-6d20-6d33-ab7b-7ad887099366@oracle.com> On 20/02/2017 19:15, Langer, Christoph wrote: > : > > However, the main issue I have with this approach is: When is the time that my service from the second module 'b' will be available and registered? I assume, module 'a' will load first, then 'b'. So, when I use some static class initialization as the place in 'a' where I try to load the service from 'b', I guess the service couldn't be available yet. Is there some module system initialization hook, where I could plug in and then assume the service from 'b' is ready? Or should I maybe add a static class initializer in 'a' which would try to resolve the implementing service from 'b' in a loop until it is ready? > Declaring the `uses` and `provides` and deploy the modules on the module path should be enough. When the consumer module (the module with `uses`) is resolved then it will trigger any providers to be resolved. The resolved modules are loaded eagerly (meaning they are defined to the VM) but there is nothing actually loaded. When you invoke ServiceLoader to get a stream or to iterate over the providers then it will load the provider from `b`. It's probably best to just try it out as it's easy to get something working. Often the hard bit is deciding on the service interface and choosing the methods to expose to allow a consumer select. -Alan From christoph.langer at sap.com Tue Feb 21 07:22:09 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 21 Feb 2017 07:22:09 +0000 Subject: Another module system question In-Reply-To: <5089fa1f-6d20-6d33-ab7b-7ad887099366@oracle.com> References: <9c102e80668549cba532eb9a0a79e6ee@derote13de46.global.corp.sap> <5089fa1f-6d20-6d33-ab7b-7ad887099366@oracle.com> Message-ID: <4ef9bb09886a45e2947f770e6c7d7edc@derote13de46.global.corp.sap> Thanks, Alan. That sounds promising. I'll try it. > -----Original Message----- > From: Alan Bateman [mailto:Alan.Bateman at oracle.com] > Sent: Montag, 20. Februar 2017 20:49 > To: Langer, Christoph ; jigsaw- > dev at openjdk.java.net > Subject: Re: Another module system question > > On 20/02/2017 19:15, Langer, Christoph wrote: > > > : > > > > However, the main issue I have with this approach is: When is the time that > my service from the second module 'b' will be available and registered? I > assume, module 'a' will load first, then 'b'. So, when I use some static class > initialization as the place in 'a' where I try to load the service from 'b', I guess > the service couldn't be available yet. Is there some module system > initialization hook, where I could plug in and then assume the service from 'b' > is ready? Or should I maybe add a static class initializer in 'a' which would try > to resolve the implementing service from 'b' in a loop until it is ready? > > > Declaring the `uses` and `provides` and deploy the modules on the module > path should be enough. When the consumer module (the module with > `uses`) > is resolved then it will trigger any providers to be resolved. The > resolved modules are loaded eagerly (meaning they are defined to the VM) > but there is nothing actually loaded. When you invoke ServiceLoader to > get a stream or to iterate over the providers then it will load the > provider from `b`. It's probably best to just try it out as it's easy to > get something working. Often the hard bit is deciding on the service > interface and choosing the methods to expose to allow a consumer select. > > -Alan From vitalyd at gmail.com Wed Feb 22 13:46:19 2017 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 22 Feb 2017 08:46:19 -0500 Subject: sun.nio.ch.DirectBuffer and jdk9/jigsaw Message-ID: Hi all, What's the status of this interface with respect to Java 9 (and beyond)? It wasn't added to the critical API list of JEP 260, and thus requires an addExports flag to grant access. I have a use case where just the address() method is used in performance sensitive code. Previously, the code had used a JNI call to get the address of a DirectByteBuffer, but address() has superior performance particularly because the JIT devirtualizes all callsites I have (they only see DBB as receivers of this call). So, has the fate of this interface been decided? Am I stuck with addExports for Java 9? Is there a medium/long term replacement? Just to reiterate, I'd like access to the address() with as little fuss as possible, and don't care about the attachment() and cleaner() methods on it. Also, let me know if this best addressed to the nio-dev mailing list - it *is* an NIO class, but my question is really geared towards working with this interface in the modular/jigsaw world. Thanks From Alan.Bateman at oracle.com Wed Feb 22 13:57:19 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 22 Feb 2017 13:57:19 +0000 Subject: sun.nio.ch.DirectBuffer and jdk9/jigsaw In-Reply-To: References: Message-ID: <909585ba-241c-eeef-7cc8-14312dd69a37@oracle.com> On 22/02/2017 13:46, Vitaly Davidovich wrote: > Hi all, > > What's the status of this interface with respect to Java 9 (and beyond)? It > wasn't added to the critical API list of JEP 260, and thus requires an > addExports flag to grant access. I have a use case where just the > address() method is used in performance sensitive code. Previously, the > code had used a JNI call to get the address of a DirectByteBuffer, but > address() has superior performance particularly because the JIT > devirtualizes all callsites I have (they only see DBB as receivers of this > call). > > So, has the fate of this interface been decided? Am I stuck with addExports > for Java 9? Is there a medium/long term replacement? Just to reiterate, I'd > like access to the address() with as little fuss as possible, and don't > care about the attachment() and cleaner() methods on it. > > Also, let me know if this best addressed to the nio-dev mailing list - it > *is* an NIO class, but my question is really geared towards working with > this interface in the modular/jigsaw world. > This interface has always been JDK-internal and has never been documented/supported. If you have something accessing the memory directly then maybe it would be better if you looked after the allocation/deallocation yourself and use NewDirectByteBuffer to wrap the regions that you need for I/O operations. -Alan From vitalyd at gmail.com Wed Feb 22 14:06:01 2017 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 22 Feb 2017 14:06:01 +0000 Subject: sun.nio.ch.DirectBuffer and jdk9/jigsaw In-Reply-To: <909585ba-241c-eeef-7cc8-14312dd69a37@oracle.com> References: <909585ba-241c-eeef-7cc8-14312dd69a37@oracle.com> Message-ID: On Wed, Feb 22, 2017 at 8:57 AM Alan Bateman wrote: > On 22/02/2017 13:46, Vitaly Davidovich wrote: > > > Hi all, > > > > What's the status of this interface with respect to Java 9 (and beyond)? > It > > wasn't added to the critical API list of JEP 260, and thus requires an > > addExports flag to grant access. I have a use case where just the > > address() method is used in performance sensitive code. Previously, the > > code had used a JNI call to get the address of a DirectByteBuffer, but > > address() has superior performance particularly because the JIT > > devirtualizes all callsites I have (they only see DBB as receivers of > this > > call). > > > > So, has the fate of this interface been decided? Am I stuck with > addExports > > for Java 9? Is there a medium/long term replacement? Just to reiterate, > I'd > > like access to the address() with as little fuss as possible, and don't > > care about the attachment() and cleaner() methods on it. > > > > Also, let me know if this best addressed to the nio-dev mailing list - it > > *is* an NIO class, but my question is really geared towards working with > > this interface in the modular/jigsaw world. > > > This interface has always been JDK-internal and has never been > documented/supported. If you have something accessing the memory > directly then maybe it would be better if you looked after the > allocation/deallocation yourself and use NewDirectByteBuffer to wrap the > regions that you need for I/O operations. Hi Alan, Yes, I know it's never been supported. That's been fine and it has worked well ... until jigsaw came into the picture. So my real question is really whether there can be a proper/supported API, with good performance characteristics, that would give access to the base address of a direct bytebuffer. In other words, can we make the notion of a direct bytebuffer first class? That notion would carry the base address with it (amongst whatever else is deemed worthwhile). NewDirectByteBuffer is used on the JNI side already, but I need something at the Java level to get the base address so that field offsets can be calculated for reading data using Unsafe (yes, another performance hack because officially supported Java variants currently don't JIT well enough). The use case is a "view" of native memory, attached to a DBB, used for IPC. > > > -Alan > -- Sent from my phone From gunnar at hibernate.org Wed Feb 22 22:44:59 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Wed, 22 Feb 2017 23:44:59 +0100 Subject: Why can't main class be given in module-info.java? Message-ID: Hi, Why is it that the binary form of module declarations can carry information on a main class ("ModuleMainClass" attribute), but no main class can be specified in module-info.java? It seems setting ModuleMainClass is left to the jar tool, but I'd like to understand the rationale behind it. Thanks, --Gunnar From paul.sandoz at oracle.com Thu Feb 23 01:22:27 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 22 Feb 2017 17:22:27 -0800 Subject: Remove sun.misc.Unsafe.defineAnonymousClass Message-ID: Hi, I think we should remove the method sun.misc.Unsafe.defineAnonymousClass. This is one leaked through in the move to the unsupported module. I believe under the remit of unsupported module we can still do this. There are no usages on grepcode.com , and we really don?t want anyone to start depending on this, especially for constant pool patching, where such a public API might require some careful thought, compared to the anon class support itself which is somewhat simpler. If developers really want constant pool patching they can crack open the jdk.internal.misc package and then they really know this is not supported. For the anon class support we are considering retconning to nest mates and with a public method on MethodHandles.lookup. Paul. From chris at hazelcast.com Thu Feb 23 02:55:37 2017 From: chris at hazelcast.com (Christoph Engelbert) Date: Wed, 22 Feb 2017 21:55:37 -0500 Subject: Remove sun.misc.Unsafe.defineAnonymousClass In-Reply-To: References: Message-ID: Hey guys, Not exactly sure but I think JRuby 3000? uses it under the covers, but I might be mistaken. I guess Charles can shed some more light. Christoph Engelbert Manager Developer Relations 350 Cambridge Ave Suite #50, Palo Alto, CA 94306 USA (based in Germany) chris at hazelcast.com +49 160 9648 2677 @noctarius2k skype: noctarius_ > On 22 Feb 2017, at 20:22, Paul Sandoz wrote: > > Hi, > > I think we should remove the method sun.misc.Unsafe.defineAnonymousClass. > > This is one leaked through in the move to the unsupported module. I believe under the remit of unsupported module we can still do this. > > There are no usages on grepcode.com , and we really don?t want anyone to start depending on this, especially for constant pool patching, where such a public API might require some careful thought, compared to the anon class support itself which is somewhat simpler. > > If developers really want constant pool patching they can crack open the jdk.internal.misc package and then they really know this is not supported. > > For the anon class support we are considering retconning to nest mates and with a public method on MethodHandles.lookup. > > Paul. > > > From forax at univ-mlv.fr Thu Feb 23 09:19:44 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 23 Feb 2017 10:19:44 +0100 (CET) Subject: Remove sun.misc.Unsafe.defineAnonymousClass In-Reply-To: References: Message-ID: <1416669232.1511653.1487841584916.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Paul Sandoz" > ?: "jigsaw-dev" > Cc: "Brian Goetz" > Envoy?: Jeudi 23 F?vrier 2017 02:22:27 > Objet: Remove sun.misc.Unsafe.defineAnonymousClass > Hi, Hi Paul, my first reaction was 'over my dead body', (you have sent this email to jigsaw-dev that i hope, it's just a mistake) > > I think we should remove the method sun.misc.Unsafe.defineAnonymousClass. so yes for 10 when public replacement APIs will be introduced, but no for 9. > > This is one leaked through in the move to the unsupported module. I believe > under the remit of unsupported module we can still do this. It does not leaked, we discuss about removing it for 9 during the last JVM Summit, and the consensus (i believe) was to add several public methods to cover all the 'features' of defineAnonymousClass in 10 before removing it. > > There are no usages on grepcode.com , and we really don?t > want anyone to start depending on this, especially for constant pool patching, > where such a public API might require some careful thought, compared to the > anon class support itself which is somewhat simpler. disentangling the different 'features' of defineAnonymousClass also requires some thought, defineNestmate [1] is one step in the right direction (even if it still mix the fact that the class is not loaded by a classloader and the NestMate access), but by example for my proxy library [2], i still also need to be able to do the constant pool patching because i want to inject method handles that are not direct (i.e. live objects from the VM POV). > > If developers really want constant pool patching they can crack open the > jdk.internal.misc package and then they really know this is not supported. I see this has being more evil that using sun.misc.Unsafe. Nobody should use a non exported package like jdk.internal.misc. It's fine if you are in the middle of the migration process to 9 but jdk.internal.misc is a package introduced in 9, so nobody outside of the modules listed in the module-info should ever using it. > > For the anon class support we are considering retconning to nest mates and with > a public method on MethodHandles.lookup. > > Paul. R?mi [1] https://bugs.openjdk.java.net/browse/JDK-8171335 [2] https://github.com/forax/proxy2 From Alan.Bateman at oracle.com Thu Feb 23 10:02:19 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 23 Feb 2017 10:02:19 +0000 Subject: sun.nio.ch.DirectBuffer and jdk9/jigsaw In-Reply-To: References: <909585ba-241c-eeef-7cc8-14312dd69a37@oracle.com> Message-ID: On 22/02/2017 14:06, Vitaly Davidovich wrote: > : > > Yes, I know it's never been supported. That's been fine and it has > worked well ... until jigsaw came into the picture. So my real > question is really whether there can be a proper/supported API, with > good performance characteristics, that would give access to the base > address of a direct bytebuffer. In other words, can we make the > notion of a direct bytebuffer first class? That notion would carry the > base address with it (amongst whatever else is deemed worthwhile). > > NewDirectByteBuffer is used on the JNI side already, but I need > something at the Java level to get the base address so that field > offsets can be calculated for reading data using Unsafe (yes, another > performance hack because officially supported Java variants currently > don't JIT well enough). The use case is a "view" of native memory, > attached to a DBB, used for IPC. > If you are using NewDirectByteBuffer already then couldn't you use a map of ByteBuffer -> address? -Alan From forax at univ-mlv.fr Thu Feb 23 11:09:33 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 23 Feb 2017 12:09:33 +0100 (CET) Subject: Why can't main class be given in module-info.java? In-Reply-To: References: Message-ID: <39259192.1588956.1487848173176.JavaMail.zimbra@u-pem.fr> Hi Gunnar, all module metadata, the main-class but also the version, the os etc, are injected by the jar command. In 8, the MainClass (or all of metadata that are in the manifest) only exist from the runtime point of view after being put inside of a jar, so in order to be the less disruptive possible for the existing build processes, we have chosen to keep the same strategy. This also allow us to support application that are built by compiling the code once and split the generated classes in several jars afterwards. cheers, R?mi ----- Mail original ----- > De: "Gunnar Morling" > ?: "jigsaw-dev" > Envoy?: Mercredi 22 F?vrier 2017 23:44:59 > Objet: Why can't main class be given in module-info.java? > Hi, > > Why is it that the binary form of module declarations can carry > information on a main class ("ModuleMainClass" attribute), but no main > class can be specified in module-info.java? > > It seems setting ModuleMainClass is left to the jar tool, but I'd like > to understand the rationale behind it. > > Thanks, > > --Gunnar From vitalyd at gmail.com Thu Feb 23 11:30:11 2017 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 23 Feb 2017 11:30:11 +0000 Subject: sun.nio.ch.DirectBuffer and jdk9/jigsaw In-Reply-To: References: <909585ba-241c-eeef-7cc8-14312dd69a37@oracle.com> Message-ID: On Thu, Feb 23, 2017 at 5:02 AM Alan Bateman wrote: > On 22/02/2017 14:06, Vitaly Davidovich wrote: > > : > > > > Yes, I know it's never been supported. That's been fine and it has worked > well ... until jigsaw came into the picture. So my real question is really > whether there can be a proper/supported API, with good performance > characteristics, that would give access to the base address of a direct > bytebuffer. In other words, can we make the notion of a direct bytebuffer > first class? That notion would carry the base address with it (amongst > whatever else is deemed worthwhile). > > NewDirectByteBuffer is used on the JNI side already, but I need something > at the Java level to get the base address so that field offsets can be > calculated for reading data using Unsafe (yes, another performance hack > because officially supported Java variants currently don't JIT well > enough). The use case is a "view" of native memory, attached to a DBB, > used for IPC. > > If you are using NewDirectByteBuffer already then couldn't you use a map > of ByteBuffer -> address? > The buffers are reused by having them point to different native memory block addresses; those blocks are managed by native code. As mentioned, the ByteBuffer (DirectByteBuffer concretely) is used as the Java level interface/view of native memory, allowing Java and native code to communicate. I don't see the point in trying to hide the elephant in the room: the whole notion/concept of direct byte buffer. It's fine if the concrete DirectByteBuffer impl is package private, but it would make sense, IMO, to have an interface to describe such a thing abstractly; DirectBuffer seemed like a stab at it, granted unsupported. > > > -Alan > -- Sent from my phone From alan.bateman at oracle.com Thu Feb 23 12:15:58 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 23 Feb 2017 12:15:58 +0000 Subject: hg: jigsaw/jake/jdk: 2 new changesets Message-ID: <201702231215.v1NCFwsJ026928@aojmv0008.oracle.com> Changeset: 6e249d6bf786 Author: alanb Date: 2017-02-23 12:04 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6e249d6bf786 Fixed typo in javadoc ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java Changeset: 15de23fa983a Author: alanb Date: 2017-02-23 12:15 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/15de23fa983a Use -Xlog:init=debug to trigger more output from initPhase2 ! src/java.base/share/classes/java/lang/System.java From alan.bateman at oracle.com Thu Feb 23 12:16:10 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 23 Feb 2017 12:16:10 +0000 Subject: hg: jigsaw/jake/hotspot: Use -Xlog:init=debug to trigger more output from initPhase2 Message-ID: <201702231216.v1NCGAkb027240@aojmv0008.oracle.com> Changeset: 0c8f5b7832d7 Author: alanb Date: 2017-02-23 12:15 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0c8f5b7832d7 Use -Xlog:init=debug to trigger more output from initPhase2 ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/thread.cpp From chris.hegarty at oracle.com Thu Feb 23 16:10:17 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 23 Feb 2017 16:10:17 +0000 Subject: sun.nio.ch.DirectBuffer and jdk9/jigsaw In-Reply-To: References: <909585ba-241c-eeef-7cc8-14312dd69a37@oracle.com> Message-ID: <1A7655EE-37AF-4C91-B16B-7E81F819E3D0@oracle.com> > On 23 Feb 2017, at 11:30, Vitaly Davidovich wrote: >> ... > The buffers are reused by having them point to different native memory > block addresses; those blocks are managed by native code. As mentioned, > the ByteBuffer (DirectByteBuffer concretely) is used as the Java level > interface/view of native memory, allowing Java and native code to > communicate. So a DBB, under your code, may report a different address at some time in the future, to that of what it currently reports? I was not aware of this usecase. Is any similar code available on the web, or elsewhere, so we could try to determine why this is being done? -Chris. From vitalyd at gmail.com Thu Feb 23 16:29:57 2017 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 23 Feb 2017 11:29:57 -0500 Subject: sun.nio.ch.DirectBuffer and jdk9/jigsaw In-Reply-To: <1A7655EE-37AF-4C91-B16B-7E81F819E3D0@oracle.com> References: <909585ba-241c-eeef-7cc8-14312dd69a37@oracle.com> <1A7655EE-37AF-4C91-B16B-7E81F819E3D0@oracle.com> Message-ID: On Thu, Feb 23, 2017 at 11:10 AM, Chris Hegarty wrote: > > > On 23 Feb 2017, at 11:30, Vitaly Davidovich wrote: > >> ... > > The buffers are reused by having them point to different native memory > > block addresses; those blocks are managed by native code. As mentioned, > > the ByteBuffer (DirectByteBuffer concretely) is used as the Java level > > interface/view of native memory, allowing Java and native code to > > communicate. > > So a DBB, under your code, may report a different address at some time > in the future, to that of what it currently reports? Correct. > I was not aware of this > usecase. Is any similar code available on the web, or elsewhere, so we > could try to determine why this is being done? > Unfortunately it's not open source code, and I don't immediately know of anything similar on the web (or otherwise). However, the gist is the following: 1) Allocate a 0-size DBB (i.e. ByteBuffer.allocateDirect(0)). This gives you a Java "handle", if you will, to some native memory. But, since this DBB will be attached/reattached to different memory dynamically, there's no need for an actual allocation. 2) Native code wants to expose a segment of memory to Java. In JNI, it sets the address and capacity of this DBB to the pointer where the native memory segment starts, and to the capacity (it knows how big the native segment is). Java code asks for this DBB to be "attached" to, say, some sort of message, and the JNI/native code perform these functions. 3) Java gets the attached DBB back, and can then use its API (getXXX/setXXX) to read/write that native block. Once the operation completes, the DBB is recycled for reuse (i.e. can be attached to a different native segment again). Obviously, we can use http://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#GetDirectBufferAddress to get the address and then expose that via a JNI helper - in fact, that's what was done before. But, there's a JNI call penalty here for what is otherwise a memory read. DirectBuffer::address() solves that nicely, and also plays well with the C2 JIT (as mentioned) because the callsites where this is used only see DBB, and then the whole invokeinterface call is devirtualized and inlined into a quick type check and Java field read - the performance of this is, as you can imagine, significantly better than the JNI approach. If you think of what a DBB really is, it's pretty much what it's name suggests - it's an API to read/write to native memory, rather than Java heap memory (i.e. HeapByteBuffer). But, there's no reason the native memory backing the DBB has to also be allocated via Unsafe itself, although that's the more common scenario. On the Java side, consumers of this have a common and conventional API over a byte buffer, i.e. ByteBuffer, which can optionally be used in the manner above (obviously callers will need to know what mode they're using). > -Chris. > > From uschindler at apache.org Thu Feb 23 16:54:07 2017 From: uschindler at apache.org (Uwe Schindler) Date: Thu, 23 Feb 2017 17:54:07 +0100 Subject: sun.nio.ch.DirectBuffer and jdk9/jigsaw In-Reply-To: References: <909585ba-241c-eeef-7cc8-14312dd69a37@oracle.com> <1A7655EE-37AF-4C91-B16B-7E81F819E3D0@oracle.com> Message-ID: <045301d28df5$7452c0d0$5cf84270$@apache.org> Hi, Why do you need the address at all in the Java code? Java code can use the official ByteBuffer methods to access the memory you are wrapping. In Java 9 that?s optimized very good by Hotspot and should be almost as fast as array accesses (we proved that in Apache Lucene - congrats to the Hotspot committers). If you need special access modes like volatile access, then you can use Java 9's VarHandles. You can get a VarHandle to the backing direct buffer using the MethodHandles API. Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: jigsaw-dev [mailto:jigsaw-dev-bounces at openjdk.java.net] On Behalf > Of Vitaly Davidovich > Sent: Thursday, February 23, 2017 5:30 PM > To: Chris Hegarty > Cc: jigsaw-dev > Subject: Re: sun.nio.ch.DirectBuffer and jdk9/jigsaw > > On Thu, Feb 23, 2017 at 11:10 AM, Chris Hegarty > > wrote: > > > > > > On 23 Feb 2017, at 11:30, Vitaly Davidovich wrote: > > >> ... > > > The buffers are reused by having them point to different native memory > > > block addresses; those blocks are managed by native code. As > mentioned, > > > the ByteBuffer (DirectByteBuffer concretely) is used as the Java level > > > interface/view of native memory, allowing Java and native code to > > > communicate. > > > > So a DBB, under your code, may report a different address at some time > > in the future, to that of what it currently reports? > > Correct. > > > I was not aware of this > > usecase. Is any similar code available on the web, or elsewhere, so we > > could try to determine why this is being done? > > > Unfortunately it's not open source code, and I don't immediately know of > anything similar on the web (or otherwise). However, the gist is the > following: > 1) Allocate a 0-size DBB (i.e. ByteBuffer.allocateDirect(0)). This gives > you a Java "handle", if you will, to some native memory. But, since this > DBB will be attached/reattached to different memory dynamically, there's no > need for an actual allocation. > 2) Native code wants to expose a segment of memory to Java. In JNI, it > sets the address and capacity of this DBB to the pointer where the native > memory segment starts, and to the capacity (it knows how big the native > segment is). Java code asks for this DBB to be "attached" to, say, some > sort of message, and the JNI/native code perform these functions. > 3) Java gets the attached DBB back, and can then use its API > (getXXX/setXXX) to read/write that native block. Once the operation > completes, the DBB is recycled for reuse (i.e. can be attached to a > different native segment again). > > Obviously, we can use > http://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions. > html#GetDirectBufferAddress > to get the address and then expose that via a JNI helper - in fact, that's > what was done before. But, there's a JNI call penalty here for what is > otherwise a memory read. DirectBuffer::address() solves that nicely, and > also plays well with the C2 JIT (as mentioned) because the callsites where > this is used only see DBB, and then the whole invokeinterface call is > devirtualized and inlined into a quick type check and Java field read - the > performance of this is, as you can imagine, significantly better than the > JNI approach. > > If you think of what a DBB really is, it's pretty much what it's name > suggests - it's an API to read/write to native memory, rather than Java > heap memory (i.e. HeapByteBuffer). But, there's no reason the native > memory backing the DBB has to also be allocated via Unsafe itself, although > that's the more common scenario. > > On the Java side, consumers of this have a common and conventional API > over > a byte buffer, i.e. ByteBuffer, which can optionally be used in the manner > above (obviously callers will need to know what mode they're using). > > > > -Chris. > > > > From vitalyd at gmail.com Thu Feb 23 17:05:36 2017 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 23 Feb 2017 12:05:36 -0500 Subject: sun.nio.ch.DirectBuffer and jdk9/jigsaw In-Reply-To: <045301d28df5$7452c0d0$5cf84270$@apache.org> References: <909585ba-241c-eeef-7cc8-14312dd69a37@oracle.com> <1A7655EE-37AF-4C91-B16B-7E81F819E3D0@oracle.com> <045301d28df5$7452c0d0$5cf84270$@apache.org> Message-ID: On Thu, Feb 23, 2017 at 11:54 AM, Uwe Schindler wrote: > Hi, > > Why do you need the address at all in the Java code? Java code can use the > official ByteBuffer methods to access the memory you are wrapping. In Java > 9 that?s optimized very good by Hotspot and should be almost as fast as > array accesses (we proved that in Apache Lucene - congrats to the Hotspot > committers). If you need special access modes like volatile access, then > you can use Java 9's VarHandles. You can get a VarHandle to the backing > direct buffer using the MethodHandles API. > I mentioned this upthread - the base address is used for index calculations to read/write data using Unsafe directly. I don't know about Java 9 as I've not tried it yet, but the generated assembly for using BB methods vs Unsafe did not favor BB. There are also various safety checks in DBB/Buffer internals that won't get optimized away. Also, my general experience with looking at C2 optimizations has led me to the conclusion that the optimizations are "unstable" - innocent code changes, differences in order of how classes are loaded, differences in what callsites trigger compilation first, and a bunch of other otherwise benign things can interfere with inlining decisions, which is typically the reason things go sideways in terms of optimization. As for MethodHandles and VarHandles, that's one possibility I'm considering as a way to migrate off using DirectBuffer (although I'd still like to know if there's any plan to standardize/formalize some notion of a direct buffer). However, my understanding is that using MH will still require me to crack into jdk code (to get access to the DBB and friends) and thus require addExports. DirectBuffer is still accessible if using addExports, but it's a wrinkle I was hoping to iron out, hence what started this email chain. > > Uwe > > ----- > Uwe Schindler > uschindler at apache.org > ASF Member, Apache Lucene PMC / Committer > Bremen, Germany > http://lucene.apache.org/ > > > -----Original Message----- > > From: jigsaw-dev [mailto:jigsaw-dev-bounces at openjdk.java.net] On Behalf > > Of Vitaly Davidovich > > Sent: Thursday, February 23, 2017 5:30 PM > > To: Chris Hegarty > > Cc: jigsaw-dev > > Subject: Re: sun.nio.ch.DirectBuffer and jdk9/jigsaw > > > > On Thu, Feb 23, 2017 at 11:10 AM, Chris Hegarty > > > > wrote: > > > > > > > > > On 23 Feb 2017, at 11:30, Vitaly Davidovich > wrote: > > > >> ... > > > > The buffers are reused by having them point to different native > memory > > > > block addresses; those blocks are managed by native code. As > > mentioned, > > > > the ByteBuffer (DirectByteBuffer concretely) is used as the Java > level > > > > interface/view of native memory, allowing Java and native code to > > > > communicate. > > > > > > So a DBB, under your code, may report a different address at some time > > > in the future, to that of what it currently reports? > > > > Correct. > > > > > I was not aware of this > > > usecase. Is any similar code available on the web, or elsewhere, so we > > > could try to determine why this is being done? > > > > > Unfortunately it's not open source code, and I don't immediately know of > > anything similar on the web (or otherwise). However, the gist is the > > following: > > 1) Allocate a 0-size DBB (i.e. ByteBuffer.allocateDirect(0)). This gives > > you a Java "handle", if you will, to some native memory. But, since this > > DBB will be attached/reattached to different memory dynamically, there's > no > > need for an actual allocation. > > 2) Native code wants to expose a segment of memory to Java. In JNI, it > > sets the address and capacity of this DBB to the pointer where the native > > memory segment starts, and to the capacity (it knows how big the native > > segment is). Java code asks for this DBB to be "attached" to, say, some > > sort of message, and the JNI/native code perform these functions. > > 3) Java gets the attached DBB back, and can then use its API > > (getXXX/setXXX) to read/write that native block. Once the operation > > completes, the DBB is recycled for reuse (i.e. can be attached to a > > different native segment again). > > > > Obviously, we can use > > http://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions > . > > html#GetDirectBufferAddress > > to get the address and then expose that via a JNI helper - in fact, > that's > > what was done before. But, there's a JNI call penalty here for what is > > otherwise a memory read. DirectBuffer::address() solves that nicely, and > > also plays well with the C2 JIT (as mentioned) because the callsites > where > > this is used only see DBB, and then the whole invokeinterface call is > > devirtualized and inlined into a quick type check and Java field read - > the > > performance of this is, as you can imagine, significantly better than the > > JNI approach. > > > > If you think of what a DBB really is, it's pretty much what it's name > > suggests - it's an API to read/write to native memory, rather than Java > > heap memory (i.e. HeapByteBuffer). But, there's no reason the native > > memory backing the DBB has to also be allocated via Unsafe itself, > although > > that's the more common scenario. > > > > On the Java side, consumers of this have a common and conventional API > > over > > a byte buffer, i.e. ByteBuffer, which can optionally be used in the > manner > > above (obviously callers will need to know what mode they're using). > > > > > > > -Chris. > > > > > > > > From claes.redestad at oracle.com Thu Feb 23 17:34:44 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 23 Feb 2017 18:34:44 +0100 Subject: RFR: 8169713: jimage fails with StringIndexOutOfBoundsException when path to the inspected image is an empty string Message-ID: <3e6a45e1-d932-44c4-58a4-367f311c4df2@oracle.com> Hi, please review this fix to make the jimage tool work correctly for empty string: diff -r b2661d26e556 src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java --- a/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java Wed Feb 22 14:12:01 2017 -0800 +++ b/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java Thu Feb 23 18:27:48 2017 +0100 @@ -524,7 +524,7 @@ List rest = collectUnhandled? new ArrayList<>() : null; // process options for (int i = 0; i < args.length; i++) { - if (args[i].charAt(0) == '-') { + if (args[i].startsWith("-")) { String name = args[i]; PluginOption pluginOption = null; Option option = getOption(name); /Claes From james.laskey at oracle.com Thu Feb 23 17:38:12 2017 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Thu, 23 Feb 2017 13:38:12 -0400 Subject: RFR: 8169713: jimage fails with StringIndexOutOfBoundsException when path to the inspected image is an empty string In-Reply-To: <3e6a45e1-d932-44c4-58a4-367f311c4df2@oracle.com> References: <3e6a45e1-d932-44c4-58a4-367f311c4df2@oracle.com> Message-ID: <36B861A9-6CCF-412B-8B60-73B1044AA848@oracle.com> +1 > On Feb 23, 2017, at 1:34 PM, Claes Redestad wrote: > > Hi, > > please review this fix to make the jimage tool work correctly > for empty string: > > diff -r b2661d26e556 src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java > --- a/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java Wed Feb 22 14:12:01 2017 -0800 > +++ b/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java Thu Feb 23 18:27:48 2017 +0100 > @@ -524,7 +524,7 @@ > List rest = collectUnhandled? new ArrayList<>() : null; > // process options > for (int i = 0; i < args.length; i++) { > - if (args[i].charAt(0) == '-') { > + if (args[i].startsWith("-")) { > String name = args[i]; > PluginOption pluginOption = null; > Option option = getOption(name); > > /Claes From claes.redestad at oracle.com Thu Feb 23 17:41:10 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 23 Feb 2017 18:41:10 +0100 Subject: RFR: 8169713: jimage fails with StringIndexOutOfBoundsException when path to the inspected image is an empty string In-Reply-To: <36B861A9-6CCF-412B-8B60-73B1044AA848@oracle.com> References: <3e6a45e1-d932-44c4-58a4-367f311c4df2@oracle.com> <36B861A9-6CCF-412B-8B60-73B1044AA848@oracle.com> Message-ID: Thanks - pushed! /Claes On 2017-02-23 18:38, Jim Laskey (Oracle) wrote: > +1 > >> On Feb 23, 2017, at 1:34 PM, Claes Redestad wrote: >> >> Hi, >> >> please review this fix to make the jimage tool work correctly >> for empty string: >> >> diff -r b2661d26e556 src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java >> --- a/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java Wed Feb 22 14:12:01 2017 -0800 >> +++ b/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java Thu Feb 23 18:27:48 2017 +0100 >> @@ -524,7 +524,7 @@ >> List rest = collectUnhandled? new ArrayList<>() : null; >> // process options >> for (int i = 0; i < args.length; i++) { >> - if (args[i].charAt(0) == '-') { >> + if (args[i].startsWith("-")) { >> String name = args[i]; >> PluginOption pluginOption = null; >> Option option = getOption(name); >> >> /Claes > From uschindler at apache.org Thu Feb 23 17:45:36 2017 From: uschindler at apache.org (Uwe Schindler) Date: Thu, 23 Feb 2017 18:45:36 +0100 Subject: sun.nio.ch.DirectBuffer and jdk9/jigsaw In-Reply-To: References: <909585ba-241c-eeef-7cc8-14312dd69a37@oracle.com> <1A7655EE-37AF-4C91-B16B-7E81F819E3D0@oracle.com> <045301d28df5$7452c0d0$5cf84270$@apache.org> Message-ID: <046a01d28dfc$a6805930$f3810b90$@apache.org> Hi, Why do you need the address at all in the Java code? Java code can use the official ByteBuffer methods to access the memory you are wrapping. In Java 9 that?s optimized very good by Hotspot and should be almost as fast as array accesses (we proved that in Apache Lucene - congrats to the Hotspot committers). If you need special access modes like volatile access, then you can use Java 9's VarHandles. You can get a VarHandle to the backing direct buffer using the MethodHandles API. I mentioned this upthread - the base address is used for index calculations to read/write data using Unsafe directly. I don't know about Java 9 as I've not tried it yet, but the generated assembly for using BB methods vs Unsafe did not favor BB. There are also various safety checks in DBB/Buffer internals that won't get optimized away. Also, my general experience with looking at C2 optimizations has led me to the conclusion that the optimizations are "unstable" - innocent code changes, differences in order of how classes are loaded, differences in what callsites trigger compilation first, and a bunch of other otherwise benign things can interfere with inlining decisions, which is typically the reason things go sideways in terms of optimization. As for MethodHandles and VarHandles, that's one possibility I'm considering as a way to migrate off using DirectBuffer (although I'd still like to know if there's any plan to standardize/formalize some notion of a direct buffer). However, my understanding is that using MH will still require me to crack into jdk code (to get access to the DBB and friends) and thus require addExports. DirectBuffer is still accessible if using addExports, but it's a wrinkle I was hoping to iron out, hence what started this email chain. with VarHandles you can directly access the underlying native memory. You can get a ByteBufferView varhandle - no cracks and Unsafe needed: < http://download.java.net/java/jdk9/docs/api/java/lang/invoke/MethodHandles.html#byteBufferViewVarHandle-java.lang.Class-java.nio.ByteOrder-> Uwe From vitalyd at gmail.com Thu Feb 23 18:04:05 2017 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 23 Feb 2017 13:04:05 -0500 Subject: sun.nio.ch.DirectBuffer and jdk9/jigsaw In-Reply-To: <046a01d28dfc$a6805930$f3810b90$@apache.org> References: <909585ba-241c-eeef-7cc8-14312dd69a37@oracle.com> <1A7655EE-37AF-4C91-B16B-7E81F819E3D0@oracle.com> <045301d28df5$7452c0d0$5cf84270$@apache.org> <046a01d28dfc$a6805930$f3810b90$@apache.org> Message-ID: On Thu, Feb 23, 2017 at 12:45 PM, Uwe Schindler wrote: > Hi, > > > > Why do you need the address at all in the Java code? Java code can use > the official ByteBuffer methods to access the memory you are wrapping. In > Java 9 that?s optimized very good by Hotspot and should be almost as fast > as array accesses (we proved that in Apache Lucene - congrats to the > Hotspot committers). If you need special access modes like volatile access, > then you can use Java 9's VarHandles. You can get a VarHandle to the > backing direct buffer using the MethodHandles API. > > I mentioned this upthread - the base address is used for index > calculations to read/write data using Unsafe directly. I don't know about > Java 9 as I've not tried it yet, but the generated assembly for using BB > methods vs Unsafe did not favor BB. There are also various safety checks > in DBB/Buffer internals that won't get optimized away. > > > > Also, my general experience with looking at C2 optimizations has led me to > the conclusion that the optimizations are "unstable" - innocent code > changes, differences in order of how classes are loaded, differences in > what callsites trigger compilation first, and a bunch of other otherwise > benign things can interfere with inlining decisions, which is typically the > reason things go sideways in terms of optimization. > > > > As for MethodHandles and VarHandles, that's one possibility I'm > considering as a way to migrate off using DirectBuffer (although I'd still > like to know if there's any plan to standardize/formalize some notion of a > direct buffer). However, my understanding is that using MH will still > require me to crack into jdk code (to get access to the DBB and friends) > and thus require addExports. DirectBuffer is still accessible if using > addExports, but it's a wrinkle I was hoping to iron out, hence what started > this email chain. > > > > with VarHandles you can directly access the underlying native memory. You > can get a ByteBufferView varhandle - no cracks and Unsafe needed: > > invoke/MethodHandles.html#byteBufferViewVarHandle-java. > lang.Class-java.nio.ByteOrder-> > Thanks Uwe - I didn't realize there was a special case for BB in VH; I'll need to play with it. Is access to a DBB via VH supposed to be faster than using the BB API itself? I vaguely recall seeing some email(s) on one of the openjdk lists about VH not matching Unsafe in terms of generated code quality, and VH is supposed to be the successor/replacement for Unsafe (which we also use, as mentioned). > > > Uwe > From forax at univ-mlv.fr Thu Feb 23 18:05:37 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 23 Feb 2017 19:05:37 +0100 (CET) Subject: sun.nio.ch.DirectBuffer and jdk9/jigsaw In-Reply-To: References: <1A7655EE-37AF-4C91-B16B-7E81F819E3D0@oracle.com> <045301d28df5$7452c0d0$5cf84270$@apache.org> Message-ID: <1248462510.1814413.1487873137869.JavaMail.zimbra@u-pem.fr> Hi Vitaly, I believe that what you are looking for is MethodHandles.byteBufferViewVarHandle [1] that creates a VarHandle that allows to do aligned/unaligned access on a ByteBuffer. It should be a little slower that using Unsafe because of the bound check (and the nullcheck but it is usually removed by the VM). That's said, unaligned access are faster with a VarHandle because sun.misc.Unsafe (which is stuck in the Java 8 world unlinke jdk.internal.misc.Unsafe) does not provide a way to do an unaligned access so you have do multiple read which is slower. cheers, R?mi http://download.java.net/java/jdk9/docs/api/java/lang/invoke/MethodHandles.html#byteBufferViewVarHandle-java.lang.Class-java.nio.ByteOrder- ----- Mail original ----- > De: "Vitaly Davidovich" > ?: "Uwe Schindler" > Cc: "jigsaw-dev" > Envoy?: Jeudi 23 F?vrier 2017 18:05:36 > Objet: Re: sun.nio.ch.DirectBuffer and jdk9/jigsaw > On Thu, Feb 23, 2017 at 11:54 AM, Uwe Schindler > wrote: > >> Hi, >> >> Why do you need the address at all in the Java code? Java code can use the >> official ByteBuffer methods to access the memory you are wrapping. In Java >> 9 that?s optimized very good by Hotspot and should be almost as fast as >> array accesses (we proved that in Apache Lucene - congrats to the Hotspot >> committers). If you need special access modes like volatile access, then >> you can use Java 9's VarHandles. You can get a VarHandle to the backing >> direct buffer using the MethodHandles API. >> > I mentioned this upthread - the base address is used for index calculations > to read/write data using Unsafe directly. I don't know about Java 9 as > I've not tried it yet, but the generated assembly for using BB methods vs > Unsafe did not favor BB. There are also various safety checks in > DBB/Buffer internals that won't get optimized away. > > Also, my general experience with looking at C2 optimizations has led me to > the conclusion that the optimizations are "unstable" - innocent code > changes, differences in order of how classes are loaded, differences in > what callsites trigger compilation first, and a bunch of other otherwise > benign things can interfere with inlining decisions, which is typically the > reason things go sideways in terms of optimization. > > As for MethodHandles and VarHandles, that's one possibility I'm considering > as a way to migrate off using DirectBuffer (although I'd still like to know > if there's any plan to standardize/formalize some notion of a direct > buffer). However, my understanding is that using MH will still require me > to crack into jdk code (to get access to the DBB and friends) and thus > require addExports. DirectBuffer is still accessible if using addExports, > but it's a wrinkle I was hoping to iron out, hence what started this email > chain. > >> >> Uwe >> >> ----- >> Uwe Schindler >> uschindler at apache.org >> ASF Member, Apache Lucene PMC / Committer >> Bremen, Germany >> http://lucene.apache.org/ >> >> > -----Original Message----- >> > From: jigsaw-dev [mailto:jigsaw-dev-bounces at openjdk.java.net] On Behalf >> > Of Vitaly Davidovich >> > Sent: Thursday, February 23, 2017 5:30 PM >> > To: Chris Hegarty >> > Cc: jigsaw-dev >> > Subject: Re: sun.nio.ch.DirectBuffer and jdk9/jigsaw >> > >> > On Thu, Feb 23, 2017 at 11:10 AM, Chris Hegarty >> > >> > wrote: >> > >> > > >> > > > On 23 Feb 2017, at 11:30, Vitaly Davidovich >> wrote: >> > > >> ... >> > > > The buffers are reused by having them point to different native >> memory >> > > > block addresses; those blocks are managed by native code. As >> > mentioned, >> > > > the ByteBuffer (DirectByteBuffer concretely) is used as the Java >> level >> > > > interface/view of native memory, allowing Java and native code to >> > > > communicate. >> > > >> > > So a DBB, under your code, may report a different address at some time >> > > in the future, to that of what it currently reports? >> > >> > Correct. >> > >> > > I was not aware of this >> > > usecase. Is any similar code available on the web, or elsewhere, so we >> > > could try to determine why this is being done? >> > > >> > Unfortunately it's not open source code, and I don't immediately know of >> > anything similar on the web (or otherwise). However, the gist is the >> > following: >> > 1) Allocate a 0-size DBB (i.e. ByteBuffer.allocateDirect(0)). This gives >> > you a Java "handle", if you will, to some native memory. But, since this >> > DBB will be attached/reattached to different memory dynamically, there's >> no >> > need for an actual allocation. >> > 2) Native code wants to expose a segment of memory to Java. In JNI, it >> > sets the address and capacity of this DBB to the pointer where the native >> > memory segment starts, and to the capacity (it knows how big the native >> > segment is). Java code asks for this DBB to be "attached" to, say, some >> > sort of message, and the JNI/native code perform these functions. >> > 3) Java gets the attached DBB back, and can then use its API >> > (getXXX/setXXX) to read/write that native block. Once the operation >> > completes, the DBB is recycled for reuse (i.e. can be attached to a >> > different native segment again). >> > >> > Obviously, we can use >> > http://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions >> . >> > html#GetDirectBufferAddress >> > to get the address and then expose that via a JNI helper - in fact, >> that's >> > what was done before. But, there's a JNI call penalty here for what is >> > otherwise a memory read. DirectBuffer::address() solves that nicely, and >> > also plays well with the C2 JIT (as mentioned) because the callsites >> where >> > this is used only see DBB, and then the whole invokeinterface call is >> > devirtualized and inlined into a quick type check and Java field read - >> the >> > performance of this is, as you can imagine, significantly better than the >> > JNI approach. >> > >> > If you think of what a DBB really is, it's pretty much what it's name >> > suggests - it's an API to read/write to native memory, rather than Java >> > heap memory (i.e. HeapByteBuffer). But, there's no reason the native >> > memory backing the DBB has to also be allocated via Unsafe itself, >> although >> > that's the more common scenario. >> > >> > On the Java side, consumers of this have a common and conventional API >> > over >> > a byte buffer, i.e. ByteBuffer, which can optionally be used in the >> manner >> > above (obviously callers will need to know what mode they're using). >> > >> > >> > > -Chris. >> > > >> > > >> From uschindler at apache.org Thu Feb 23 18:16:44 2017 From: uschindler at apache.org (Uwe Schindler) Date: Thu, 23 Feb 2017 19:16:44 +0100 Subject: sun.nio.ch.DirectBuffer and jdk9/jigsaw In-Reply-To: <1248462510.1814413.1487873137869.JavaMail.zimbra@u-pem.fr> References: <1A7655EE-37AF-4C91-B16B-7E81F819E3D0@oracle.com> <045301d28df5$7452c0d0$5cf84270$@apache.org> <1248462510.1814413.1487873137869.JavaMail.zimbra@u-pem.fr> Message-ID: <047101d28e01$0118a6f0$0349f4d0$@apache.org> Hi, > I believe that what you are looking for is > MethodHandles.byteBufferViewVarHandle [1] that creates a VarHandle that > allows to do aligned/unaligned access on a ByteBuffer. Related question: I wonder why there is now way to get a view on a ByteBuffer as a byte[]-typed Varhandle (byte[] and boolean[] views are explicitly excluded - why????)? It throws UnsupportedOperationExeception! To me this is inconsistent. You can get a Varhandle for byte[] arrays, but not ByteBuffers. I know it brings not much, but you would have the possibility to have "generic code" for all types. And by looking at the source code, there is no reason to not generate the byte[] view, in fact it is already available in the generated class for array-views. Should I open a feature request? This was something we were stuck when trying to use VarHandles inside Lucene to access memory mapped files as VarHandles (would be really cool). But we need a byte[] view, too!!! Uwe > It should be a little slower that using Unsafe because of the bound check > (and the nullcheck but it is usually removed by the VM). > That's said, unaligned access are faster with a VarHandle because > sun.misc.Unsafe (which is stuck in the Java 8 world unlinke > jdk.internal.misc.Unsafe) does not provide a way to do an unaligned access > so you have do multiple read which is slower. > > cheers, > R?mi > > http://download.java.net/java/jdk9/docs/api/java/lang/invoke/MethodHan > dles.html#byteBufferViewVarHandle-java.lang.Class-java.nio.ByteOrder- > > ----- Mail original ----- > > De: "Vitaly Davidovich" > > ?: "Uwe Schindler" > > Cc: "jigsaw-dev" > > Envoy?: Jeudi 23 F?vrier 2017 18:05:36 > > Objet: Re: sun.nio.ch.DirectBuffer and jdk9/jigsaw > > > On Thu, Feb 23, 2017 at 11:54 AM, Uwe Schindler > > > wrote: > > > >> Hi, > >> > >> Why do you need the address at all in the Java code? Java code can use > the > >> official ByteBuffer methods to access the memory you are wrapping. In > Java > >> 9 that?s optimized very good by Hotspot and should be almost as fast as > >> array accesses (we proved that in Apache Lucene - congrats to the Hotspot > >> committers). If you need special access modes like volatile access, then > >> you can use Java 9's VarHandles. You can get a VarHandle to the backing > >> direct buffer using the MethodHandles API. > >> > > I mentioned this upthread - the base address is used for index calculations > > to read/write data using Unsafe directly. I don't know about Java 9 as > > I've not tried it yet, but the generated assembly for using BB methods vs > > Unsafe did not favor BB. There are also various safety checks in > > DBB/Buffer internals that won't get optimized away. > > > > Also, my general experience with looking at C2 optimizations has led me to > > the conclusion that the optimizations are "unstable" - innocent code > > changes, differences in order of how classes are loaded, differences in > > what callsites trigger compilation first, and a bunch of other otherwise > > benign things can interfere with inlining decisions, which is typically the > > reason things go sideways in terms of optimization. > > > > As for MethodHandles and VarHandles, that's one possibility I'm > considering > > as a way to migrate off using DirectBuffer (although I'd still like to know > > if there's any plan to standardize/formalize some notion of a direct > > buffer). However, my understanding is that using MH will still require me > > to crack into jdk code (to get access to the DBB and friends) and thus > > require addExports. DirectBuffer is still accessible if using addExports, > > but it's a wrinkle I was hoping to iron out, hence what started this email > > chain. > > > >> > >> Uwe > >> > >> ----- > >> Uwe Schindler > >> uschindler at apache.org > >> ASF Member, Apache Lucene PMC / Committer > >> Bremen, Germany > >> http://lucene.apache.org/ > >> > >> > -----Original Message----- > >> > From: jigsaw-dev [mailto:jigsaw-dev-bounces at openjdk.java.net] On > Behalf > >> > Of Vitaly Davidovich > >> > Sent: Thursday, February 23, 2017 5:30 PM > >> > To: Chris Hegarty > >> > Cc: jigsaw-dev > >> > Subject: Re: sun.nio.ch.DirectBuffer and jdk9/jigsaw > >> > > >> > On Thu, Feb 23, 2017 at 11:10 AM, Chris Hegarty > >> > > >> > wrote: > >> > > >> > > > >> > > > On 23 Feb 2017, at 11:30, Vitaly Davidovich > >> wrote: > >> > > >> ... > >> > > > The buffers are reused by having them point to different native > >> memory > >> > > > block addresses; those blocks are managed by native code. As > >> > mentioned, > >> > > > the ByteBuffer (DirectByteBuffer concretely) is used as the Java > >> level > >> > > > interface/view of native memory, allowing Java and native code to > >> > > > communicate. > >> > > > >> > > So a DBB, under your code, may report a different address at some > time > >> > > in the future, to that of what it currently reports? > >> > > >> > Correct. > >> > > >> > > I was not aware of this > >> > > usecase. Is any similar code available on the web, or elsewhere, so we > >> > > could try to determine why this is being done? > >> > > > >> > Unfortunately it's not open source code, and I don't immediately know > of > >> > anything similar on the web (or otherwise). However, the gist is the > >> > following: > >> > 1) Allocate a 0-size DBB (i.e. ByteBuffer.allocateDirect(0)). This gives > >> > you a Java "handle", if you will, to some native memory. But, since this > >> > DBB will be attached/reattached to different memory dynamically, > there's > >> no > >> > need for an actual allocation. > >> > 2) Native code wants to expose a segment of memory to Java. In JNI, it > >> > sets the address and capacity of this DBB to the pointer where the native > >> > memory segment starts, and to the capacity (it knows how big the native > >> > segment is). Java code asks for this DBB to be "attached" to, say, some > >> > sort of message, and the JNI/native code perform these functions. > >> > 3) Java gets the attached DBB back, and can then use its API > >> > (getXXX/setXXX) to read/write that native block. Once the operation > >> > completes, the DBB is recycled for reuse (i.e. can be attached to a > >> > different native segment again). > >> > > >> > Obviously, we can use > >> > > http://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions > >> . > >> > html#GetDirectBufferAddress > >> > to get the address and then expose that via a JNI helper - in fact, > >> that's > >> > what was done before. But, there's a JNI call penalty here for what is > >> > otherwise a memory read. DirectBuffer::address() solves that nicely, > and > >> > also plays well with the C2 JIT (as mentioned) because the callsites > >> where > >> > this is used only see DBB, and then the whole invokeinterface call is > >> > devirtualized and inlined into a quick type check and Java field read - > >> the > >> > performance of this is, as you can imagine, significantly better than the > >> > JNI approach. > >> > > >> > If you think of what a DBB really is, it's pretty much what it's name > >> > suggests - it's an API to read/write to native memory, rather than Java > >> > heap memory (i.e. HeapByteBuffer). But, there's no reason the native > >> > memory backing the DBB has to also be allocated via Unsafe itself, > >> although > >> > that's the more common scenario. > >> > > >> > On the Java side, consumers of this have a common and conventional > API > >> > over > >> > a byte buffer, i.e. ByteBuffer, which can optionally be used in the > >> manner > >> > above (obviously callers will need to know what mode they're using). > >> > > >> > > >> > > -Chris. > >> > > > >> > > > >> From vitalyd at gmail.com Thu Feb 23 18:17:57 2017 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 23 Feb 2017 13:17:57 -0500 Subject: sun.nio.ch.DirectBuffer and jdk9/jigsaw In-Reply-To: <1248462510.1814413.1487873137869.JavaMail.zimbra@u-pem.fr> References: <1A7655EE-37AF-4C91-B16B-7E81F819E3D0@oracle.com> <045301d28df5$7452c0d0$5cf84270$@apache.org> <1248462510.1814413.1487873137869.JavaMail.zimbra@u-pem.fr> Message-ID: Hey Remi, Indeed - Uwe just beat you slightly to the punch. I'll need to play with it to see what "little slower" actually translates to :). Thanks P.S. We've nicely sidetracked a bit from my original question, but I suppose the between-the-lines answer is that there's no plan to expose some of the guts of a direct buffer in a supported manner. On Thu, Feb 23, 2017 at 1:05 PM, Remi Forax wrote: > Hi Vitaly, > I believe that what you are looking for is MethodHandles.byteBufferViewVarHandle > [1] that creates a VarHandle that allows to do aligned/unaligned access on > a ByteBuffer. > It should be a little slower that using Unsafe because of the bound check > (and the nullcheck but it is usually removed by the VM). > That's said, unaligned access are faster with a VarHandle because > sun.misc.Unsafe (which is stuck in the Java 8 world unlinke > jdk.internal.misc.Unsafe) does not provide a way to do an unaligned access > so you have do multiple read which is slower. > > cheers, > R?mi > > http://download.java.net/java/jdk9/docs/api/java/lang/ > invoke/MethodHandles.html#byteBufferViewVarHandle-java. > lang.Class-java.nio.ByteOrder- > > ----- Mail original ----- > > De: "Vitaly Davidovich" > > ?: "Uwe Schindler" > > Cc: "jigsaw-dev" > > Envoy?: Jeudi 23 F?vrier 2017 18:05:36 > > Objet: Re: sun.nio.ch.DirectBuffer and jdk9/jigsaw > > > On Thu, Feb 23, 2017 at 11:54 AM, Uwe Schindler > > wrote: > > > >> Hi, > >> > >> Why do you need the address at all in the Java code? Java code can use > the > >> official ByteBuffer methods to access the memory you are wrapping. In > Java > >> 9 that?s optimized very good by Hotspot and should be almost as fast as > >> array accesses (we proved that in Apache Lucene - congrats to the > Hotspot > >> committers). If you need special access modes like volatile access, then > >> you can use Java 9's VarHandles. You can get a VarHandle to the backing > >> direct buffer using the MethodHandles API. > >> > > I mentioned this upthread - the base address is used for index > calculations > > to read/write data using Unsafe directly. I don't know about Java 9 as > > I've not tried it yet, but the generated assembly for using BB methods vs > > Unsafe did not favor BB. There are also various safety checks in > > DBB/Buffer internals that won't get optimized away. > > > > Also, my general experience with looking at C2 optimizations has led me > to > > the conclusion that the optimizations are "unstable" - innocent code > > changes, differences in order of how classes are loaded, differences in > > what callsites trigger compilation first, and a bunch of other otherwise > > benign things can interfere with inlining decisions, which is typically > the > > reason things go sideways in terms of optimization. > > > > As for MethodHandles and VarHandles, that's one possibility I'm > considering > > as a way to migrate off using DirectBuffer (although I'd still like to > know > > if there's any plan to standardize/formalize some notion of a direct > > buffer). However, my understanding is that using MH will still require > me > > to crack into jdk code (to get access to the DBB and friends) and thus > > require addExports. DirectBuffer is still accessible if using > addExports, > > but it's a wrinkle I was hoping to iron out, hence what started this > email > > chain. > > > >> > >> Uwe > >> > >> ----- > >> Uwe Schindler > >> uschindler at apache.org > >> ASF Member, Apache Lucene PMC / Committer > >> Bremen, Germany > >> http://lucene.apache.org/ > >> > >> > -----Original Message----- > >> > From: jigsaw-dev [mailto:jigsaw-dev-bounces at openjdk.java.net] On > Behalf > >> > Of Vitaly Davidovich > >> > Sent: Thursday, February 23, 2017 5:30 PM > >> > To: Chris Hegarty > >> > Cc: jigsaw-dev > >> > Subject: Re: sun.nio.ch.DirectBuffer and jdk9/jigsaw > >> > > >> > On Thu, Feb 23, 2017 at 11:10 AM, Chris Hegarty > >> > > >> > wrote: > >> > > >> > > > >> > > > On 23 Feb 2017, at 11:30, Vitaly Davidovich > >> wrote: > >> > > >> ... > >> > > > The buffers are reused by having them point to different native > >> memory > >> > > > block addresses; those blocks are managed by native code. As > >> > mentioned, > >> > > > the ByteBuffer (DirectByteBuffer concretely) is used as the Java > >> level > >> > > > interface/view of native memory, allowing Java and native code to > >> > > > communicate. > >> > > > >> > > So a DBB, under your code, may report a different address at some > time > >> > > in the future, to that of what it currently reports? > >> > > >> > Correct. > >> > > >> > > I was not aware of this > >> > > usecase. Is any similar code available on the web, or elsewhere, so > we > >> > > could try to determine why this is being done? > >> > > > >> > Unfortunately it's not open source code, and I don't immediately know > of > >> > anything similar on the web (or otherwise). However, the gist is the > >> > following: > >> > 1) Allocate a 0-size DBB (i.e. ByteBuffer.allocateDirect(0)). This > gives > >> > you a Java "handle", if you will, to some native memory. But, since > this > >> > DBB will be attached/reattached to different memory dynamically, > there's > >> no > >> > need for an actual allocation. > >> > 2) Native code wants to expose a segment of memory to Java. In JNI, > it > >> > sets the address and capacity of this DBB to the pointer where the > native > >> > memory segment starts, and to the capacity (it knows how big the > native > >> > segment is). Java code asks for this DBB to be "attached" to, say, > some > >> > sort of message, and the JNI/native code perform these functions. > >> > 3) Java gets the attached DBB back, and can then use its API > >> > (getXXX/setXXX) to read/write that native block. Once the operation > >> > completes, the DBB is recycled for reuse (i.e. can be attached to a > >> > different native segment again). > >> > > >> > Obviously, we can use > >> > http://docs.oracle.com/javase/8/docs/technotes/guides/jni/ > spec/functions > >> . > >> > html#GetDirectBufferAddress > >> > to get the address and then expose that via a JNI helper - in fact, > >> that's > >> > what was done before. But, there's a JNI call penalty here for what > is > >> > otherwise a memory read. DirectBuffer::address() solves that nicely, > and > >> > also plays well with the C2 JIT (as mentioned) because the callsites > >> where > >> > this is used only see DBB, and then the whole invokeinterface call is > >> > devirtualized and inlined into a quick type check and Java field read > - > >> the > >> > performance of this is, as you can imagine, significantly better than > the > >> > JNI approach. > >> > > >> > If you think of what a DBB really is, it's pretty much what it's name > >> > suggests - it's an API to read/write to native memory, rather than > Java > >> > heap memory (i.e. HeapByteBuffer). But, there's no reason the native > >> > memory backing the DBB has to also be allocated via Unsafe itself, > >> although > >> > that's the more common scenario. > >> > > >> > On the Java side, consumers of this have a common and conventional API > >> > over > >> > a byte buffer, i.e. ByteBuffer, which can optionally be used in the > >> manner > >> > above (obviously callers will need to know what mode they're using). > >> > > >> > > >> > > -Chris. > >> > > > >> > > > >> > From paul.sandoz at oracle.com Thu Feb 23 20:52:54 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 23 Feb 2017 12:52:54 -0800 Subject: sun.nio.ch.DirectBuffer and jdk9/jigsaw In-Reply-To: <1248462510.1814413.1487873137869.JavaMail.zimbra@u-pem.fr> References: <1A7655EE-37AF-4C91-B16B-7E81F819E3D0@oracle.com> <045301d28df5$7452c0d0$5cf84270$@apache.org> <1248462510.1814413.1487873137869.JavaMail.zimbra@u-pem.fr> Message-ID: > On 23 Feb 2017, at 10:05, Remi Forax wrote: > > Hi Vitaly, > I believe that what you are looking for is MethodHandles.byteBufferViewVarHandle [1] that creates a VarHandle that allows to do aligned/unaligned access on a ByteBuffer. > It should be a little slower that using Unsafe because of the bound check (and the nullcheck but it is usually removed by the VM). VarHandles for byte buffer views was primarily added to support enhanced atomic access to the contents of a byte buffer, all the methods route through to the internal Unsafe methods with safety checks (which for the most part can be optimized away, in loops at least, such as array bounds checks, read only checks, alignment checks for atomic ops). As part of the general work to encourage people not to use Unsafe we also made improvements to ByteBuffer (heap and direct) view access in JDK 9, primarily for x86 platforms (or those that support misaligned loads/stores). The performance analysis we did showed that VarHandle plain access and ByteBuffer view access are similar and C2 can generate good code in unrolled loops. So if you want plain access a ByteBuffer might be sufficient. Of course this will not be sufficient for those really pushing the boundaries. (It?s a race where we often behind trying to catch up!) -- The general way forward is Project Panama, where we can have better control over memory alloc/free, the overlay of structure, and safe pointers to such allocated structures. There will be optimisation challenges and value types are needed for a good API. (I am unsure if it might be possible to do something lower-level in the interim with minimal value types.) (I am wondering if Andrew Haley?s discussion on jmm-dev about safe deallocation of direct byte buffers also holds some clues for efficient safe pointer management.) Paul. > That's said, unaligned access are faster with a VarHandle because sun.misc.Unsafe (which is stuck in the Java 8 world unlinke jdk.internal.misc.Unsafe) does not provide a way to do an unaligned access so you have do multiple read which is slower. > > cheers, > R?mi > > http://download.java.net/java/jdk9/docs/api/java/lang/invoke/MethodHandles.html#byteBufferViewVarHandle-java.lang.Class-java.nio.ByteOrder- > > ----- Mail original ----- >> De: "Vitaly Davidovich" >> ?: "Uwe Schindler" >> Cc: "jigsaw-dev" >> Envoy?: Jeudi 23 F?vrier 2017 18:05:36 >> Objet: Re: sun.nio.ch.DirectBuffer and jdk9/jigsaw > >> On Thu, Feb 23, 2017 at 11:54 AM, Uwe Schindler >> wrote: >> >>> Hi, >>> >>> Why do you need the address at all in the Java code? Java code can use the >>> official ByteBuffer methods to access the memory you are wrapping. In Java >>> 9 that?s optimized very good by Hotspot and should be almost as fast as >>> array accesses (we proved that in Apache Lucene - congrats to the Hotspot >>> committers). If you need special access modes like volatile access, then >>> you can use Java 9's VarHandles. You can get a VarHandle to the backing >>> direct buffer using the MethodHandles API. >>> >> I mentioned this upthread - the base address is used for index calculations >> to read/write data using Unsafe directly. I don't know about Java 9 as >> I've not tried it yet, but the generated assembly for using BB methods vs >> Unsafe did not favor BB. There are also various safety checks in >> DBB/Buffer internals that won't get optimized away. >> >> Also, my general experience with looking at C2 optimizations has led me to >> the conclusion that the optimizations are "unstable" - innocent code >> changes, differences in order of how classes are loaded, differences in >> what callsites trigger compilation first, and a bunch of other otherwise >> benign things can interfere with inlining decisions, which is typically the >> reason things go sideways in terms of optimization. >> >> As for MethodHandles and VarHandles, that's one possibility I'm considering >> as a way to migrate off using DirectBuffer (although I'd still like to know >> if there's any plan to standardize/formalize some notion of a direct >> buffer). However, my understanding is that using MH will still require me >> to crack into jdk code (to get access to the DBB and friends) and thus >> require addExports. DirectBuffer is still accessible if using addExports, >> but it's a wrinkle I was hoping to iron out, hence what started this email >> chain. >> >>> >>> Uwe >>> >>> ----- >>> Uwe Schindler >>> uschindler at apache.org >>> ASF Member, Apache Lucene PMC / Committer >>> Bremen, Germany >>> http://lucene.apache.org/ >>> >>>> -----Original Message----- >>>> From: jigsaw-dev [mailto:jigsaw-dev-bounces at openjdk.java.net] On Behalf >>>> Of Vitaly Davidovich >>>> Sent: Thursday, February 23, 2017 5:30 PM >>>> To: Chris Hegarty >>>> Cc: jigsaw-dev >>>> Subject: Re: sun.nio.ch.DirectBuffer and jdk9/jigsaw >>>> >>>> On Thu, Feb 23, 2017 at 11:10 AM, Chris Hegarty >>>> >>>> wrote: >>>> >>>>> >>>>>> On 23 Feb 2017, at 11:30, Vitaly Davidovich >>> wrote: >>>>>>> ... >>>>>> The buffers are reused by having them point to different native >>> memory >>>>>> block addresses; those blocks are managed by native code. As >>>> mentioned, >>>>>> the ByteBuffer (DirectByteBuffer concretely) is used as the Java >>> level >>>>>> interface/view of native memory, allowing Java and native code to >>>>>> communicate. >>>>> >>>>> So a DBB, under your code, may report a different address at some time >>>>> in the future, to that of what it currently reports? >>>> >>>> Correct. >>>> >>>>> I was not aware of this >>>>> usecase. Is any similar code available on the web, or elsewhere, so we >>>>> could try to determine why this is being done? >>>>> >>>> Unfortunately it's not open source code, and I don't immediately know of >>>> anything similar on the web (or otherwise). However, the gist is the >>>> following: >>>> 1) Allocate a 0-size DBB (i.e. ByteBuffer.allocateDirect(0)). This gives >>>> you a Java "handle", if you will, to some native memory. But, since this >>>> DBB will be attached/reattached to different memory dynamically, there's >>> no >>>> need for an actual allocation. >>>> 2) Native code wants to expose a segment of memory to Java. In JNI, it >>>> sets the address and capacity of this DBB to the pointer where the native >>>> memory segment starts, and to the capacity (it knows how big the native >>>> segment is). Java code asks for this DBB to be "attached" to, say, some >>>> sort of message, and the JNI/native code perform these functions. >>>> 3) Java gets the attached DBB back, and can then use its API >>>> (getXXX/setXXX) to read/write that native block. Once the operation >>>> completes, the DBB is recycled for reuse (i.e. can be attached to a >>>> different native segment again). >>>> >>>> Obviously, we can use >>>> http://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions >>> . >>>> html#GetDirectBufferAddress >>>> to get the address and then expose that via a JNI helper - in fact, >>> that's >>>> what was done before. But, there's a JNI call penalty here for what is >>>> otherwise a memory read. DirectBuffer::address() solves that nicely, and >>>> also plays well with the C2 JIT (as mentioned) because the callsites >>> where >>>> this is used only see DBB, and then the whole invokeinterface call is >>>> devirtualized and inlined into a quick type check and Java field read - >>> the >>>> performance of this is, as you can imagine, significantly better than the >>>> JNI approach. >>>> >>>> If you think of what a DBB really is, it's pretty much what it's name >>>> suggests - it's an API to read/write to native memory, rather than Java >>>> heap memory (i.e. HeapByteBuffer). But, there's no reason the native >>>> memory backing the DBB has to also be allocated via Unsafe itself, >>> although >>>> that's the more common scenario. >>>> >>>> On the Java side, consumers of this have a common and conventional API >>>> over >>>> a byte buffer, i.e. ByteBuffer, which can optionally be used in the >>> manner >>>> above (obviously callers will need to know what mode they're using). >>>> >>>> >>>>> -Chris. >>>>> >>>>> >>> From vitalyd at gmail.com Thu Feb 23 20:58:03 2017 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 23 Feb 2017 15:58:03 -0500 Subject: sun.nio.ch.DirectBuffer and jdk9/jigsaw In-Reply-To: References: <1A7655EE-37AF-4C91-B16B-7E81F819E3D0@oracle.com> <045301d28df5$7452c0d0$5cf84270$@apache.org> <1248462510.1814413.1487873137869.JavaMail.zimbra@u-pem.fr> Message-ID: Thanks for the added color Paul. On Thu, Feb 23, 2017 at 3:52 PM, Paul Sandoz wrote: > > > On 23 Feb 2017, at 10:05, Remi Forax wrote: > > > > Hi Vitaly, > > I believe that what you are looking for is MethodHandles.byteBufferViewVarHandle > [1] that creates a VarHandle that allows to do aligned/unaligned access on > a ByteBuffer. > > It should be a little slower that using Unsafe because of the bound > check (and the nullcheck but it is usually removed by the VM). > > VarHandles for byte buffer views was primarily added to support enhanced > atomic access to the contents of a byte buffer, all the methods route > through to the internal Unsafe methods with safety checks (which for the > most part can be optimized away, in loops at least, such as array bounds > checks, read only checks, alignment checks for atomic ops). > > As part of the general work to encourage people not to use Unsafe we also > made improvements to ByteBuffer (heap and direct) view access in JDK 9, > primarily for x86 platforms (or those that support misaligned loads/stores). > > The performance analysis we did showed that VarHandle plain access and > ByteBuffer view access are similar and C2 can generate good code in > unrolled loops. So if you want plain access a ByteBuffer might be > sufficient. > > Of course this will not be sufficient for those really pushing the > boundaries. (It?s a race where we often behind trying to catch up!) > Unfortunately, the case I have is DBB access outside of a loop. Instead, it's many accesses sprinkled throughout code, with control flow and method call boundaries (i.e. possible inlining hazards) in between them - C2 "loses sight" of the big picture (I don't blame it) amidst all that noise, and therefore doesn't eliminate certain safety checks that could be coalesced had it seen the whole thing (as in the loop cases). > > -- > > The general way forward is Project Panama, where we can have better > control over memory alloc/free, the overlay of structure, and safe pointers > to such allocated structures. There will be optimisation challenges and > value types are needed for a good API. > > (I am unsure if it might be possible to do something lower-level in the > interim with minimal value types.) > > (I am wondering if Andrew Haley?s discussion on jmm-dev about safe > deallocation of direct byte buffers also holds some clues for efficient > safe pointer management.) > > Paul. > > > > That's said, unaligned access are faster with a VarHandle because > sun.misc.Unsafe (which is stuck in the Java 8 world unlinke > jdk.internal.misc.Unsafe) does not provide a way to do an unaligned access > so you have do multiple read which is slower. > > > > cheers, > > R?mi > > > > http://download.java.net/java/jdk9/docs/api/java/lang/ > invoke/MethodHandles.html#byteBufferViewVarHandle-java. > lang.Class-java.nio.ByteOrder- > > > > ----- Mail original ----- > >> De: "Vitaly Davidovich" > >> ?: "Uwe Schindler" > >> Cc: "jigsaw-dev" > >> Envoy?: Jeudi 23 F?vrier 2017 18:05:36 > >> Objet: Re: sun.nio.ch.DirectBuffer and jdk9/jigsaw > > > >> On Thu, Feb 23, 2017 at 11:54 AM, Uwe Schindler > >> wrote: > >> > >>> Hi, > >>> > >>> Why do you need the address at all in the Java code? Java code can use > the > >>> official ByteBuffer methods to access the memory you are wrapping. In > Java > >>> 9 that?s optimized very good by Hotspot and should be almost as fast as > >>> array accesses (we proved that in Apache Lucene - congrats to the > Hotspot > >>> committers). If you need special access modes like volatile access, > then > >>> you can use Java 9's VarHandles. You can get a VarHandle to the backing > >>> direct buffer using the MethodHandles API. > >>> > >> I mentioned this upthread - the base address is used for index > calculations > >> to read/write data using Unsafe directly. I don't know about Java 9 as > >> I've not tried it yet, but the generated assembly for using BB methods > vs > >> Unsafe did not favor BB. There are also various safety checks in > >> DBB/Buffer internals that won't get optimized away. > >> > >> Also, my general experience with looking at C2 optimizations has led me > to > >> the conclusion that the optimizations are "unstable" - innocent code > >> changes, differences in order of how classes are loaded, differences in > >> what callsites trigger compilation first, and a bunch of other otherwise > >> benign things can interfere with inlining decisions, which is typically > the > >> reason things go sideways in terms of optimization. > >> > >> As for MethodHandles and VarHandles, that's one possibility I'm > considering > >> as a way to migrate off using DirectBuffer (although I'd still like to > know > >> if there's any plan to standardize/formalize some notion of a direct > >> buffer). However, my understanding is that using MH will still require > me > >> to crack into jdk code (to get access to the DBB and friends) and thus > >> require addExports. DirectBuffer is still accessible if using > addExports, > >> but it's a wrinkle I was hoping to iron out, hence what started this > email > >> chain. > >> > >>> > >>> Uwe > >>> > >>> ----- > >>> Uwe Schindler > >>> uschindler at apache.org > >>> ASF Member, Apache Lucene PMC / Committer > >>> Bremen, Germany > >>> http://lucene.apache.org/ > >>> > >>>> -----Original Message----- > >>>> From: jigsaw-dev [mailto:jigsaw-dev-bounces at openjdk.java.net] On > Behalf > >>>> Of Vitaly Davidovich > >>>> Sent: Thursday, February 23, 2017 5:30 PM > >>>> To: Chris Hegarty > >>>> Cc: jigsaw-dev > >>>> Subject: Re: sun.nio.ch.DirectBuffer and jdk9/jigsaw > >>>> > >>>> On Thu, Feb 23, 2017 at 11:10 AM, Chris Hegarty > >>>> > >>>> wrote: > >>>> > >>>>> > >>>>>> On 23 Feb 2017, at 11:30, Vitaly Davidovich > >>> wrote: > >>>>>>> ... > >>>>>> The buffers are reused by having them point to different native > >>> memory > >>>>>> block addresses; those blocks are managed by native code. As > >>>> mentioned, > >>>>>> the ByteBuffer (DirectByteBuffer concretely) is used as the Java > >>> level > >>>>>> interface/view of native memory, allowing Java and native code to > >>>>>> communicate. > >>>>> > >>>>> So a DBB, under your code, may report a different address at some > time > >>>>> in the future, to that of what it currently reports? > >>>> > >>>> Correct. > >>>> > >>>>> I was not aware of this > >>>>> usecase. Is any similar code available on the web, or elsewhere, so > we > >>>>> could try to determine why this is being done? > >>>>> > >>>> Unfortunately it's not open source code, and I don't immediately know > of > >>>> anything similar on the web (or otherwise). However, the gist is the > >>>> following: > >>>> 1) Allocate a 0-size DBB (i.e. ByteBuffer.allocateDirect(0)). This > gives > >>>> you a Java "handle", if you will, to some native memory. But, since > this > >>>> DBB will be attached/reattached to different memory dynamically, > there's > >>> no > >>>> need for an actual allocation. > >>>> 2) Native code wants to expose a segment of memory to Java. In JNI, > it > >>>> sets the address and capacity of this DBB to the pointer where the > native > >>>> memory segment starts, and to the capacity (it knows how big the > native > >>>> segment is). Java code asks for this DBB to be "attached" to, say, > some > >>>> sort of message, and the JNI/native code perform these functions. > >>>> 3) Java gets the attached DBB back, and can then use its API > >>>> (getXXX/setXXX) to read/write that native block. Once the operation > >>>> completes, the DBB is recycled for reuse (i.e. can be attached to a > >>>> different native segment again). > >>>> > >>>> Obviously, we can use > >>>> http://docs.oracle.com/javase/8/docs/technotes/guides/jni/ > spec/functions > >>> . > >>>> html#GetDirectBufferAddress > >>>> to get the address and then expose that via a JNI helper - in fact, > >>> that's > >>>> what was done before. But, there's a JNI call penalty here for what > is > >>>> otherwise a memory read. DirectBuffer::address() solves that nicely, > and > >>>> also plays well with the C2 JIT (as mentioned) because the callsites > >>> where > >>>> this is used only see DBB, and then the whole invokeinterface call is > >>>> devirtualized and inlined into a quick type check and Java field read > - > >>> the > >>>> performance of this is, as you can imagine, significantly better than > the > >>>> JNI approach. > >>>> > >>>> If you think of what a DBB really is, it's pretty much what it's name > >>>> suggests - it's an API to read/write to native memory, rather than > Java > >>>> heap memory (i.e. HeapByteBuffer). But, there's no reason the native > >>>> memory backing the DBB has to also be allocated via Unsafe itself, > >>> although > >>>> that's the more common scenario. > >>>> > >>>> On the Java side, consumers of this have a common and conventional API > >>>> over > >>>> a byte buffer, i.e. ByteBuffer, which can optionally be used in the > >>> manner > >>>> above (obviously callers will need to know what mode they're using). > >>>> > >>>> > >>>>> -Chris. > >>>>> > >>>>> > >>> > > From forax at univ-mlv.fr Thu Feb 23 21:31:35 2017 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 23 Feb 2017 22:31:35 +0100 (CET) Subject: sun.nio.ch.DirectBuffer and jdk9/jigsaw In-Reply-To: <047101d28e01$0118a6f0$0349f4d0$@apache.org> References: <1A7655EE-37AF-4C91-B16B-7E81F819E3D0@oracle.com> <045301d28df5$7452c0d0$5cf84270$@apache.org> <1248462510.1814413.1487873137869.JavaMail.zimbra@u-pem.fr> <047101d28e01$0118a6f0$0349f4d0$@apache.org> Message-ID: <655086303.1842411.1487885495930.JavaMail.zimbra@u-pem.fr> Hi Uwe, I've not the definitive answer, but you can create a MethodHandle on ByteBuffer::get and see a VarHandle as a MethodHandle (with VarHandler.toMethodHandle) so both access can be represented as method handles. R?mi [1] http://download.java.net/java/jdk9/docs/api/java/lang/invoke/VarHandle.html#toMethodHandle-java.lang.invoke.VarHandle.AccessMode- ----- Mail original ----- > De: "Uwe Schindler" > ?: "Remi Forax" , "Vitaly Davidovich" > Cc: "jigsaw-dev" > Envoy?: Jeudi 23 F?vrier 2017 19:16:44 > Objet: RE: sun.nio.ch.DirectBuffer and jdk9/jigsaw > Hi, > >> I believe that what you are looking for is >> MethodHandles.byteBufferViewVarHandle [1] that creates a VarHandle that >> allows to do aligned/unaligned access on a ByteBuffer. > > Related question: I wonder why there is now way to get a view on a ByteBuffer as > a byte[]-typed Varhandle (byte[] and boolean[] views are explicitly excluded - > why????)? It throws UnsupportedOperationExeception! To me this is inconsistent. > You can get a Varhandle for byte[] arrays, but not ByteBuffers. I know it > brings not much, but you would have the possibility to have "generic code" for > all types. > > And by looking at the source code, there is no reason to not generate the byte[] > view, in fact it is already available in the generated class for array-views. > > Should I open a feature request? This was something we were stuck when trying to > use VarHandles inside Lucene to access memory mapped files as VarHandles (would > be really cool). But we need a byte[] view, too!!! > > Uwe > >> It should be a little slower that using Unsafe because of the bound check >> (and the nullcheck but it is usually removed by the VM). >> That's said, unaligned access are faster with a VarHandle because >> sun.misc.Unsafe (which is stuck in the Java 8 world unlinke >> jdk.internal.misc.Unsafe) does not provide a way to do an unaligned access >> so you have do multiple read which is slower. >> >> cheers, >> R?mi >> >> http://download.java.net/java/jdk9/docs/api/java/lang/invoke/MethodHan >> dles.html#byteBufferViewVarHandle-java.lang.Class-java.nio.ByteOrder- >> >> ----- Mail original ----- >> > De: "Vitaly Davidovich" >> > ?: "Uwe Schindler" >> > Cc: "jigsaw-dev" >> > Envoy?: Jeudi 23 F?vrier 2017 18:05:36 >> > Objet: Re: sun.nio.ch.DirectBuffer and jdk9/jigsaw >> >> > On Thu, Feb 23, 2017 at 11:54 AM, Uwe Schindler >> >> > wrote: >> > >> >> Hi, >> >> >> >> Why do you need the address at all in the Java code? Java code can use >> the >> >> official ByteBuffer methods to access the memory you are wrapping. In >> Java >> >> 9 that?s optimized very good by Hotspot and should be almost as fast as >> >> array accesses (we proved that in Apache Lucene - congrats to the Hotspot >> >> committers). If you need special access modes like volatile access, then >> >> you can use Java 9's VarHandles. You can get a VarHandle to the backing >> >> direct buffer using the MethodHandles API. >> >> >> > I mentioned this upthread - the base address is used for index calculations >> > to read/write data using Unsafe directly. I don't know about Java 9 as >> > I've not tried it yet, but the generated assembly for using BB methods vs >> > Unsafe did not favor BB. There are also various safety checks in >> > DBB/Buffer internals that won't get optimized away. >> > >> > Also, my general experience with looking at C2 optimizations has led me to >> > the conclusion that the optimizations are "unstable" - innocent code >> > changes, differences in order of how classes are loaded, differences in >> > what callsites trigger compilation first, and a bunch of other otherwise >> > benign things can interfere with inlining decisions, which is typically the >> > reason things go sideways in terms of optimization. >> > >> > As for MethodHandles and VarHandles, that's one possibility I'm >> considering >> > as a way to migrate off using DirectBuffer (although I'd still like to know >> > if there's any plan to standardize/formalize some notion of a direct >> > buffer). However, my understanding is that using MH will still require me >> > to crack into jdk code (to get access to the DBB and friends) and thus >> > require addExports. DirectBuffer is still accessible if using addExports, >> > but it's a wrinkle I was hoping to iron out, hence what started this email >> > chain. >> > >> >> >> >> Uwe >> >> >> >> ----- >> >> Uwe Schindler >> >> uschindler at apache.org >> >> ASF Member, Apache Lucene PMC / Committer >> >> Bremen, Germany >> >> http://lucene.apache.org/ >> >> >> >> > -----Original Message----- >> >> > From: jigsaw-dev [mailto:jigsaw-dev-bounces at openjdk.java.net] On >> Behalf >> >> > Of Vitaly Davidovich >> >> > Sent: Thursday, February 23, 2017 5:30 PM >> >> > To: Chris Hegarty >> >> > Cc: jigsaw-dev >> >> > Subject: Re: sun.nio.ch.DirectBuffer and jdk9/jigsaw >> >> > >> >> > On Thu, Feb 23, 2017 at 11:10 AM, Chris Hegarty >> >> > >> >> > wrote: >> >> > >> >> > > >> >> > > > On 23 Feb 2017, at 11:30, Vitaly Davidovich >> >> wrote: >> >> > > >> ... >> >> > > > The buffers are reused by having them point to different native >> >> memory >> >> > > > block addresses; those blocks are managed by native code. As >> >> > mentioned, >> >> > > > the ByteBuffer (DirectByteBuffer concretely) is used as the Java >> >> level >> >> > > > interface/view of native memory, allowing Java and native code to >> >> > > > communicate. >> >> > > >> >> > > So a DBB, under your code, may report a different address at some >> time >> >> > > in the future, to that of what it currently reports? >> >> > >> >> > Correct. >> >> > >> >> > > I was not aware of this >> >> > > usecase. Is any similar code available on the web, or elsewhere, so we >> >> > > could try to determine why this is being done? >> >> > > >> >> > Unfortunately it's not open source code, and I don't immediately know >> of >> >> > anything similar on the web (or otherwise). However, the gist is the >> >> > following: >> >> > 1) Allocate a 0-size DBB (i.e. ByteBuffer.allocateDirect(0)). This gives >> >> > you a Java "handle", if you will, to some native memory. But, since this >> >> > DBB will be attached/reattached to different memory dynamically, >> there's >> >> no >> >> > need for an actual allocation. >> >> > 2) Native code wants to expose a segment of memory to Java. In JNI, it >> >> > sets the address and capacity of this DBB to the pointer where the native >> >> > memory segment starts, and to the capacity (it knows how big the native >> >> > segment is). Java code asks for this DBB to be "attached" to, say, some >> >> > sort of message, and the JNI/native code perform these functions. >> >> > 3) Java gets the attached DBB back, and can then use its API >> >> > (getXXX/setXXX) to read/write that native block. Once the operation >> >> > completes, the DBB is recycled for reuse (i.e. can be attached to a >> >> > different native segment again). >> >> > >> >> > Obviously, we can use >> >> > >> http://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions >> >> . >> >> > html#GetDirectBufferAddress >> >> > to get the address and then expose that via a JNI helper - in fact, >> >> that's >> >> > what was done before. But, there's a JNI call penalty here for what is >> >> > otherwise a memory read. DirectBuffer::address() solves that nicely, >> and >> >> > also plays well with the C2 JIT (as mentioned) because the callsites >> >> where >> >> > this is used only see DBB, and then the whole invokeinterface call is >> >> > devirtualized and inlined into a quick type check and Java field read - >> >> the >> >> > performance of this is, as you can imagine, significantly better than the >> >> > JNI approach. >> >> > >> >> > If you think of what a DBB really is, it's pretty much what it's name >> >> > suggests - it's an API to read/write to native memory, rather than Java >> >> > heap memory (i.e. HeapByteBuffer). But, there's no reason the native >> >> > memory backing the DBB has to also be allocated via Unsafe itself, >> >> although >> >> > that's the more common scenario. >> >> > >> >> > On the Java side, consumers of this have a common and conventional >> API >> >> > over >> >> > a byte buffer, i.e. ByteBuffer, which can optionally be used in the >> >> manner >> >> > above (obviously callers will need to know what mode they're using). >> >> > >> >> > >> >> > > -Chris. >> >> > > >> >> > > From forax at univ-mlv.fr Thu Feb 23 21:39:07 2017 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 23 Feb 2017 22:39:07 +0100 (CET) Subject: sun.nio.ch.DirectBuffer and jdk9/jigsaw In-Reply-To: References: <1A7655EE-37AF-4C91-B16B-7E81F819E3D0@oracle.com> <045301d28df5$7452c0d0$5cf84270$@apache.org> <1248462510.1814413.1487873137869.JavaMail.zimbra@u-pem.fr> Message-ID: <626108356.1845319.1487885947239.JavaMail.zimbra@u-pem.fr> Hi Vitaly, > De: "Vitaly Davidovich" > ?: "Remi Forax" > Cc: "Uwe Schindler" , "jigsaw-dev" > > Envoy?: Jeudi 23 F?vrier 2017 19:17:57 > Objet: Re: sun.nio.ch.DirectBuffer and jdk9/jigsaw > Hey Remi, [...] > P.S. We've nicely sidetracked a bit from my original question, but I suppose the > between-the-lines answer is that there's no plan to expose some of the guts of > a direct buffer in a supported manner. yes, sun.nio.ch.DirectBuffer is not part of the exported API as you already know. R?mi > On Thu, Feb 23, 2017 at 1:05 PM, Remi Forax < forax at univ-mlv.fr > wrote: >> Hi Vitaly, >> I believe that what you are looking for is MethodHandles.byteBufferViewVarHandle >> [1] that creates a VarHandle that allows to do aligned/unaligned access on a >> ByteBuffer. >> It should be a little slower that using Unsafe because of the bound check (and >> the nullcheck but it is usually removed by the VM). >> That's said, unaligned access are faster with a VarHandle because >> sun.misc.Unsafe (which is stuck in the Java 8 world unlinke >> jdk.internal.misc.Unsafe) does not provide a way to do an unaligned access so >> you have do multiple read which is slower. >> cheers, >> R?mi >> http://download.java.net/java/jdk9/docs/api/java/lang/invoke/MethodHandles.html#byteBufferViewVarHandle-java.lang.Class-java.nio.ByteOrder- >> ----- Mail original ----- >> > De: "Vitaly Davidovich" < vitalyd at gmail.com > >> > ?: "Uwe Schindler" < uschindler at apache.org > >> > Cc: "jigsaw-dev" < jigsaw-dev at openjdk.java.net > >> > Envoy?: Jeudi 23 F?vrier 2017 18:05:36 >> > Objet: Re: sun.nio.ch.DirectBuffer and jdk9/jigsaw >> > On Thu, Feb 23, 2017 at 11:54 AM, Uwe Schindler < uschindler at apache.org > >> > wrote: >> >> Hi, >> >> Why do you need the address at all in the Java code? Java code can use the >> >> official ByteBuffer methods to access the memory you are wrapping. In Java >> >> 9 that?s optimized very good by Hotspot and should be almost as fast as >> >> array accesses (we proved that in Apache Lucene - congrats to the Hotspot >> >> committers). If you need special access modes like volatile access, then >> >> you can use Java 9's VarHandles. You can get a VarHandle to the backing >> >> direct buffer using the MethodHandles API. >> > I mentioned this upthread - the base address is used for index calculations >> > to read/write data using Unsafe directly. I don't know about Java 9 as >> > I've not tried it yet, but the generated assembly for using BB methods vs >> > Unsafe did not favor BB. There are also various safety checks in >> > DBB/Buffer internals that won't get optimized away. >> > Also, my general experience with looking at C2 optimizations has led me to >> > the conclusion that the optimizations are "unstable" - innocent code >> > changes, differences in order of how classes are loaded, differences in >> > what callsites trigger compilation first, and a bunch of other otherwise >> > benign things can interfere with inlining decisions, which is typically the >> > reason things go sideways in terms of optimization. >> > As for MethodHandles and VarHandles, that's one possibility I'm considering >> > as a way to migrate off using DirectBuffer (although I'd still like to know >> > if there's any plan to standardize/formalize some notion of a direct >> > buffer). However, my understanding is that using MH will still require me >> > to crack into jdk code (to get access to the DBB and friends) and thus >> > require addExports. DirectBuffer is still accessible if using addExports, >> > but it's a wrinkle I was hoping to iron out, hence what started this email >> > chain. >> >> Uwe >> >> ----- >> >> Uwe Schindler >> >> uschindler at apache.org >> >> ASF Member, Apache Lucene PMC / Committer >> >> Bremen, Germany >> >> http://lucene.apache.org/ >> >> > -----Original Message----- >> >> > From: jigsaw-dev [mailto: jigsaw-dev-bounces at openjdk.java.net ] On Behalf >> >> > Of Vitaly Davidovich >> >> > Sent: Thursday, February 23, 2017 5:30 PM >> >> > To: Chris Hegarty < chris.hegarty at oracle.com > >> >> > Cc: jigsaw-dev < jigsaw-dev at openjdk.java.net > >> >> > Subject: Re: sun.nio.ch.DirectBuffer and jdk9/jigsaw >> >> > On Thu, Feb 23, 2017 at 11:10 AM, Chris Hegarty >> >> > < chris.hegarty at oracle.com > >> >> > wrote: >> >> > > > On 23 Feb 2017, at 11:30, Vitaly Davidovich < vitalyd at gmail.com > >> >> wrote: >> >> > > >> ... >> >> > > > The buffers are reused by having them point to different native >> >> memory >> >> > > > block addresses; those blocks are managed by native code. As >> >> > mentioned, >> >> > > > the ByteBuffer (DirectByteBuffer concretely) is used as the Java >> >> level >> >> > > > interface/view of native memory, allowing Java and native code to >> >> > > > communicate. >> >> > > So a DBB, under your code, may report a different address at some time >> >> > > in the future, to that of what it currently reports? >> >> > Correct. >> >> > > I was not aware of this >> >> > > usecase. Is any similar code available on the web, or elsewhere, so we >> >> > > could try to determine why this is being done? >> >> > Unfortunately it's not open source code, and I don't immediately know of >> >> > anything similar on the web (or otherwise). However, the gist is the >> >> > following: >> >> > 1) Allocate a 0-size DBB (i.e. ByteBuffer.allocateDirect(0)). This gives >> >> > you a Java "handle", if you will, to some native memory. But, since this >> >> > DBB will be attached/reattached to different memory dynamically, there's >> >> no >> >> > need for an actual allocation. >> >> > 2) Native code wants to expose a segment of memory to Java. In JNI, it >> >> > sets the address and capacity of this DBB to the pointer where the native >> >> > memory segment starts, and to the capacity (it knows how big the native >> >> > segment is). Java code asks for this DBB to be "attached" to, say, some >> >> > sort of message, and the JNI/native code perform these functions. >> >> > 3) Java gets the attached DBB back, and can then use its API >> >> > (getXXX/setXXX) to read/write that native block. Once the operation >> >> > completes, the DBB is recycled for reuse (i.e. can be attached to a >> >> > different native segment again). >> >> > Obviously, we can use >> >> > http://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions >> >> . >> >> > html#GetDirectBufferAddress >> >> > to get the address and then expose that via a JNI helper - in fact, >> >> that's >> >> > what was done before. But, there's a JNI call penalty here for what is >> >> > otherwise a memory read. DirectBuffer::address() solves that nicely, and >> >> > also plays well with the C2 JIT (as mentioned) because the callsites >> >> where >> >> > this is used only see DBB, and then the whole invokeinterface call is >> >> > devirtualized and inlined into a quick type check and Java field read - >> >> the >> >> > performance of this is, as you can imagine, significantly better than the >> >> > JNI approach. >> >> > If you think of what a DBB really is, it's pretty much what it's name >> >> > suggests - it's an API to read/write to native memory, rather than Java >> >> > heap memory (i.e. HeapByteBuffer). But, there's no reason the native >> >> > memory backing the DBB has to also be allocated via Unsafe itself, >> >> although >> >> > that's the more common scenario. >> >> > On the Java side, consumers of this have a common and conventional API >> >> > over >> >> > a byte buffer, i.e. ByteBuffer, which can optionally be used in the >> >> manner >> >> > above (obviously callers will need to know what mode they're using). >> >> > > -Chris. From uschindler at apache.org Thu Feb 23 21:39:16 2017 From: uschindler at apache.org (Uwe Schindler) Date: Thu, 23 Feb 2017 21:39:16 +0000 Subject: sun.nio.ch.DirectBuffer and jdk9/jigsaw In-Reply-To: <655086303.1842411.1487885495930.JavaMail.zimbra@u-pem.fr> References: <1A7655EE-37AF-4C91-B16B-7E81F819E3D0@oracle.com> <045301d28df5$7452c0d0$5cf84270$@apache.org> <1248462510.1814413.1487873137869.JavaMail.zimbra@u-pem.fr> <047101d28e01$0118a6f0$0349f4d0$@apache.org> <655086303.1842411.1487885495930.JavaMail.zimbra@u-pem.fr> Message-ID: <6A026BE4-2D05-4900-A70A-D2E10FA840FB@apache.org> Thanks Remi. Of course that would work, but the goal was to try VarHandles as generic way to access on-heap and off-heap structures. Maybe Paul Sandoz has an answer to this API inconsistency. Uwe Am 23. Februar 2017 22:31:35 MEZ schrieb forax at univ-mlv.fr: >Hi Uwe, >I've not the definitive answer, but you can create a MethodHandle on >ByteBuffer::get and see a VarHandle as a MethodHandle (with >VarHandler.toMethodHandle) so both access can be represented as method >handles. > >R?mi > >[1] >http://download.java.net/java/jdk9/docs/api/java/lang/invoke/VarHandle.html#toMethodHandle-java.lang.invoke.VarHandle.AccessMode- > >----- Mail original ----- >> De: "Uwe Schindler" >> ?: "Remi Forax" , "Vitaly Davidovich" > >> Cc: "jigsaw-dev" >> Envoy?: Jeudi 23 F?vrier 2017 19:16:44 >> Objet: RE: sun.nio.ch.DirectBuffer and jdk9/jigsaw > >> Hi, >> >>> I believe that what you are looking for is >>> MethodHandles.byteBufferViewVarHandle [1] that creates a VarHandle >that >>> allows to do aligned/unaligned access on a ByteBuffer. >> >> Related question: I wonder why there is now way to get a view on a >ByteBuffer as >> a byte[]-typed Varhandle (byte[] and boolean[] views are explicitly >excluded - >> why????)? It throws UnsupportedOperationExeception! To me this is >inconsistent. >> You can get a Varhandle for byte[] arrays, but not ByteBuffers. I >know it >> brings not much, but you would have the possibility to have "generic >code" for >> all types. >> >> And by looking at the source code, there is no reason to not generate >the byte[] >> view, in fact it is already available in the generated class for >array-views. >> >> Should I open a feature request? This was something we were stuck >when trying to >> use VarHandles inside Lucene to access memory mapped files as >VarHandles (would >> be really cool). But we need a byte[] view, too!!! >> >> Uwe >> >>> It should be a little slower that using Unsafe because of the bound >check >>> (and the nullcheck but it is usually removed by the VM). >>> That's said, unaligned access are faster with a VarHandle because >>> sun.misc.Unsafe (which is stuck in the Java 8 world unlinke >>> jdk.internal.misc.Unsafe) does not provide a way to do an unaligned >access >>> so you have do multiple read which is slower. >>> >>> cheers, >>> R?mi >>> >>> >http://download.java.net/java/jdk9/docs/api/java/lang/invoke/MethodHan >>> >dles.html#byteBufferViewVarHandle-java.lang.Class-java.nio.ByteOrder- >>> >>> ----- Mail original ----- >>> > De: "Vitaly Davidovich" >>> > ?: "Uwe Schindler" >>> > Cc: "jigsaw-dev" >>> > Envoy?: Jeudi 23 F?vrier 2017 18:05:36 >>> > Objet: Re: sun.nio.ch.DirectBuffer and jdk9/jigsaw >>> >>> > On Thu, Feb 23, 2017 at 11:54 AM, Uwe Schindler >>> >>> > wrote: >>> > >>> >> Hi, >>> >> >>> >> Why do you need the address at all in the Java code? Java code >can use >>> the >>> >> official ByteBuffer methods to access the memory you are >wrapping. In >>> Java >>> >> 9 that?s optimized very good by Hotspot and should be almost as >fast as >>> >> array accesses (we proved that in Apache Lucene - congrats to the >Hotspot >>> >> committers). If you need special access modes like volatile >access, then >>> >> you can use Java 9's VarHandles. You can get a VarHandle to the >backing >>> >> direct buffer using the MethodHandles API. >>> >> >>> > I mentioned this upthread - the base address is used for index >calculations >>> > to read/write data using Unsafe directly. I don't know about Java >9 as >>> > I've not tried it yet, but the generated assembly for using BB >methods vs >>> > Unsafe did not favor BB. There are also various safety checks in >>> > DBB/Buffer internals that won't get optimized away. >>> > >>> > Also, my general experience with looking at C2 optimizations has >led me to >>> > the conclusion that the optimizations are "unstable" - innocent >code >>> > changes, differences in order of how classes are loaded, >differences in >>> > what callsites trigger compilation first, and a bunch of other >otherwise >>> > benign things can interfere with inlining decisions, which is >typically the >>> > reason things go sideways in terms of optimization. >>> > >>> > As for MethodHandles and VarHandles, that's one possibility I'm >>> considering >>> > as a way to migrate off using DirectBuffer (although I'd still >like to know >>> > if there's any plan to standardize/formalize some notion of a >direct >>> > buffer). However, my understanding is that using MH will still >require me >>> > to crack into jdk code (to get access to the DBB and friends) and >thus >>> > require addExports. DirectBuffer is still accessible if using >addExports, >>> > but it's a wrinkle I was hoping to iron out, hence what started >this email >>> > chain. >>> > >>> >> >>> >> Uwe >>> >> >>> >> ----- >>> >> Uwe Schindler >>> >> uschindler at apache.org >>> >> ASF Member, Apache Lucene PMC / Committer >>> >> Bremen, Germany >>> >> http://lucene.apache.org/ >>> >> >>> >> > -----Original Message----- >>> >> > From: jigsaw-dev [mailto:jigsaw-dev-bounces at openjdk.java.net] >On >>> Behalf >>> >> > Of Vitaly Davidovich >>> >> > Sent: Thursday, February 23, 2017 5:30 PM >>> >> > To: Chris Hegarty >>> >> > Cc: jigsaw-dev >>> >> > Subject: Re: sun.nio.ch.DirectBuffer and jdk9/jigsaw >>> >> > >>> >> > On Thu, Feb 23, 2017 at 11:10 AM, Chris Hegarty >>> >> > >>> >> > wrote: >>> >> > >>> >> > > >>> >> > > > On 23 Feb 2017, at 11:30, Vitaly Davidovich > >>> >> wrote: >>> >> > > >> ... >>> >> > > > The buffers are reused by having them point to different >native >>> >> memory >>> >> > > > block addresses; those blocks are managed by native code. >As >>> >> > mentioned, >>> >> > > > the ByteBuffer (DirectByteBuffer concretely) is used as the >Java >>> >> level >>> >> > > > interface/view of native memory, allowing Java and native >code to >>> >> > > > communicate. >>> >> > > >>> >> > > So a DBB, under your code, may report a different address at >some >>> time >>> >> > > in the future, to that of what it currently reports? >>> >> > >>> >> > Correct. >>> >> > >>> >> > > I was not aware of this >>> >> > > usecase. Is any similar code available on the web, or >elsewhere, so we >>> >> > > could try to determine why this is being done? >>> >> > > >>> >> > Unfortunately it's not open source code, and I don't >immediately know >>> of >>> >> > anything similar on the web (or otherwise). However, the gist >is the >>> >> > following: >>> >> > 1) Allocate a 0-size DBB (i.e. ByteBuffer.allocateDirect(0)). >This gives >>> >> > you a Java "handle", if you will, to some native memory. But, >since this >>> >> > DBB will be attached/reattached to different memory >dynamically, >>> there's >>> >> no >>> >> > need for an actual allocation. >>> >> > 2) Native code wants to expose a segment of memory to Java. In >JNI, it >>> >> > sets the address and capacity of this DBB to the pointer where >the native >>> >> > memory segment starts, and to the capacity (it knows how big >the native >>> >> > segment is). Java code asks for this DBB to be "attached" to, >say, some >>> >> > sort of message, and the JNI/native code perform these >functions. >>> >> > 3) Java gets the attached DBB back, and can then use its API >>> >> > (getXXX/setXXX) to read/write that native block. Once the >operation >>> >> > completes, the DBB is recycled for reuse (i.e. can be attached >to a >>> >> > different native segment again). >>> >> > >>> >> > Obviously, we can use >>> >> > >>> >http://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions >>> >> . >>> >> > html#GetDirectBufferAddress >>> >> > to get the address and then expose that via a JNI helper - in >fact, >>> >> that's >>> >> > what was done before. But, there's a JNI call penalty here for >what is >>> >> > otherwise a memory read. DirectBuffer::address() solves that >nicely, >>> and >>> >> > also plays well with the C2 JIT (as mentioned) because the >callsites >>> >> where >>> >> > this is used only see DBB, and then the whole invokeinterface >call is >>> >> > devirtualized and inlined into a quick type check and Java >field read - >>> >> the >>> >> > performance of this is, as you can imagine, significantly >better than the >>> >> > JNI approach. >>> >> > >>> >> > If you think of what a DBB really is, it's pretty much what >it's name >>> >> > suggests - it's an API to read/write to native memory, rather >than Java >>> >> > heap memory (i.e. HeapByteBuffer). But, there's no reason the >native >>> >> > memory backing the DBB has to also be allocated via Unsafe >itself, >>> >> although >>> >> > that's the more common scenario. >>> >> > >>> >> > On the Java side, consumers of this have a common and >conventional >>> API >>> >> > over >>> >> > a byte buffer, i.e. ByteBuffer, which can optionally be used in >the >>> >> manner >>> >> > above (obviously callers will need to know what mode they're >using). >>> >> > >>> >> > >>> >> > > -Chris. >>> >> > > >>> >> > > From claes.redestad at oracle.com Thu Feb 23 22:57:36 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 23 Feb 2017 23:57:36 +0100 Subject: RFR: 8175561: Memory churn in jimage code affects startup after resource encapsulation changes Message-ID: <369c4d61-32d8-ae8d-6f88-45f6bde3ff37@oracle.com> Hi, various resource encapsulation changes in 9+148 meant an uptick in footprint and startup times for certain applications. While some of this regression is hard to avoid[1] (opening readers, touching more memory mapped pages etc), a large part is due to simple java allocation churn, some of which can be optimized away by reducing the number of objects we create when scanning modules for resources. Bug: https://bugs.openjdk.java.net/browse/JDK-8175561 Webrev: http://cr.openjdk.java.net/~redestad/8175561/jdk.01/ Thanks! /Claes [1] Things we could do in the future to improve further include adding an index to the jimage (too late for 9) or marking modules with no non-encapsulated resources as such so that they can be skipped. From paul.sandoz at oracle.com Thu Feb 23 23:18:49 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 23 Feb 2017 15:18:49 -0800 Subject: sun.nio.ch.DirectBuffer and jdk9/jigsaw In-Reply-To: <6A026BE4-2D05-4900-A70A-D2E10FA840FB@apache.org> References: <1A7655EE-37AF-4C91-B16B-7E81F819E3D0@oracle.com> <045301d28df5$7452c0d0$5cf84270$@apache.org> <1248462510.1814413.1487873137869.JavaMail.zimbra@u-pem.fr> <047101d28e01$0118a6f0$0349f4d0$@apache.org> <655086303.1842411.1487885495930.JavaMail.zimbra@u-pem.fr> <6A026BE4-2D05-4900-A70A-D2E10FA840FB@apache.org> Message-ID: > On 23 Feb 2017, at 13:39, Uwe Schindler wrote: > > Thanks Remi. > > Of course that would work, but the goal was to try VarHandles as generic way to access on-heap and off-heap structures. Maybe Paul Sandoz has an answer to this API inconsistency. > It?s just that, an inconsistency, something i did not focus on w.r.t. use-cases, same for expanding the types supported for aligned atomic access, since we added field/array support for those quite late in the process and it?s a pain to deal with big/little endian cases read-modify-write ops (such as getAndAdd). In effect the following VarHandles would then provide equivalent access functionality: VarHandle v1 = MethodHandles.arrayElementVarHandle(byte[].class); VarHandle v2 = MethodHandles.byteArrayViewVarHandle(byte[].class, ByteOrder.BIG_ENDIAN); VarHandle v3 = MethodHandles.byteBufferViewVarHandle(byte[].class, ByteOrder.LITTLE_ENDIAN); // Where for v3 a ByteBuffer instance is a heap buffer wrapping a byte[] array We can certainly do this for 10. Paul. > Uwe > > Am 23. Februar 2017 22:31:35 MEZ schrieb forax at univ-mlv.fr: > Hi Uwe, > I've not the definitive answer, but you can create a MethodHandle on ByteBuffer::get and see a VarHandle as a MethodHandle (with VarHandler.toMethodHandle) so both access can be represented as method handles. > > R?mi > From claes.redestad at oracle.com Thu Feb 23 23:19:13 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 24 Feb 2017 00:19:13 +0100 Subject: RFR: 8175385: ServiceLoader$LazyClassPathLookupIterator scans boot and platform modules for services Message-ID: <5e0c670d-7e91-ea6b-ab2a-3ffc6b0c94c1@oracle.com> Hi, related to the same regression as JDK-8175561, there are now some cases where we unnecessarily scan platform modules for services. This patch allows us to skip the platform and boot classloaders in certain cases, which speeds up loading and enumerating the built-in services. Bug: https://bugs.openjdk.java.net/browse/JDK-8175561 Webrev: http://cr.openjdk.java.net/~redestad/8175385/jdk.01/ Thanks! /Claes From james.laskey at oracle.com Thu Feb 23 23:25:05 2017 From: james.laskey at oracle.com (James Laskey) Date: Thu, 23 Feb 2017 19:25:05 -0400 Subject: RFR: 8175561: Memory churn in jimage code affects startup after resource encapsulation changes In-Reply-To: <369c4d61-32d8-ae8d-6f88-45f6bde3ff37@oracle.com> References: <369c4d61-32d8-ae8d-6f88-45f6bde3ff37@oracle.com> Message-ID: <47EC2DE7-105A-454D-B091-8041327EDBBB@oracle.com> +1 Sent from my iPhone > On Feb 23, 2017, at 6:57 PM, Claes Redestad wrote: > > Hi, > > various resource encapsulation changes in 9+148 meant an uptick in > footprint and startup times for certain applications. > > While some of this regression is hard to avoid[1] (opening readers, > touching more memory mapped pages etc), a large part is due to simple > java allocation churn, some of which can be optimized away by reducing > the number of objects we create when scanning modules for resources. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8175561 > Webrev: http://cr.openjdk.java.net/~redestad/8175561/jdk.01/ > > Thanks! > > /Claes > > [1] Things we could do in the future to improve further include adding > an index to the jimage (too late for 9) or marking modules with no non-encapsulated resources as such so that they can be skipped. From mandy.chung at oracle.com Thu Feb 23 23:47:35 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 23 Feb 2017 15:47:35 -0800 Subject: Review Request: JDK-8175193: jlink and `requires static` Message-ID: This patch fixes jlink to link modules that has `requires static M`. jlink does not modify module-info.class. Hence, at runtime if module M is on the module path and added in the resolved graph. `requires static` dependency will be satisfied. Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175193/webrev.00/index.html Mandy From forax at univ-mlv.fr Fri Feb 24 00:32:09 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 24 Feb 2017 01:32:09 +0100 (CET) Subject: Review Request: JDK-8175193: jlink and `requires static` In-Reply-To: References: Message-ID: <1094698757.1857907.1487896329162.JavaMail.zimbra@u-pem.fr> Hi Mandy, I prefer that semantics. In the code, you can remove the ".stream()". regards, R?mi ----- Mail original ----- > De: "Mandy Chung" > ?: "jigsaw-dev" > Envoy?: Vendredi 24 F?vrier 2017 00:47:35 > Objet: Review Request: JDK-8175193: jlink and `requires static` > This patch fixes jlink to link modules that has `requires static M`. > jlink does not modify module-info.class. Hence, at runtime if > module M is on the module path and added in the resolved graph. > `requires static` dependency will be satisfied. > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175193/webrev.00/index.html > > Mandy From mandy.chung at oracle.com Fri Feb 24 00:34:58 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 23 Feb 2017 16:34:58 -0800 Subject: Review Request: JDK-8175193: jlink and `requires static` In-Reply-To: <1094698757.1857907.1487896329162.JavaMail.zimbra@u-pem.fr> References: <1094698757.1857907.1487896329162.JavaMail.zimbra@u-pem.fr> Message-ID: > On Feb 23, 2017, at 4:32 PM, Remi Forax wrote: > > Hi Mandy, > I prefer that semantics. > > In the code, you can remove the ".stream()?. Good catch. I will remove it before I push. Mandy > regards, > R?mi > > ----- Mail original ----- >> De: "Mandy Chung" >> ?: "jigsaw-dev" >> Envoy?: Vendredi 24 F?vrier 2017 00:47:35 >> Objet: Review Request: JDK-8175193: jlink and `requires static` > >> This patch fixes jlink to link modules that has `requires static M`. >> jlink does not modify module-info.class. Hence, at runtime if >> module M is on the module path and added in the resolved graph. >> `requires static` dependency will be satisfied. >> >> Webrev: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175193/webrev.00/index.html >> >> Mandy From mandy.chung at oracle.com Fri Feb 24 00:53:53 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 23 Feb 2017 16:53:53 -0800 Subject: RFR: 8175385: ServiceLoader$LazyClassPathLookupIterator scans boot and platform modules for services In-Reply-To: <5e0c670d-7e91-ea6b-ab2a-3ffc6b0c94c1@oracle.com> References: <5e0c670d-7e91-ea6b-ab2a-3ffc6b0c94c1@oracle.com> Message-ID: > On Feb 23, 2017, at 3:19 PM, Claes Redestad wrote: > > Hi, > > related to the same regression as JDK-8175561, there are now some cases > where we unnecessarily scan platform modules for services. This patch > allows us to skip the platform and boot classloaders in certain cases, > which speeds up loading and enumerating the built-in services. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8175561 > Webrev: http://cr.openjdk.java.net/~redestad/8175385/jdk.01/ Looks good to me. Mandy From sundararajan.athijegannathan at oracle.com Fri Feb 24 06:25:19 2017 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Fri, 24 Feb 2017 06:25:19 +0000 Subject: hg: jigsaw/jake/jdk: jlink changes for osName, osArch and osVersion Message-ID: <201702240625.v1O6PJqh018239@aojmv0008.oracle.com> Changeset: ff56667231e2 Author: sundar Date: 2017-02-24 12:10 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ff56667231e2 jlink changes for osName, osArch and osVersion ! src/java.base/share/classes/jdk/internal/module/ClassFileAttributes.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/builder/DefaultImageBuilder.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginStack.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ResourcePoolManager.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ReleaseInfoPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/ResourcePoolModule.java ! test/tools/jlink/IntegrationTest.java ! test/tools/jlink/plugins/SystemModuleDescriptors/CompiledVersionTest.java ! test/tools/jlink/plugins/SystemModuleDescriptors/SystemModulesTest.java ! test/tools/jlink/plugins/SystemModuleDescriptors/UserModuleTest.java ! test/tools/jlink/plugins/SystemModuleDescriptors/src/m1/p1/Main.java ! test/tools/jlink/plugins/SystemModuleDescriptors/src/m4/p4/Main.java From sundararajan.athijegannathan at oracle.com Fri Feb 24 06:26:42 2017 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Fri, 24 Feb 2017 06:26:42 +0000 Subject: hg: jigsaw/jake/jdk: jlink changes for osName, osArch and osVersion. Missed a new test library source. Message-ID: <201702240626.v1O6QgrN018525@aojmv0008.oracle.com> Changeset: 70ecebe1b74f Author: sundar Date: 2017-02-24 12:11 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/70ecebe1b74f jlink changes for osName, osArch and osVersion. Missed a new test library source. + test/lib/testlibrary/ModuleTargetHelper.java From sundararajan.athijegannathan at oracle.com Fri Feb 24 06:29:51 2017 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Fri, 24 Feb 2017 06:29:51 +0000 Subject: hg: jigsaw/jake: jlink OS_VERSION release property generated from makefile Message-ID: <201702240629.v1O6Tpsn018957@aojmv0008.oracle.com> Changeset: 3086b2a9f5d4 Author: sundar Date: 2017-02-24 12:14 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/3086b2a9f5d4 jlink OS_VERSION release property generated from makefile ! make/Images.gmk From Alan.Bateman at oracle.com Fri Feb 24 08:50:12 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 24 Feb 2017 08:50:12 +0000 Subject: RFR: 8175385: ServiceLoader$LazyClassPathLookupIterator scans boot and platform modules for services In-Reply-To: <5e0c670d-7e91-ea6b-ab2a-3ffc6b0c94c1@oracle.com> References: <5e0c670d-7e91-ea6b-ab2a-3ffc6b0c94c1@oracle.com> Message-ID: <5dde79d7-9e67-941f-a8aa-75f93b9987c0@oracle.com> On 23/02/2017 23:19, Claes Redestad wrote: > Hi, > > related to the same regression as JDK-8175561, there are now some cases > where we unnecessarily scan platform modules for services. This patch > allows us to skip the platform and boot classloaders in certain cases, > which speeds up loading and enumerating the built-in services. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8175561 > Webrev: http://cr.openjdk.java.net/~redestad/8175385/jdk.01/ Looks good. A minor nit is to move BootLoader hasClassPath() so it's co-located with the other public static methods. -Alan From Alan.Bateman at oracle.com Fri Feb 24 09:10:16 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 24 Feb 2017 09:10:16 +0000 Subject: Review Request: JDK-8175193: jlink and `requires static` In-Reply-To: References: <1094698757.1857907.1487896329162.JavaMail.zimbra@u-pem.fr> Message-ID: On 24/02/2017 00:34, Mandy Chung wrote: >> On Feb 23, 2017, at 4:32 PM, Remi Forax wrote: >> >> Hi Mandy, >> I prefer that semantics. >> >> In the code, you can remove the ".stream()?. > Good catch. I will remove it before I push. > > Looks okay to me too. -Alan From alan.bateman at oracle.com Fri Feb 24 11:08:13 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 24 Feb 2017 11:08:13 +0000 Subject: hg: jigsaw/jake/jaxp: 8 new changesets Message-ID: <201702241108.v1OB8E62027659@aojmv0008.oracle.com> Changeset: 5621e47022e5 Author: joehw Date: 2017-02-14 10:28 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/5621e47022e5 8169450: StAX parse error if there is a newline in xml declaration Reviewed-by: clanger, dfuchs, lancea ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLDocumentScannerImpl.java + test/javax/xml/jaxp/unittest/parsers/BaseParsingTest.java Changeset: f329c1a1a1ea Author: fyuan Date: 2017-02-15 11:43 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/f329c1a1a1ea 8174025: Regression in XML Transform caused by JDK-8087303 Reviewed-by: joehw, dfuchs ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/ToStream.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/dom3/DOM3TreeWalker.java ! test/javax/xml/jaxp/unittest/common/prettyprint/PrettyPrintTest.java + test/javax/xml/jaxp/unittest/common/prettyprint/generate-catalog.xsl ! test/javax/xml/jaxp/unittest/common/prettyprint/htmltest1.xml + test/javax/xml/jaxp/unittest/common/prettyprint/htmltest7.out + test/javax/xml/jaxp/unittest/common/prettyprint/htmltest7.xml ! test/javax/xml/jaxp/unittest/common/prettyprint/nodetest2.out + test/javax/xml/jaxp/unittest/common/prettyprint/nodetest2ls.out + test/javax/xml/jaxp/unittest/common/prettyprint/simple-entity-resolver-config-transformed.xml + test/javax/xml/jaxp/unittest/common/prettyprint/simple-entity-resolver-config.xml - test/javax/xml/jaxp/unittest/common/prettyprint/xmltest5.out + test/javax/xml/jaxp/unittest/common/prettyprint/xmltest5ls.out + test/javax/xml/jaxp/unittest/common/prettyprint/xmltest5xslt.out - test/javax/xml/jaxp/unittest/common/prettyprint/xmltest7.out + test/javax/xml/jaxp/unittest/common/prettyprint/xmltest7ls.out + test/javax/xml/jaxp/unittest/common/prettyprint/xmltest7xslt.out ! test/javax/xml/jaxp/unittest/common/prettyprint/xmltest8.out ! test/javax/xml/jaxp/unittest/common/prettyprint/xmltest8.xml ! test/javax/xml/jaxp/unittest/dom/ls/LSSerializerTest.java Changeset: 7d070d3e794b Author: aefimov Date: 2017-02-16 04:11 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/7d070d3e794b 8173390: Investigate SymbolTable in SAXParser Reviewed-by: dfuchs, joehw ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/XML11Configuration.java + test/javax/xml/jaxp/unittest/sax/SymbolTableResetTest.java Changeset: 97698c9cd095 Author: aefimov Date: 2017-02-16 13:19 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/97698c9cd095 8174735: Update JAX-WS RI integration to latest version Reviewed-by: alanb, mchung, lancea Contributed-by: roman.grigoriadi at oracle.com ! src/java.xml/share/classes/module-info.java Changeset: 83b9302a43f9 Author: fyuan Date: 2017-02-16 21:39 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/83b9302a43f9 8175043: Multiple jaxp tests failing across platforms Reviewed-by: weijun, joehw ! test/javax/xml/jaxp/functional/org/w3c/dom/ptests/NodeTest.java ! test/javax/xml/jaxp/functional/test/astro/DocumentLSTest.java ! test/javax/xml/jaxp/unittest/parsers/Bug6341770.java ! test/javax/xml/jaxp/unittest/sax/Bug7057778Test.java ! test/javax/xml/jaxp/unittest/stream/Bug6688002Test.java ! test/javax/xml/jaxp/unittest/stream/XMLEventWriterTest/ReaderToWriterTest.java ! test/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/WriterTest.java ! test/javax/xml/jaxp/unittest/transform/Bug4693341Test.java ! test/javax/xml/jaxp/unittest/transform/Bug4892774.java ! test/javax/xml/jaxp/unittest/transform/Bug6216226Test.java ! test/javax/xml/jaxp/unittest/transform/CR6935697Test.java ! test/javax/xml/jaxp/unittest/transform/XSLTFunctionsTest.java ! test/javax/xml/jaxp/unittest/transform/util/TransformerUtil.java ! test/javax/xml/jaxp/unittest/validation/CR6708840Test.java ! test/javax/xml/jaxp/unittest/validation/ValidatorTest.java Changeset: 60e670a65e07 Author: lana Date: 2017-02-16 18:28 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/60e670a65e07 Merge - test/javax/xml/jaxp/unittest/common/prettyprint/xmltest5.out - test/javax/xml/jaxp/unittest/common/prettyprint/xmltest7.out Changeset: bee6f114a47a Author: lana Date: 2017-02-23 16:21 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/bee6f114a47a Added tag jdk-9+158 for changeset 60e670a65e07 ! .hgtags Changeset: 1ed81018fce2 Author: alanb Date: 2017-02-24 11:07 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/1ed81018fce2 Merge ! .hgtags ! src/java.xml/share/classes/module-info.java - test/javax/xml/jaxp/unittest/common/prettyprint/xmltest5.out - test/javax/xml/jaxp/unittest/common/prettyprint/xmltest7.out From alan.bateman at oracle.com Fri Feb 24 11:08:15 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 24 Feb 2017 11:08:15 +0000 Subject: hg: jigsaw/jake/hotspot: 2 new changesets Message-ID: <201702241108.v1OB8F59027731@aojmv0008.oracle.com> Changeset: 750ef08b1278 Author: lana Date: 2017-02-23 16:21 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/750ef08b1278 Added tag jdk-9+158 for changeset 4e78f3093522 ! .hgtags Changeset: ae7703cdbb50 Author: alanb Date: 2017-02-24 11:07 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ae7703cdbb50 Merge ! .hgtags From alan.bateman at oracle.com Fri Feb 24 11:08:14 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 24 Feb 2017 11:08:14 +0000 Subject: hg: jigsaw/jake/corba: 2 new changesets Message-ID: <201702241108.v1OB8EIY027672@aojmv0008.oracle.com> Changeset: 6feea77d2083 Author: lana Date: 2017-02-23 16:21 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/6feea77d2083 Added tag jdk-9+158 for changeset de6bdf38935f ! .hgtags Changeset: 6045b4585af9 Author: alanb Date: 2017-02-24 11:07 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/6045b4585af9 Merge ! .hgtags From alan.bateman at oracle.com Fri Feb 24 11:08:16 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 24 Feb 2017 11:08:16 +0000 Subject: hg: jigsaw/jake: 9 new changesets Message-ID: <201702241108.v1OB8GWw027734@aojmv0008.oracle.com> Changeset: 04a685edd41d Author: darcy Date: 2017-02-14 09:00 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/04a685edd41d 8174945: Turn on doclint reference checking in build of java.compiler module Reviewed-by: erikj ! make/CompileJavaModules.gmk Changeset: 15a37edc6717 Author: sherman Date: 2017-02-15 12:11 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/15a37edc6717 8173207: Upgrade compression library Reviewed-by: alanb, erikj ! common/bin/unshuffle_list.txt ! common/nb_native/nbproject/configurations.xml Changeset: acad65b6e3ee Author: darcy Date: 2017-02-15 13:43 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/acad65b6e3ee 8175045: Turn on doclint reference checking in build of the java.management.rmi module Reviewed-by: lancea, mchung ! make/CompileJavaModules.gmk Changeset: 5a8a2aa4d40a Author: erikj Date: 2017-02-16 09:04 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/5a8a2aa4d40a 8174895: test/TestCommon.gmk: value of JTREG_TESTVM_MEMORY_OPTION is missing Reviewed-by: dholmes, ihse ! test/TestCommon.gmk Changeset: 42d0b3eec016 Author: chegar Date: 2017-02-16 13:10 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/42d0b3eec016 8175071: Minor cleanup in Javadoc.gmk Reviewed-by: erikj, ihse ! make/Javadoc.gmk Changeset: ecb22730b4df Author: lana Date: 2017-02-16 18:27 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/ecb22730b4df Merge Changeset: a4087bc10a88 Author: redestad Date: 2017-02-17 18:12 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/a4087bc10a88 8175026: Capture build-time parameters to --generate-jli-classes Reviewed-by: mchung, ihse ! make/GenerateLinkOptData.gmk ! make/Images.gmk ! make/Main.gmk Changeset: 281d20ee4076 Author: lana Date: 2017-02-23 16:21 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/281d20ee4076 Added tag jdk-9+158 for changeset a4087bc10a88 ! .hgtags Changeset: 8c79dde5671e Author: alanb Date: 2017-02-24 11:07 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/8c79dde5671e Merge ! .hgtags ! make/CompileJavaModules.gmk ! make/Images.gmk ! make/Javadoc.gmk ! make/Main.gmk From alan.bateman at oracle.com Fri Feb 24 11:08:16 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 24 Feb 2017 11:08:16 +0000 Subject: hg: jigsaw/jake/jaxws: 4 new changesets Message-ID: <201702241108.v1OB8GT1027735@aojmv0008.oracle.com> Changeset: 311b931e5485 Author: aefimov Date: 2017-02-16 13:14 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/311b931e5485 8174735: Update JAX-WS RI integration to latest version Reviewed-by: alanb, mchung, lancea Contributed-by: roman.grigoriadi at oracle.com ! src/java.xml.bind/share/classes/com/sun/istack/internal/localization/Localizable.java ! src/java.xml.bind/share/classes/com/sun/istack/internal/localization/LocalizableMessage.java ! src/java.xml.bind/share/classes/com/sun/istack/internal/localization/LocalizableMessageFactory.java ! src/java.xml.bind/share/classes/com/sun/istack/internal/localization/Localizer.java ! src/java.xml.bind/share/classes/com/sun/istack/internal/localization/NullLocalizable.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/api/JAXBRIContext.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/ContextFactory.java + src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/bytecode/package-info.java - src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/bytecode/package.html + src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/model/annotation/package-info.java - src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/model/annotation/package.html ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/model/core/ErrorHandler.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/model/core/PropertyKind.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/model/core/RegistryInfo.java + src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/model/impl/package-info.java - src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/model/impl/package.html + src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/model/nav/package-info.java - src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/model/nav/package.html ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/JAXBContextImpl.java + src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/package-info.java - src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/package.html ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/AccessorInjector.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/Injector.java + src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/package-info.java - src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/package.html + src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/package-info.java - src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/package.html ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/LocatorEx.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/xmlschema/package-info.java - src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/package.html ! src/java.xml.bind/share/classes/javax/xml/bind/ContextFinder.java ! src/java.xml.bind/share/classes/javax/xml/bind/Messages.java ! src/java.xml.bind/share/classes/javax/xml/bind/Messages.properties + src/java.xml.bind/share/classes/javax/xml/bind/annotation/adapters/package-info.java + src/java.xml.bind/share/classes/javax/xml/bind/helpers/package-info.java + src/java.xml.bind/share/classes/javax/xml/bind/package-info.java + src/java.xml.bind/share/classes/javax/xml/bind/util/package-info.java ! src/java.xml.bind/share/classes/module-info.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/LazyEnvelopeSource.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/SOAPExceptionImpl.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/MultipartDataSource.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/BMMimeMultipart.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/ContentDisposition.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/ContentType.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/HeaderTokenizer.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/messaging/saaj/packaging/mime/internet/MimeMultipart.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/MimePartDataSource.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/MimeUtility.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/SharedInputStream.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/util/ASCIIUtility.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/util/BASE64DecoderStream.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/util/BASE64EncoderStream.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/util/BEncoderStream.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/util/LineInputStream.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/util/OutputUtil.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/util/QEncoderStream.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/util/UUEncoderStream.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/Envelope.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/FastInfosetDataContentHandler.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/GifDataContentHandler.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ImageDataContentHandler.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/JpegDataContentHandler.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/LazyEnvelope.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/MessageImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/MultipartDataContentHandler.java - src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPDocumentFragment.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPDocumentImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPPartImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPVersionMismatchException.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/StringDataContentHandler.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/XmlDataContentHandler.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/BodyImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/CDATAImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/DetailImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/ElementFactory.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/ElementImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/EnvelopeImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/FaultElementImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/FaultImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/HeaderImpl.java + src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/NodeListImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/SOAPCommentImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/SOAPTextImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/name/NameImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Body1_1Impl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Detail1_1Impl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Envelope1_1Impl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Fault1_1Impl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Header1_1Impl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Body1_2Impl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Detail1_2Impl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Envelope1_2Impl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Fault1_2Impl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Header1_2Impl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/Base64.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/ByteOutputStream.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/JaxmURI.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/ParseUtil.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/ParserPool.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/SAAJUtil.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/transform/EfficientStreamingTransformer.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/api/message/saaj/SAAJMessageHeaders.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/api/pipe/ThreadHelper.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/api/server/MethodUtil.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/api/server/SDDocumentSource.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/api/streaming/ContextClassloaderLocal.java - src/java.xml.ws/share/classes/com/sun/xml/internal/ws/api/streaming/ContextClassloaderLocal.properties ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/binding/BindingImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/binding/SOAPBindingImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/client/sei/MethodUtil.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/commons/xmlutil/ContextClassloaderLocal.java - src/java.xml.ws/share/classes/com/sun/xml/internal/ws/commons/xmlutil/ContextClassloaderLocal.properties ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/developer/ContextClassloaderLocal.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/model/Injector.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/model/RuntimeModeler.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/model/SOAPSEIModel.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/policy/privateutil/MethodUtil.java + src/java.xml.ws/share/classes/com/sun/xml/internal/ws/policy/util/MethodUtil.java + src/java.xml.ws/share/classes/com/sun/xml/internal/ws/resources/ContextClassloaderLocal.properties + src/java.xml.ws/share/classes/com/sun/xml/internal/ws/resources/ContextClassloaderLocalMessages.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/spi/ContextClassloaderLocal.java - src/java.xml.ws/share/classes/com/sun/xml/internal/ws/spi/ContextClassloaderLocal.properties ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/EndpointImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java + src/java.xml.ws/share/classes/com/sun/xml/internal/ws/util/MethodUtil.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/util/version.properties ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/util/xml/ContextClassloaderLocal.java - src/java.xml.ws/share/classes/com/sun/xml/internal/ws/util/xml/ContextClassloaderLocal.properties + src/java.xml.ws/share/classes/com/sun/xml/internal/ws/util/xml/XmlCatalogUtil.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/util/xml/XmlUtil.java ! src/java.xml.ws/share/classes/javax/xml/soap/FactoryFinder.java ! src/java.xml.ws/share/classes/module-info.java ! src/jdk.xml.bind/share/classes/com/sun/codemodel/internal/JJavaName.java ! src/jdk.xml.bind/share/classes/com/sun/codemodel/internal/JModuleDirective.java ! src/jdk.xml.bind/share/classes/com/sun/codemodel/internal/util/JavadocEscapeWriter.java ! src/jdk.xml.bind/share/classes/com/sun/istack/internal/tools/DefaultAuthenticator.java ! src/jdk.xml.bind/share/classes/com/sun/istack/internal/tools/SecureLoader.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/package-info.java - src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/package.html + src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/CatalogUtil.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle.properties ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle_de.properties ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle_es.properties ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle_fr.properties ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle_it.properties ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle_ja.properties ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle_ko.properties ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle_pt_BR.properties ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle_zh_CN.properties ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle_zh_TW.properties ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/Options.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/SchemaCache.java + src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/impl/s2j/package-info.java - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/impl/s2j/package.html + src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/package-info.java - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/package.html + src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/generator/bean/field/package-info.java - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/generator/bean/field/package.html + src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/model/nav/package-info.java - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/model/nav/package.html + src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/outline/package-info.java - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/outline/package.html + src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/package-info.java - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/package.html + src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/gbind/package-info.java - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/gbind/package.html + src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/internalizer/package-info.java - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/internalizer/package.html + src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/package-info.java - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/package.html ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/package-info.java - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/package.html + src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/runtime/package-info.java - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/runtime/package.html ! src/jdk.xml.bind/share/classes/com/sun/xml/internal/xsom/impl/ElementDecl.java ! src/jdk.xml.bind/share/classes/com/sun/xml/internal/xsom/impl/IdentityConstraintImpl.java ! src/jdk.xml.bind/share/classes/com/sun/xml/internal/xsom/impl/parser/NGCCRuntimeEx.java - src/jdk.xml.bind/share/classes/com/sun/xml/internal/xsom/impl/util/Uri.java + src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/ContextClassloaderLocal.properties + src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/ContextClassloaderLocalMessages.java ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/version.properties ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wscompile/WsgenTool.java ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wscompile/WsimportTool.java ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wsdl/parser/ContextClassloaderLocal.java - src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wsdl/parser/ContextClassloaderLocal.properties Changeset: e53b32235738 Author: lana Date: 2017-02-16 18:28 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/e53b32235738 Merge - src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/bytecode/package.html - src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/model/annotation/package.html - src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/model/impl/package.html - src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/model/nav/package.html - src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/package.html - src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/package.html - src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/package.html - src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/package.html - src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPDocumentFragment.java - src/java.xml.ws/share/classes/com/sun/xml/internal/ws/api/streaming/ContextClassloaderLocal.properties - src/java.xml.ws/share/classes/com/sun/xml/internal/ws/commons/xmlutil/ContextClassloaderLocal.properties - src/java.xml.ws/share/classes/com/sun/xml/internal/ws/spi/ContextClassloaderLocal.properties - src/java.xml.ws/share/classes/com/sun/xml/internal/ws/util/xml/ContextClassloaderLocal.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/package.html - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/impl/s2j/package.html - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/package.html - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/generator/bean/field/package.html - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/model/nav/package.html - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/outline/package.html - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/package.html - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/gbind/package.html - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/internalizer/package.html - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/package.html - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/package.html - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/runtime/package.html - src/jdk.xml.bind/share/classes/com/sun/xml/internal/xsom/impl/util/Uri.java - src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wsdl/parser/ContextClassloaderLocal.properties Changeset: 0ea34706c7fa Author: lana Date: 2017-02-23 16:21 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/0ea34706c7fa Added tag jdk-9+158 for changeset e53b32235738 ! .hgtags Changeset: 0582a058cc23 Author: alanb Date: 2017-02-24 11:07 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/0582a058cc23 Merge ! .hgtags - src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/bytecode/package.html - src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/model/annotation/package.html - src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/model/impl/package.html - src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/model/nav/package.html - src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/package.html - src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/package.html - src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/package.html - src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/package.html ! src/java.xml.bind/share/classes/javax/xml/bind/ContextFinder.java ! src/java.xml.bind/share/classes/module-info.java - src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPDocumentFragment.java - src/java.xml.ws/share/classes/com/sun/xml/internal/ws/api/streaming/ContextClassloaderLocal.properties - src/java.xml.ws/share/classes/com/sun/xml/internal/ws/commons/xmlutil/ContextClassloaderLocal.properties ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/model/RuntimeModeler.java - src/java.xml.ws/share/classes/com/sun/xml/internal/ws/spi/ContextClassloaderLocal.properties - src/java.xml.ws/share/classes/com/sun/xml/internal/ws/util/xml/ContextClassloaderLocal.properties ! src/java.xml.ws/share/classes/javax/xml/soap/FactoryFinder.java ! src/java.xml.ws/share/classes/module-info.java - src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/package.html ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/SchemaCache.java - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/impl/s2j/package.html - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/package.html - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/generator/bean/field/package.html - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/model/nav/package.html - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/outline/package.html - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/package.html - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/gbind/package.html - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/internalizer/package.html - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/package.html - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/package.html - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/runtime/package.html - src/jdk.xml.bind/share/classes/com/sun/xml/internal/xsom/impl/util/Uri.java - src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wsdl/parser/ContextClassloaderLocal.properties From alan.bateman at oracle.com Fri Feb 24 11:08:18 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 24 Feb 2017 11:08:18 +0000 Subject: hg: jigsaw/jake/langtools: 26 new changesets Message-ID: <201702241108.v1OB8IIf027751@aojmv0008.oracle.com> Changeset: 39f31cef8e6a Author: rfield Date: 2017-02-13 08:50 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/39f31cef8e6a 8174797: jshell tool: invalid module path crashes tool 8174796: jshell tool: regression: user home (tilde) not translated Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java ! test/jdk/jshell/ToolBasicTest.java ! test/jdk/jshell/ToolSimpleTest.java Changeset: c73b98b79148 Author: darcy Date: 2017-02-13 10:29 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/c73b98b79148 8173945: Add methods for Elements.getAll{Type, Package, Module}Elements Reviewed-by: jlahoda, jjg ! src/java.compiler/share/classes/javax/lang/model/util/Elements.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/model/JavacElements.java + test/tools/javac/processing/model/util/elements/TestAllFoos.java + test/tools/javac/processing/model/util/elements/modules/m1/module-info.java + test/tools/javac/processing/model/util/elements/modules/m1/pkg/C.java + test/tools/javac/processing/model/util/elements/modules/m1/pkg/package-info.java + test/tools/javac/processing/model/util/elements/modules/m2/module-info.java + test/tools/javac/processing/model/util/elements/modules/m2/pkg/C.java + test/tools/javac/processing/model/util/elements/modules/m2/pkg/package-info.java Changeset: b87052a3056f Author: darcy Date: 2017-02-13 11:51 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/b87052a3056f 8174854: Fix two javax.annotation.processing javadoc link issues Reviewed-by: mchung ! src/java.compiler/share/classes/javax/annotation/processing/AbstractProcessor.java ! src/java.compiler/share/classes/javax/annotation/processing/Processor.java Changeset: ab6d375bab80 Author: rfield Date: 2017-02-13 12:14 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/ab6d375bab80 8174857: jshell tool: /help /set truncation -- confusing indentation Reviewed-by: jjg ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties Changeset: 0837e68b5689 Author: darcy Date: 2017-02-13 12:59 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/0837e68b5689 8174860: Fix bad javadoc link in javax.tools.JavaFileManager Reviewed-by: jjg ! src/java.compiler/share/classes/javax/tools/JavaFileManager.java Changeset: 44e21b2f6370 Author: rfield Date: 2017-02-13 17:04 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/44e21b2f6370 8174862: JShell tests: new JDK-8174797 testInvalidClassPath fails on Windows Reviewed-by: jlahoda ! test/jdk/jshell/ToolSimpleTest.java Changeset: 6967e22a5ddd Author: mli Date: 2017-02-13 18:19 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/6967e22a5ddd 8174695: Fix @since in module-info.java in dev/langtools repo Reviewed-by: mcimadamore ! src/java.compiler/share/classes/module-info.java ! src/jdk.compiler/share/classes/module-info.java ! src/jdk.javadoc/share/classes/module-info.java ! src/jdk.jdeps/share/classes/module-info.java Changeset: 457e4a27daad Author: sadayapalam Date: 2017-02-14 14:24 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/457e4a27daad 8170691: fill in @bug number for test Reviewed-by: darcy ! test/tools/javac/modules/AllDefaultTest.java Changeset: 3cf5dd848c5b Author: anazarov Date: 2017-02-14 16:18 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/3cf5dd848c5b 8170404: Improve negative testing for module-info Reviewed-by: jjg ! test/tools/javac/modules/ModuleInfoTest.java Changeset: ce416299fd2d Author: vromero Date: 2017-02-14 15:45 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/ce416299fd2d 8174243: incorrect error message for nested service provider Reviewed-by: jjg, jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/AttrContext.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/ServiceImplNotPublic/ServiceImplNotPublic.java + test/tools/javac/diags/examples/ServiceImplNotPublic/example/ServiceImpl.java + test/tools/javac/diags/examples/ServiceImplNotPublic/example/SomeService.java + test/tools/javac/diags/examples/ServiceImplNotPublic/module-info.java ! test/tools/javac/modules/ProvidesTest.java + test/tools/javac/modules/WrongErrorMessageForNestedServiceProviderTest.java Changeset: 2815405955ee Author: jlahoda Date: 2017-02-15 11:27 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/2815405955ee 8175007: Incorrect error messages for inaccessible classes in visible packages Summary: Recovery lookup may be triggered for inaccessible classes in visible packages - providing better errors. Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java ! test/tools/javac/modules/ConvenientAccessErrorsTest.java Changeset: 93b50b70ba6c Author: ksrini Date: 2017-02-15 09:50 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/93b50b70ba6c 8174715: Javadoc fails on JDK 7 and JDK 8 sources with StringIndexOutOfBoundsException Reviewed-by: jjg ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! test/com/sun/javadoc/testNonInlineHtmlTagRemoval/C.java + test/com/sun/javadoc/testNonInlineHtmlTagRemoval/Negative.java ! test/com/sun/javadoc/testNonInlineHtmlTagRemoval/TestNonInlineHtmlTagRemoval.java ! test/jdk/javadoc/doclet/testNonInlineHtmlTagRemoval/C.java + test/jdk/javadoc/doclet/testNonInlineHtmlTagRemoval/Negative.java ! test/jdk/javadoc/doclet/testNonInlineHtmlTagRemoval/TestNonInlineHtmlTagRemoval.java Changeset: 9b784c8acd81 Author: ksrini Date: 2017-02-15 11:23 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/9b784c8acd81 8173804: javadoc throws UnsupportedOperationException: should not happen Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java + test/jdk/javadoc/doclet/testMissingType/TestMissingType.java + test/jdk/javadoc/doclet/testMissingType/p/MissingType.java Changeset: 486173bd7be0 Author: jlahoda Date: 2017-02-15 20:31 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/486173bd7be0 8175038: Wrong note about multiple type/package elements being found. Summary: Avoiding quoting by a single '. Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties Changeset: 0ff92d6ce442 Author: bpatel Date: 2017-02-15 11:55 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/0ff92d6ce442 8151743: Header can still disappear behind the navbar Reviewed-by: jjg, ksrini ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/script.js ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css ! test/jdk/javadoc/doclet/testHtmlVersion/TestHtmlVersion.java ! test/jdk/javadoc/doclet/testJavascript/TestJavascript.java ! test/jdk/javadoc/doclet/testNavigation/TestNavigation.java ! test/jdk/javadoc/doclet/testStylesheet/TestStylesheet.java Changeset: ae88ea1b7649 Author: jjg Date: 2017-02-15 14:12 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/ae88ea1b7649 8173596: JavaCompiler.CompilationTask should support addModules Reviewed-by: ksrini, jlahoda ! src/java.compiler/share/classes/javax/tools/DocumentationTool.java ! src/java.compiler/share/classes/javax/tools/JavaCompiler.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/BasicJavacTask.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Main.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/api/JavadocTaskImpl.java + test/jdk/javadoc/tool/api/basic/AddModulesTest.java ! test/tools/javac/modules/AddModulesTest.java Changeset: 8ae5c2d42e17 Author: ksrini Date: 2017-02-15 14:25 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/8ae5c2d42e17 8174839: javadoc crashes with a method which does not override a super. Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/Configuration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/WorkArounds.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java + test/jdk/javadoc/doclet/testOverridenMethods/TestBadOverride.java + test/jdk/javadoc/doclet/testOverridenMethods/pkg4/Foo.java Changeset: 9b2de82e7e49 Author: mchung Date: 2017-02-15 16:18 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/9b2de82e7e49 8173374: Update GenGraphs tool to generate dot graph with requires transitive edges Reviewed-by: dfuchs, redestad ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Graph.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsConfiguration.java ! 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/ModuleDotGraph.java + test/tools/jdeps/modules/DotFileTest.java Changeset: 4a4fd9ecca20 Author: ksrini Date: 2017-02-15 18:07 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/4a4fd9ecca20 8173308: JAVAC_OPTIONS should be updated to align with JAVA_OPTIONS Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/CommandLine.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Main.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties + test/tools/javac/main/EnvVariableTest.java ! test/tools/javac/modules/EnvVarTest.java ! test/tools/javac/modules/InheritRuntimeEnvironmentTest.java Changeset: 1eca2a674d44 Author: jjg Date: 2017-02-15 18:30 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/1eca2a674d44 8175047: javadoc should support --help-extra as a synonym for -X Reviewed-by: ksrini ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ToolOption.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/resources/javadoc.properties ! test/jdk/javadoc/doclet/testXOption/TestXOption.java Changeset: 326d25df2cb7 Author: amlu Date: 2017-02-16 13:38 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/326d25df2cb7 8174059: langtools test failed again on win32 with the trial reversion changes for limited win32 address space Reviewed-by: darcy ! test/tools/javac/lambda/intersection/IntersectionTargetTypeTest.java ! test/tools/javac/tree/JavacTreeScannerTest.java ! test/tools/javac/tree/SourceTreeScannerTest.java ! test/tools/javac/tree/TreePosTest.java ! test/tools/javac/varargs/7043922/T7043922.java Changeset: 525c59180d53 Author: lana Date: 2017-02-16 18:29 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/525c59180d53 Merge Changeset: 890da24e5d30 Author: jjg Date: 2017-02-16 12:49 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/890da24e5d30 8175048: javadoc does not decode options containing '=' and ':' correctly Reviewed-by: ksrini ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ToolOption.java Changeset: 4eb737a8d439 Author: vromero Date: 2017-02-16 14:47 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/4eb737a8d439 8174805: JavacTrees should use Types.skipTypeVars() to get the upper bound of type variables Reviewed-by: jjg, ksrini ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java + test/jdk/javadoc/doclet/testTypeVariableLinks/TestTypeVariableLinks.java + test/jdk/javadoc/doclet/testTypeVariableLinks/pkg1/C.java Changeset: f2bc6963daa7 Author: lana Date: 2017-02-23 16:21 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/f2bc6963daa7 Added tag jdk-9+158 for changeset 4eb737a8d439 ! .hgtags Changeset: 2310f9c69a12 Author: alanb Date: 2017-02-24 11:07 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/2310f9c69a12 Merge ! .hgtags ! src/java.compiler/share/classes/javax/lang/model/util/Elements.java ! src/java.compiler/share/classes/javax/tools/JavaFileManager.java ! src/java.compiler/share/classes/module-info.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/BasicJavacTask.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/AttrContext.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Main.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/model/JavacElements.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/module-info.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.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/script.js ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ToolOption.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/resources/javadoc.properties ! src/jdk.javadoc/share/classes/module-info.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsConfiguration.java ! 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/module-info.java ! test/jdk/javadoc/doclet/testHtmlVersion/TestHtmlVersion.java ! test/jdk/javadoc/doclet/testJavascript/TestJavascript.java ! test/jdk/javadoc/doclet/testNavigation/TestNavigation.java ! test/tools/javac/modules/ModuleInfoTest.java ! test/tools/javac/modules/ProvidesTest.java From alan.bateman at oracle.com Fri Feb 24 11:08:17 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 24 Feb 2017 11:08:17 +0000 Subject: hg: jigsaw/jake/nashorn: 2 new changesets Message-ID: <201702241108.v1OB8HZg027745@aojmv0008.oracle.com> Changeset: d75af059cff6 Author: lana Date: 2017-02-23 16:21 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/d75af059cff6 Added tag jdk-9+158 for changeset 13ae2480a4c3 ! .hgtags Changeset: 46ba0efe400d Author: alanb Date: 2017-02-24 11:07 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/46ba0efe400d Merge ! .hgtags From alan.bateman at oracle.com Fri Feb 24 11:08:27 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 24 Feb 2017 11:08:27 +0000 Subject: hg: jigsaw/jake/jdk: 52 new changesets Message-ID: <201702241108.v1OB8TbT027777@aojmv0008.oracle.com> Changeset: 4fc407cc1bad Author: dfuchs Date: 2017-02-13 17:18 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4fc407cc1bad 8174833: java/net/httpclient/http2/BasicTest.java always fails but always report success Reviewed-by: michaelm ! test/java/net/httpclient/http2/BasicTest.java ! test/java/net/httpclient/http2/server/Http2TestServerConnection.java Changeset: a3b3c7b6464d Author: dlsmith Date: 2017-02-13 10:47 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a3b3c7b6464d 8174399: LambdaMetafactory should use types in implMethod.type() Reviewed-by: psandoz ! src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java ! src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java + test/java/lang/invoke/lambda/InheritedMethodTest.java Changeset: a9986a4dff27 Author: redestad Date: 2017-02-13 20:32 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a9986a4dff27 8174831: Reduce number of Charset classes loaded on bootstrap Reviewed-by: alanb ! src/java.base/share/classes/java/lang/StringCoding.java ! src/java.base/share/classes/java/nio/charset/Charset.java ! src/java.base/share/classes/sun/nio/cs/StandardCharsets.java.template ! src/java.base/share/classes/sun/nio/cs/US_ASCII.java Changeset: 735dfe90bf33 Author: sundar Date: 2017-02-14 07:33 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/735dfe90bf33 8174209: Renumber the compress levels Reviewed-by: alanb, jlaskey, mchung, redestad ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/DefaultCompressPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties ! test/tools/jlink/IntegrationTest.java ! test/tools/jlink/plugins/CompressorPluginTest.java Changeset: 46052e3e5372 Author: amlu Date: 2017-02-14 10:11 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/46052e3e5372 8169903: Refactor spliterator traversing tests into a library Reviewed-by: psandoz ! test/java/util/Spliterator/SpliteratorCollisions.java ! test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java + test/java/util/stream/bootlib/java.base/java/util/SpliteratorTestHelper.java ! test/java/util/stream/bootlib/java.base/java/util/stream/DoubleStreamTestScenario.java ! test/java/util/stream/bootlib/java.base/java/util/stream/IntStreamTestScenario.java ! test/java/util/stream/bootlib/java.base/java/util/stream/LongStreamTestScenario.java - test/java/util/stream/bootlib/java.base/java/util/stream/SpliteratorTestHelper.java ! test/java/util/stream/bootlib/java.base/java/util/stream/StreamTestScenario.java ! test/java/util/stream/boottest/java.base/java/util/stream/DoubleNodeTest.java ! test/java/util/stream/boottest/java.base/java/util/stream/IntNodeTest.java ! test/java/util/stream/boottest/java.base/java/util/stream/LongNodeTest.java ! test/java/util/stream/boottest/java.base/java/util/stream/NodeTest.java ! test/java/util/stream/boottest/java.base/java/util/stream/SliceSpliteratorTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/RangeTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamSpliteratorTest.java Changeset: ca12febae936 Author: amlu Date: 2017-02-14 12:43 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ca12febae936 8174887: Problem list javax/net/ssl/DTLS/RespondToRetransmit.java Reviewed-by: xuelei ! test/ProblemList.txt Changeset: 82bdb3885afa Author: coffeys Date: 2017-02-14 10:49 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/82bdb3885afa 8173094: Error in API documentation for SwingWorker 8173751: Syntax error in ZipFile.getComment() method 8173752: Syntax error in ZipEntry.setCompressedSize(long) method documentation 8173755: FilterOutputStream.write(byte[],int,int) javadoc correction 8173802: Incorrect argument name in java.io.FilterInputStream.read(byte[]) method documentation Reviewed-by: coffeys, chegar Contributed-by: abhijit.r.roy at oracle.com ! src/java.base/share/classes/java/io/FilterInputStream.java ! src/java.base/share/classes/java/io/FilterOutputStream.java ! src/java.base/share/classes/java/util/zip/ZipEntry.java ! src/java.base/share/classes/java/util/zip/ZipFile.java ! src/java.desktop/share/classes/javax/swing/SwingWorker.java Changeset: 4eb7b73bb5b6 Author: dkononenko Date: 2017-02-14 14:31 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4eb7b73bb5b6 8169715: jimage fails with IAE when attempts to inspect an empty file Summary: Added buffer's capacity checks. Reviewed-by: jlaskey, anazarov Contributed-by: denis.kononenko at oracle.com ! src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java Changeset: b8d79a801d16 Author: sundar Date: 2017-02-14 21:56 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b8d79a801d16 8174718: "Module 's descriptor returns inconsistent package set" confusing Reviewed-by: alanb, jlaskey, mchung ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ResourcePoolConfiguration.java ! test/tools/jlink/JLinkNegativeTest.java Changeset: d52809e235c9 Author: sherman Date: 2017-02-14 11:50 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d52809e235c9 8174248: partialUpdateFooMainClass test in tools/jar/modularJar/Basic.java needs to be re-examined Reviewed-by: chegar, lancea ! test/tools/jar/modularJar/Basic.java Changeset: 22af9029b07b Author: darcy Date: 2017-02-14 13:08 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/22af9029b07b 8174960: Mark WakeupAfterClose.java as failing intermittentl Reviewed-by: rriggs, bpb ! test/java/nio/channels/Selector/WakeupAfterClose.java Changeset: d014ae449563 Author: naoto Date: 2017-02-14 13:20 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d014ae449563 8174779: Locale issues with Mac 10.12 Reviewed-by: bchristi ! src/java.base/macosx/native/libjava/java_props_macosx.c Changeset: 1c101c68279d Author: psandoz Date: 2017-02-14 14:29 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1c101c68279d 8174151: URLClassLoader no longer uses custom URLStreamHandler for jar URLs Reviewed-by: alanb, chegar ! src/java.base/share/classes/java/net/URL.java ! src/java.base/share/classes/jdk/internal/loader/URLClassPath.java + src/java.base/share/classes/jdk/internal/misc/JavaNetURLAccess.java ! src/java.base/share/classes/jdk/internal/misc/SharedSecrets.java + test/java/net/URL/JarHandlerPkgPrefix/JarHandlerPkgPrefix.java + test/java/net/URL/JarHandlerPkgPrefix/handlers/jar/Handler.java Changeset: 734a8b392154 Author: weijun Date: 2017-02-15 09:08 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/734a8b392154 8174909: Doc error in SecureRandom Reviewed-by: mullan ! src/java.base/share/classes/java/security/DrbgParameters.java ! src/java.base/share/classes/java/security/SecureRandom.java Changeset: 8fd1fcfc2f09 Author: simonis Date: 2017-02-15 09:10 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8fd1fcfc2f09 8174950: Gracefully handle null Supplier in Objects.requireNonNull Reviewed-by: dholmes, psandoz, alanb, chegar ! src/java.base/share/classes/java/util/Objects.java Changeset: 8b0d55e02f54 Author: weijun Date: 2017-02-15 21:46 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8b0d55e02f54 8168410: Multiple JCK tests are failing due to SecurityException is not thrown. Reviewed-by: mullan ! src/java.base/share/classes/java/security/ProtectionDomain.java ! test/java/security/testlibrary/Proc.java ! test/sun/security/util/FilePermCompat/CompatImpact.java ! test/sun/security/util/FilePermCompat/Flag.java + test/sun/security/util/FilePermCompat/flag.policy Changeset: 87f2a6fb4b9a Author: redestad Date: 2017-02-15 15:57 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/87f2a6fb4b9a 8175010: ImageReader is not thread-safe Reviewed-by: alanb, jlaskey, chegar ! src/java.base/share/classes/jdk/internal/jimage/ImageReader.java ! src/java.base/share/classes/jdk/internal/jimage/ImageReaderFactory.java Changeset: 8060bc52c10e Author: psandoz Date: 2017-02-15 09:10 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8060bc52c10e 8165035: jar --help-extra should provide information on the -n/--normalize option Reviewed-by: chegar, alanb, mchung, lancea, sherman ! src/jdk.jartool/share/classes/sun/tools/jar/GNUStyleOptions.java ! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties Changeset: b035f72cddfc Author: sherman Date: 2017-02-15 12:11 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b035f72cddfc 8173207: Upgrade compression library Reviewed-by: alanb, erikj ! make/launcher/Launcher-jdk.pack.gmk ! make/lib/Awt2dLibraries.gmk ! make/lib/CoreLibraries.gmk ! make/lib/LibCommon.gmk - src/java.base/share/native/libzip/zlib-1.2.8/ChangeLog - src/java.base/share/native/libzip/zlib-1.2.8/README - src/java.base/share/native/libzip/zlib-1.2.8/compress.c - src/java.base/share/native/libzip/zlib-1.2.8/crc32.h - src/java.base/share/native/libzip/zlib-1.2.8/deflate.c - src/java.base/share/native/libzip/zlib-1.2.8/deflate.h - src/java.base/share/native/libzip/zlib-1.2.8/gzclose.c - src/java.base/share/native/libzip/zlib-1.2.8/gzguts.h - src/java.base/share/native/libzip/zlib-1.2.8/gzlib.c - src/java.base/share/native/libzip/zlib-1.2.8/gzread.c - src/java.base/share/native/libzip/zlib-1.2.8/gzwrite.c - src/java.base/share/native/libzip/zlib-1.2.8/infback.c - src/java.base/share/native/libzip/zlib-1.2.8/inffast.c - src/java.base/share/native/libzip/zlib-1.2.8/inffast.h - src/java.base/share/native/libzip/zlib-1.2.8/inffixed.h - src/java.base/share/native/libzip/zlib-1.2.8/inflate.c - src/java.base/share/native/libzip/zlib-1.2.8/inflate.h - src/java.base/share/native/libzip/zlib-1.2.8/inftrees.c - src/java.base/share/native/libzip/zlib-1.2.8/inftrees.h - src/java.base/share/native/libzip/zlib-1.2.8/patches/ChangeLog_java - src/java.base/share/native/libzip/zlib-1.2.8/trees.c - src/java.base/share/native/libzip/zlib-1.2.8/trees.h - src/java.base/share/native/libzip/zlib-1.2.8/uncompr.c - src/java.base/share/native/libzip/zlib-1.2.8/zadler32.c - src/java.base/share/native/libzip/zlib-1.2.8/zconf.h - src/java.base/share/native/libzip/zlib-1.2.8/zcrc32.c - src/java.base/share/native/libzip/zlib-1.2.8/zlib.h - src/java.base/share/native/libzip/zlib-1.2.8/zutil.c - src/java.base/share/native/libzip/zlib-1.2.8/zutil.h + src/java.base/share/native/libzip/zlib/ChangeLog + src/java.base/share/native/libzip/zlib/README + src/java.base/share/native/libzip/zlib/compress.c + src/java.base/share/native/libzip/zlib/crc32.h + src/java.base/share/native/libzip/zlib/deflate.c + src/java.base/share/native/libzip/zlib/deflate.h + src/java.base/share/native/libzip/zlib/infback.c + src/java.base/share/native/libzip/zlib/inffast.c + src/java.base/share/native/libzip/zlib/inffast.h + src/java.base/share/native/libzip/zlib/inffixed.h + src/java.base/share/native/libzip/zlib/inflate.c + src/java.base/share/native/libzip/zlib/inflate.h + src/java.base/share/native/libzip/zlib/inftrees.c + src/java.base/share/native/libzip/zlib/inftrees.h + src/java.base/share/native/libzip/zlib/patches/ChangeLog_java + src/java.base/share/native/libzip/zlib/trees.c + src/java.base/share/native/libzip/zlib/trees.h + src/java.base/share/native/libzip/zlib/uncompr.c + src/java.base/share/native/libzip/zlib/zadler32.c + src/java.base/share/native/libzip/zlib/zconf.h + src/java.base/share/native/libzip/zlib/zcrc32.c + src/java.base/share/native/libzip/zlib/zlib.h + src/java.base/share/native/libzip/zlib/zutil.c + src/java.base/share/native/libzip/zlib/zutil.h Changeset: d911fe42d2da Author: ascarpino Date: 2017-02-15 12:55 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d911fe42d2da 8174849: Change SHA1 certpath restrictions Reviewed-by: mullan ! src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChecker.java ! src/java.base/share/conf/security/java.security Changeset: 3534a97c9244 Author: mchung Date: 2017-02-15 16:18 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3534a97c9244 8173374: Update GenGraphs tool to generate dot graph with requires transitive edges Reviewed-by: dfuchs, redestad ! make/CompileModuleTools.gmk ! make/GenerateModuleSummary.gmk ! make/ModuleTools.gmk ! make/src/classes/build/tools/jigsaw/GenGraphs.java - make/src/classes/build/tools/jigsaw/Graph.java Changeset: 96e10bc4ff66 Author: vromero Date: 2017-02-15 17:00 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/96e10bc4ff66 8174694: improve error message shown when main class can't be loaded Reviewed-by: ksrini, alanb ! src/java.base/share/classes/sun/launcher/LauncherHelper.java ! src/java.base/share/classes/sun/launcher/resources/launcher.properties + test/tools/launcher/MainClassCantBeLoadedTest.java Changeset: dab92e4bd4ef Author: sherman Date: 2017-02-15 22:50 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/dab92e4bd4ef 8175053: March 5 builds failed on Windows/install repo after JDK-8173207 Reviewed-by: mchung + src/java.base/share/native/libzip/zlib/gzclose.c + src/java.base/share/native/libzip/zlib/gzguts.h + src/java.base/share/native/libzip/zlib/gzlib.c + src/java.base/share/native/libzip/zlib/gzread.c + src/java.base/share/native/libzip/zlib/gzwrite.c ! src/java.base/share/native/libzip/zlib/patches/ChangeLog_java ! src/java.base/share/native/libzip/zlib/zconf.h ! src/java.base/share/native/libzip/zlib/zutil.c Changeset: 77df00dbacfb Author: aefimov Date: 2017-02-16 13:17 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/77df00dbacfb 8174735: Update JAX-WS RI integration to latest version Reviewed-by: alanb, mchung, lancea Contributed-by: roman.grigoriadi at oracle.com ! src/java.base/share/classes/module-info.java ! src/java.base/share/lib/security/default.policy Changeset: b0fe19c8a49e Author: msheppar Date: 2017-02-16 11:26 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b0fe19c8a49e 8146299: Disable rmic -Xnew Reviewed-by: chegar, smarks, rriggs, mchung ! src/jdk.rmic/share/classes/sun/rmi/rmic/Main.java ! test/ProblemList.txt ! test/sun/rmi/rmic/newrmic/equivalence/run.sh Changeset: 8c022f735023 Author: redestad Date: 2017-02-16 17:28 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8c022f735023 8175079: Lazy initialization of ImageReader breaks rmid Reviewed-by: alanb ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java Changeset: 26a708e71902 Author: lana Date: 2017-02-16 18:28 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/26a708e71902 Merge - make/src/classes/build/tools/jigsaw/Graph.java - src/java.base/share/native/libzip/zlib-1.2.8/ChangeLog - src/java.base/share/native/libzip/zlib-1.2.8/README - src/java.base/share/native/libzip/zlib-1.2.8/compress.c - src/java.base/share/native/libzip/zlib-1.2.8/crc32.h - src/java.base/share/native/libzip/zlib-1.2.8/deflate.c - src/java.base/share/native/libzip/zlib-1.2.8/deflate.h - src/java.base/share/native/libzip/zlib-1.2.8/gzclose.c - src/java.base/share/native/libzip/zlib-1.2.8/gzguts.h - src/java.base/share/native/libzip/zlib-1.2.8/gzlib.c - src/java.base/share/native/libzip/zlib-1.2.8/gzread.c - src/java.base/share/native/libzip/zlib-1.2.8/gzwrite.c - src/java.base/share/native/libzip/zlib-1.2.8/infback.c - src/java.base/share/native/libzip/zlib-1.2.8/inffast.c - src/java.base/share/native/libzip/zlib-1.2.8/inffast.h - src/java.base/share/native/libzip/zlib-1.2.8/inffixed.h - src/java.base/share/native/libzip/zlib-1.2.8/inflate.c - src/java.base/share/native/libzip/zlib-1.2.8/inflate.h - src/java.base/share/native/libzip/zlib-1.2.8/inftrees.c - src/java.base/share/native/libzip/zlib-1.2.8/inftrees.h - src/java.base/share/native/libzip/zlib-1.2.8/patches/ChangeLog_java - src/java.base/share/native/libzip/zlib-1.2.8/trees.c - src/java.base/share/native/libzip/zlib-1.2.8/trees.h - src/java.base/share/native/libzip/zlib-1.2.8/uncompr.c - src/java.base/share/native/libzip/zlib-1.2.8/zadler32.c - src/java.base/share/native/libzip/zlib-1.2.8/zconf.h - src/java.base/share/native/libzip/zlib-1.2.8/zcrc32.c - src/java.base/share/native/libzip/zlib-1.2.8/zlib.h - src/java.base/share/native/libzip/zlib-1.2.8/zutil.c - src/java.base/share/native/libzip/zlib-1.2.8/zutil.h - test/java/util/stream/bootlib/java.base/java/util/stream/SpliteratorTestHelper.java Changeset: 9174f842811d Author: bpb Date: 2017-02-16 12:26 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9174f842811d 8175033: (se) Improve internal timing of java/nio/channels/Selector/WakeupAfterClose.java Summary: Add print of expected ClosedSelectorException Reviewed-by: alanb ! test/java/nio/channels/Selector/WakeupAfterClose.java Changeset: 910801555a96 Author: bpb Date: 2017-02-16 14:55 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/910801555a96 8175041: Add success message to java/nio/channels/FileChannel/LoopingTruncate.java Summary: Print "Test succeeded" to stdout at the end of main() Reviewed-by: alanb ! test/java/nio/channels/FileChannel/LoopingTruncate.java Changeset: 3286c922ac0b Author: bpb Date: 2017-02-16 14:56 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3286c922ac0b 8175042: Add success message to java/io/FileInputStream/LargeFileAvailable.java Summary: Print "Test succeeded" to stdout at the end of main() Reviewed-by: lancea ! test/java/io/FileInputStream/LargeFileAvailable.java Changeset: 055092148b3d Author: weijun Date: 2017-02-17 10:27 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/055092148b3d 8175120: Remove old tests on kdc timeout policy Reviewed-by: xuelei - test/sun/security/krb5/auto/BadKdc.java - test/sun/security/krb5/auto/BadKdc1.java - test/sun/security/krb5/auto/BadKdc2.java - test/sun/security/krb5/auto/BadKdc3.java - test/sun/security/krb5/auto/BadKdc4.java - test/sun/security/krb5/auto/CommMatcher.java - test/sun/security/krb5/auto/MaxRetries.java - test/sun/security/krb5/auto/TcpTimeout.java - test/sun/security/krb5/auto/UdpTcp.java Changeset: 02bb14ee7f9d Author: amlu Date: 2017-02-17 14:10 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/02bb14ee7f9d 8175062: Mark java/nio/channels/AsyncCloseAndInterrupt.java as intermittently failing Reviewed-by: bpb ! test/java/nio/channels/AsyncCloseAndInterrupt.java Changeset: b459c6ed9cd3 Author: ihse Date: 2017-02-17 14:55 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b459c6ed9cd3 8175165: Don't process JceSecurity.java.template if crypto sources is not present Reviewed-by: erikj ! make/gensrc/GensrcMisc.gmk Changeset: cdb6ac2b8a25 Author: aghaisas Date: 2017-02-08 17:02 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/cdb6ac2b8a25 8137087: [TEST_BUG] Cygwin failure of java/awt/appletviewer/IOExceptionIfEncodedURLTest/IOExceptionIfEncodedURLTest.sh Reviewed-by: yan, arapte Contributed-by: rahul.d.singh at oracle.com ! test/java/awt/appletviewer/IOExceptionIfEncodedURLTest/IOExceptionIfEncodedURLTest.sh Changeset: b0671742f122 Author: alexsch Date: 2017-02-08 18:10 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b0671742f122 8147440: HiDPI (Windows) Swing components have incorrect sizes after changing display resolution Reviewed-by: serb, azvegint ! src/java.desktop/windows/classes/sun/awt/Win32GraphicsDevice.java ! src/java.desktop/windows/classes/sun/awt/windows/WWindowPeer.java ! src/java.desktop/windows/native/libawt/windows/awt_Component.cpp ! src/java.desktop/windows/native/libawt/windows/awt_Component.h ! src/java.desktop/windows/native/libawt/windows/awt_Window.cpp ! src/java.desktop/windows/native/libawt/windows/awt_Window.h + test/java/awt/Window/WindowResizingOnDPIChanging/WindowResizingOnDPIChangingTest.java + test/java/awt/Window/WindowResizingOnDPIChanging/WindowResizingOnMovingToAnotherDisplay.java Changeset: ba316e40c19b Author: malenkov Date: 2017-02-08 19:22 +0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ba316e40c19b 8173876: Fast precise scrolling and DeltaAccumulator fix for macOS Sierra 10.12.2 Reviewed-by: serb, alexsch ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/NSEvent.java ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CTrayIcon.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/LWCToolkit.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/LWCToolkit.m ! test/javax/swing/plaf/basic/BasicScrollPaneUI/8166591/TooMuchWheelRotationEventsTest.java Changeset: e69569fe2655 Author: psadhukhan Date: 2017-02-10 13:32 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e69569fe2655 8147002: [macosx] Arabic character cannot be rendered on MacOS X Reviewed-by: prr, pnarayanan, jdv Contributed-by: prasanta.sadhukhan at oracle.com, prahalad.kumar.narayanan at oracle.com ! src/java.desktop/macosx/classes/sun/font/CFont.java + test/java/awt/font/Fallback/MissingGlyphTest.java Changeset: 6ead667074d4 Author: prr Date: 2017-02-10 08:57 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6ead667074d4 Merge - src/java.base/share/classes/sun/security/provider/certpath/PKIXTimestampParameters.java - src/java.base/share/classes/sun/security/util/CertConstraintParameters.java - src/java.base/unix/classes/sun/nio/fs/DefaultFileSystemProvider.java - test/java/lang/StackWalker/CountLocalSlots.java - test/java/lang/StackWalker/LocalsCrash.java - test/java/lang/invoke/lambda/MetafactorySamReturnTest.java - test/java/lang/invoke/modules/ModuleAccessControlTest.java - test/java/lang/invoke/modules/src/m1/module-info.java - test/java/lang/invoke/modules/src/m1/p1/Main.java - test/java/lang/invoke/modules/src/m1/p1/Type1.java - test/java/lang/invoke/modules/src/m1/p2/Type2.java - test/java/lang/invoke/modules/src/m2/module-info.java - test/java/lang/invoke/modules/src/m2/q1/Type1.java - test/java/lang/invoke/modules/src/m2/q2/Type2.java Changeset: 462934a5d8b1 Author: prr Date: 2017-02-10 10:20 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/462934a5d8b1 8172967: [macosx] Exception while working with layout for text containing unmappable character Reviewed-by: serb, psadhukhan ! src/java.desktop/share/classes/sun/font/CompositeStrike.java ! src/java.desktop/share/classes/sun/font/ExtendedTextSourceLabel.java ! src/java.desktop/share/native/libfontmanager/hb-jdk-font.cc + test/java/awt/font/TextLayout/MissingCodePointLayoutTest.java Changeset: 68e4988e48e6 Author: jdv Date: 2017-02-13 12:13 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/68e4988e48e6 7107905: ColorModel subclasses are missing hashCode() or equals() or both methods Reviewed-by: prr, flar Contributed-by: jayathirth.d.v at oracle.com ! src/java.desktop/share/classes/java/awt/image/ColorModel.java ! src/java.desktop/share/classes/java/awt/image/ComponentColorModel.java ! src/java.desktop/share/classes/java/awt/image/IndexColorModel.java ! src/java.desktop/share/classes/java/awt/image/PackedColorModel.java + test/java/awt/image/ColorModel/EqualsTest.java + test/java/awt/image/ComponentColorModel/ComponentColorModelEqualsTest.java + test/java/awt/image/IndexColorModel/IndexColorModelEqualsTest.java + test/java/awt/image/PackedColorModel/PackedColorModelEqualsTest.java Changeset: 1b9926205a97 Author: psadhukhan Date: 2017-02-13 16:26 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1b9926205a97 8174720: [TEST_BUG] add :open to a @modules annotation for bug7089914.java Reviewed-by: yan ! test/com/sun/java/swing/plaf/windows/WindowsRadioButtonUI/7089914/bug7089914.java Changeset: 2855498ee7c6 Author: prr Date: 2017-02-13 08:49 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2855498ee7c6 8170913: Java "1.8.0_112" on Windows 10 displays different characters for EUDCs from ones created in eudcedit.exe. Reviewed-by: vadim, psadhukhan ! src/java.desktop/share/classes/sun/font/CompositeFont.java Changeset: 079b407272a9 Author: prr Date: 2017-02-13 11:48 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/079b407272a9 8173028: Incorrect processing of supplementary-plane characters in text fields Reviewed-by: serb, vadim ! src/java.desktop/share/classes/sun/font/ExtendedTextSourceLabel.java + test/java/awt/font/TextLayout/HitTest.java Changeset: 32cddf46ddb6 Author: ddehaven Date: 2017-02-13 11:51 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/32cddf46ddb6 Merge - test/javax/xml/jaxp/common/8035437/Document.java - test/javax/xml/jaxp/common/8035437/DocumentImpl.java - test/javax/xml/jaxp/common/8035437/Node.java + test/javax/xml/jaxp/common/8035437/patch-src1/org/w3c/dom/Document.java + test/javax/xml/jaxp/common/8035437/patch-src1/org/w3c/dom/Node.java + test/javax/xml/jaxp/common/8035437/patch-src2/com/sun/org/apache/xerces/internal/dom/DocumentImpl.java - test/sun/text/IntHashtable/Bug4170614Test.java + test/sun/text/IntHashtable/patch-src/java/text/Bug4170614Test.java Changeset: 7ba90377c7f4 Author: dbatrak Date: 2017-02-14 00:09 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7ba90377c7f4 8170950: Text is displayed in bold when fonts are installed into symlinked folder Reviewed-by: prr, serb ! src/java.desktop/share/classes/sun/font/FontFamily.java Changeset: 3d324be1e6a0 Author: azvegint Date: 2017-02-14 01:11 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3d324be1e6a0 8166313: JavaDoc mentions AppEvent subclasses as inner class of AppEvent Reviewed-by: serb, ssadetsky ! src/java.desktop/share/classes/java/awt/Desktop.java ! src/java.desktop/share/classes/java/awt/desktop/AppForegroundEvent.java ! src/java.desktop/share/classes/java/awt/desktop/AppHiddenEvent.java ! src/java.desktop/share/classes/java/awt/desktop/AppReopenedEvent.java ! src/java.desktop/share/classes/java/awt/desktop/OpenURIEvent.java ! src/java.desktop/share/classes/java/awt/desktop/PrintFilesEvent.java ! src/java.desktop/share/classes/java/awt/desktop/QuitEvent.java ! src/java.desktop/share/classes/java/awt/desktop/ScreenSleepEvent.java ! src/java.desktop/share/classes/java/awt/desktop/SystemSleepEvent.java ! src/java.desktop/share/classes/java/awt/desktop/UserSessionEvent.java Changeset: 40f17fdc4490 Author: psadhukhan Date: 2017-02-14 10:00 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/40f17fdc4490 8174717: [TEST_BUG] javax/swing/text/html/StyleSheet/bug4936917.java Reviewed-by: yan, serb ! test/javax/swing/text/html/StyleSheet/bug4936917.java Changeset: 1ae309b73c0d Author: pnarayanan Date: 2017-02-14 11:24 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1ae309b73c0d 6852563: ArrayOutOfBoundException when reading RLE8 compressed bitmap Reviewed-by: prr, jdv ! src/java.desktop/share/classes/com/sun/imageio/plugins/bmp/BMPImageReader.java Changeset: 91a8b80fe1bc Author: ddehaven Date: 2017-02-16 13:55 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/91a8b80fe1bc Merge Changeset: c476ca737506 Author: redestad Date: 2017-02-17 18:12 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c476ca737506 8175026: Capture build-time parameters to --generate-jli-classes Reviewed-by: mchung ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/GenerateJLIClassesPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties Changeset: bc86105ee839 Author: lana Date: 2017-02-23 16:21 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/bc86105ee839 Added tag jdk-9+158 for changeset c476ca737506 ! .hgtags Changeset: 4ddb61b128db Author: alanb Date: 2017-02-24 11:07 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4ddb61b128db Merge ! .hgtags ! make/CompileModuleTools.gmk ! make/GenerateModuleSummary.gmk ! make/ModuleTools.gmk ! make/gensrc/GensrcMisc.gmk ! make/launcher/Launcher-jdk.pack.gmk ! make/lib/Awt2dLibraries.gmk ! make/lib/CoreLibraries.gmk ! make/lib/LibCommon.gmk ! make/src/classes/build/tools/jigsaw/GenGraphs.java - make/src/classes/build/tools/jigsaw/Graph.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/net/URL.java ! src/java.base/share/classes/java/nio/charset/Charset.java ! src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java ! src/java.base/share/classes/jdk/internal/jimage/ImageReader.java ! src/java.base/share/classes/jdk/internal/jimage/ImageReaderFactory.java ! src/java.base/share/classes/jdk/internal/loader/URLClassPath.java ! src/java.base/share/classes/jdk/internal/misc/SharedSecrets.java ! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java ! src/java.base/share/classes/module-info.java ! src/java.base/share/classes/sun/launcher/LauncherHelper.java ! src/java.base/share/classes/sun/launcher/resources/launcher.properties ! src/java.base/share/conf/security/java.security - src/java.base/share/native/libzip/zlib-1.2.8/ChangeLog - src/java.base/share/native/libzip/zlib-1.2.8/README - src/java.base/share/native/libzip/zlib-1.2.8/compress.c - src/java.base/share/native/libzip/zlib-1.2.8/crc32.h - src/java.base/share/native/libzip/zlib-1.2.8/deflate.c - src/java.base/share/native/libzip/zlib-1.2.8/deflate.h - src/java.base/share/native/libzip/zlib-1.2.8/gzclose.c - src/java.base/share/native/libzip/zlib-1.2.8/gzguts.h - src/java.base/share/native/libzip/zlib-1.2.8/gzlib.c - src/java.base/share/native/libzip/zlib-1.2.8/gzread.c - src/java.base/share/native/libzip/zlib-1.2.8/gzwrite.c - src/java.base/share/native/libzip/zlib-1.2.8/infback.c - src/java.base/share/native/libzip/zlib-1.2.8/inffast.c - src/java.base/share/native/libzip/zlib-1.2.8/inffast.h - src/java.base/share/native/libzip/zlib-1.2.8/inffixed.h - src/java.base/share/native/libzip/zlib-1.2.8/inflate.c - src/java.base/share/native/libzip/zlib-1.2.8/inflate.h - src/java.base/share/native/libzip/zlib-1.2.8/inftrees.c - src/java.base/share/native/libzip/zlib-1.2.8/inftrees.h - src/java.base/share/native/libzip/zlib-1.2.8/patches/ChangeLog_java - src/java.base/share/native/libzip/zlib-1.2.8/trees.c - src/java.base/share/native/libzip/zlib-1.2.8/trees.h - src/java.base/share/native/libzip/zlib-1.2.8/uncompr.c - src/java.base/share/native/libzip/zlib-1.2.8/zadler32.c - src/java.base/share/native/libzip/zlib-1.2.8/zconf.h - src/java.base/share/native/libzip/zlib-1.2.8/zcrc32.c - src/java.base/share/native/libzip/zlib-1.2.8/zlib.h - src/java.base/share/native/libzip/zlib-1.2.8/zutil.c - src/java.base/share/native/libzip/zlib-1.2.8/zutil.h ! src/jdk.jartool/share/classes/sun/tools/jar/GNUStyleOptions.java ! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ResourcePoolConfiguration.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/DefaultCompressPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties ! test/ProblemList.txt ! test/java/security/testlibrary/Proc.java - test/java/util/stream/bootlib/java.base/java/util/stream/SpliteratorTestHelper.java - test/sun/security/krb5/auto/BadKdc.java - test/sun/security/krb5/auto/BadKdc1.java - test/sun/security/krb5/auto/BadKdc2.java - test/sun/security/krb5/auto/BadKdc3.java - test/sun/security/krb5/auto/BadKdc4.java - test/sun/security/krb5/auto/CommMatcher.java - test/sun/security/krb5/auto/MaxRetries.java - test/sun/security/krb5/auto/TcpTimeout.java - test/sun/security/krb5/auto/UdpTcp.java ! test/tools/jar/modularJar/Basic.java ! test/tools/jlink/IntegrationTest.java ! test/tools/jlink/JLinkNegativeTest.java ! test/tools/jlink/plugins/CompressorPluginTest.java From claes.redestad at oracle.com Fri Feb 24 11:14:15 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 24 Feb 2017 12:14:15 +0100 Subject: RFR: 8175385: ServiceLoader$LazyClassPathLookupIterator scans boot and platform modules for services In-Reply-To: <5dde79d7-9e67-941f-a8aa-75f93b9987c0@oracle.com> References: <5e0c670d-7e91-ea6b-ab2a-3ffc6b0c94c1@oracle.com> <5dde79d7-9e67-941f-a8aa-75f93b9987c0@oracle.com> Message-ID: <9def859f-72e4-db86-8f2d-b5c07bf3c7c3@oracle.com> On 02/24/2017 09:50 AM, Alan Bateman wrote: > > > On 23/02/2017 23:19, Claes Redestad wrote: >> Hi, >> >> related to the same regression as JDK-8175561, there are now some cases >> where we unnecessarily scan platform modules for services. This patch >> allows us to skip the platform and boot classloaders in certain cases, >> which speeds up loading and enumerating the built-in services. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8175561 >> Webrev: http://cr.openjdk.java.net/~redestad/8175385/jdk.01/ > Looks good. Thanks! > A minor nit is to move BootLoader hasClassPath() so it's co-located > with the other public static methods. Moved it up to just after packages() (updated in-place). /Claes > > -Alan From volker.simonis at gmail.com Fri Feb 24 15:08:05 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 24 Feb 2017 16:08:05 +0100 Subject: Extending java.base module In-Reply-To: References: <923e234609234237bc42089c76b5c6c3@derote13de46.global.corp.sap> <387c6a3c-3371-b6f6-4e01-65647a3ad812@oracle.com> <79cb413f-fd60-3a0a-7739-29ef06ad4a5e@oracle.com> Message-ID: On Wed, Feb 15, 2017 at 5:20 PM, Volker Simonis wrote: > > On Wed, Feb 15, 2017 at 5:16 PM, Alan Bateman wrote: > > On 15/02/2017 16:01, Daniel Fuchs wrote: > > > >> > >> In that specific case it's not java.base that depends > >> on java.security.jgss, but the application itself. > >> > >> So I would expect the application code to either require > >> java.security.jgss, or some higher level module for that > >> itself requires java.security.jgss, or jlink to be run with > >> command line options that explicitly add java.security.jgss > >> to the image. > > > > java.security.jgss exports an API so it will be resolved by default when the > > initial class is loaded from the class path. In addition, it provides a > > SecurityProvider implementation and so will be resolved because java.base > > `uses java.security.Provider`. For the jlink case then you are right, it > > needs someone to know that the application might need to do SPNEGO > > authentication. > > > > In any case, it's an example of how not to do things, and hopefully it will > > be cleaned up at some point. > > > While digging deeper into this topic, I found other such examples (and you can easily find more by searching for "Class.forName" in the base module :) sun.text.bidi.BidiBase$TextAttributeConstants (which is in the base module) has the following static initializer: // Make sure to load the AWT's TextAttribute class before using the constants, if any. static { try { Class.forName("java.awt.font.TextAttribute", true, null); } catch (ClassNotFoundException e) {} } static final JavaAWTFontAccess jafa = SharedSecrets.getJavaAWTFontAccess(); which is clearly another implicit dependency from java.base to java.desktop which contains java.awt.font.TextAttribute There's yet another such implicit dependency from java.base to jdk.net in sun.net.ext.ExtendedSocketOptions which has the following static initializer: static { try { // If the class is present, it will be initialized which // triggers registration of the extended socket options. Class c = Class.forName("jdk.net.ExtendedSocketOptions"); } catch (ClassNotFoundException e) { // the jdk.net module is not present => no extended socket options instance = new NoExtendedSocketOptions(); } } So I'm wondering if these all are examples of "how not to do things" which will be cleaned up eventually or are if there other reasons that this cleanup hasn't been done until now. I can imagine that if all the current, implicit dependencies would have been resolved by using services, service binding could lead to a much bigger dependency graph for the base module which would probably include most of the modules in the jdk. Not sure if this could have an negative performance impact on startup time? Wouldn't it be a good idea to have a list of all this implicit dependencies somewhere (preferable in JBS) with a short comment for each of them (like "should be fixed by using services", "will leave as is because it's required too early during initialization", "should remove dependency by refactoring the code", etc..) Thank you and best regards, Volker > > Daniel, Alan, thanks for the clarification. I didn't wanted to blame > anybody - just looking for good arguments to prevent such code in our > version of the JDK :) > > > -Alan > > > > From sundararajan.athijegannathan at oracle.com Fri Feb 24 16:37:18 2017 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Fri, 24 Feb 2017 16:37:18 +0000 Subject: hg: jigsaw/jake/jdk: jlink ExcludeVMPlugin should use ResourcePoolModule.osName() Message-ID: <201702241637.v1OGbIke028543@aojmv0008.oracle.com> Changeset: 2b20fe8e7938 Author: sundar Date: 2017-02-24 22:22 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2b20fe8e7938 jlink ExcludeVMPlugin should use ResourcePoolModule.osName() ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ExcludeVMPlugin.java ! test/ProblemList.txt From mandy.chung at oracle.com Fri Feb 24 23:38:30 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 24 Feb 2017 15:38:30 -0800 Subject: RFR: 8175561: Memory churn in jimage code affects startup after resource encapsulation changes In-Reply-To: <369c4d61-32d8-ae8d-6f88-45f6bde3ff37@oracle.com> References: <369c4d61-32d8-ae8d-6f88-45f6bde3ff37@oracle.com> Message-ID: > On Feb 23, 2017, at 2:57 PM, Claes Redestad wrote: > > Hi, > > various resource encapsulation changes in 9+148 meant an uptick in > footprint and startup times for certain applications. > > While some of this regression is hard to avoid[1] (opening readers, > touching more memory mapped pages etc), a large part is due to simple > java allocation churn, some of which can be optimized away by reducing > the number of objects we create when scanning modules for resources. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8175561 > Webrev: http://cr.openjdk.java.net/~redestad/8175561/jdk.01/ > ImageStringsReader.java Should the hashCode methods taking byte[] parameter be removed? ImageLocation.java I suggest to add the comment to describe the expect format comparing to the name. something like ?//[/][.]? and a comment for each if-statement what segment is checking. I have carefully reviewed the change which attempts to inline the code and write to avoid object allocation. It looks correct to me. Since jimage is a sensitive area, I suggest to run PIT and do the automated hotspot testing. Mandy From doug.simon at oracle.com Sun Feb 26 11:20:58 2017 From: doug.simon at oracle.com (Doug Simon) Date: Sun, 26 Feb 2017 12:20:58 +0100 Subject: Problem loading Truffle service providers in Graal Message-ID: While trying to get upstream Graal working again with JDK 9, I'm having problems with service loading. Graal uses a LayoutFactory service defined by Truffle where the latter also includes a provider. The relevant parts of the module-info descriptors are: module com.oracle.truffle.truffle_api { exports com.oracle.truffle.object; exports com.oracle.truffle.object.basic; uses com.oracle.truffle.api.object.LayoutFactory; provides com.oracle.truffle.api.object.LayoutFactory with com.oracle.truffle.object.basic.DefaultLayoutFactory; } module jdk.internal.vm.compiler { requires transitive com.oracle.truffle.truffle_api; uses com.oracle.truffle.api.object.LayoutFactory; } However, looking up a provider in Graal[1] returns no providers. As far as I understand service loading with modules, this is because jdk.internal.vm.compiler is loaded via the platform class loader while truffle is loaded via the app class loader as shown by the output of trace statements I added: GraalTruffleRuntime.class.getClassLoader() -> jdk.internal.loader.ClassLoaders$PlatformClassLoader at 366e2eef LayoutFactory.class.getClassLoader() -> jdk.internal.loader.ClassLoaders$AppClassLoader at 6df97b55 This ability of a platform loaded class to depend on an app loaded class is probably due to the soon-to-be-disabled mechanism[2] we use for overriding the version of Graal bundled with JDK 9. Is there some command line magic I can use to make this case work now or do I have to wait until [2] is addressed? If the latter, how will it work then? -Doug [1] https://github.com/graalvm/graal-core/blob/1efc1c543acd7ed447c59788aeabc223be13e774/graal/org.graalvm.compiler.truffle/src/org/graalvm/compiler/truffle/GraalTruffleRuntime.java#L693 [2] http://mail.openjdk.java.net/pipermail/graal-dev/2017-February/004889.html From Alan.Bateman at oracle.com Sun Feb 26 12:08:09 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 26 Feb 2017 12:08:09 +0000 Subject: Problem loading Truffle service providers in Graal In-Reply-To: References: Message-ID: On 26/02/2017 11:20, Doug Simon wrote: > While trying to get upstream Graal working again with JDK 9, I'm having problems with service loading. Graal uses a LayoutFactory service defined by Truffle where the latter also includes a provider. The relevant parts of the module-info descriptors are: > > module com.oracle.truffle.truffle_api { > > exports com.oracle.truffle.object; > exports com.oracle.truffle.object.basic; > > uses com.oracle.truffle.api.object.LayoutFactory; > provides com.oracle.truffle.api.object.LayoutFactory with com.oracle.truffle.object.basic.DefaultLayoutFactory; > > } > > module jdk.internal.vm.compiler { > > requires transitive com.oracle.truffle.truffle_api; > uses com.oracle.truffle.api.object.LayoutFactory; > > } > > However, looking up a provider in Graal[1] returns no providers. As far as I understand service loading with modules, this is because jdk.internal.vm.compiler is loaded via the platform class loader while truffle is loaded via the app class loader as shown by the output of trace statements I added: > > GraalTruffleRuntime.class.getClassLoader() -> jdk.internal.loader.ClassLoaders$PlatformClassLoader at 366e2eef > LayoutFactory.class.getClassLoader() -> jdk.internal.loader.ClassLoaders$AppClassLoader at 6df97b55 > > This ability of a platform loaded class to depend on an app loaded class is probably due to the soon-to-be-disabled mechanism[2] we use for overriding the version of Graal bundled with JDK 9. > > Is there some command line magic I can use to make this case work now or do I have to wait until [2] is addressed? If the latter, how will it work then? > An upgraded moduledefined to the platform loader can link to types in modules defined to the app loader. So I wouldn't expect issues there. Can you track down the code that uses ServiceLoader.load to load the LayoutFactory providers? It might be using loadInstalled or invoking it with the platform class loader and that would explain what you are seeing. -Alan From doug.simon at oracle.com Sun Feb 26 12:22:08 2017 From: doug.simon at oracle.com (Doug Simon) Date: Sun, 26 Feb 2017 13:22:08 +0100 Subject: Problem loading Truffle service providers in Graal In-Reply-To: References: Message-ID: > On 26 Feb 2017, at 13:08, Alan Bateman wrote: > > On 26/02/2017 11:20, Doug Simon wrote: > >> While trying to get upstream Graal working again with JDK 9, I'm having problems with service loading. Graal uses a LayoutFactory service defined by Truffle where the latter also includes a provider. The relevant parts of the module-info descriptors are: >> >> module com.oracle.truffle.truffle_api { >> >> exports com.oracle.truffle.object; >> exports com.oracle.truffle.object.basic; >> >> uses com.oracle.truffle.api.object.LayoutFactory; >> provides com.oracle.truffle.api.object.LayoutFactory with com.oracle.truffle.object.basic.DefaultLayoutFactory; >> >> } >> >> module jdk.internal.vm.compiler { >> requires transitive com.oracle.truffle.truffle_api; >> uses com.oracle.truffle.api.object.LayoutFactory; >> >> } >> >> However, looking up a provider in Graal[1] returns no providers. As far as I understand service loading with modules, this is because jdk.internal.vm.compiler is loaded via the platform class loader while truffle is loaded via the app class loader as shown by the output of trace statements I added: >> >> GraalTruffleRuntime.class.getClassLoader() -> jdk.internal.loader.ClassLoaders$PlatformClassLoader at 366e2eef >> LayoutFactory.class.getClassLoader() -> jdk.internal.loader.ClassLoaders$AppClassLoader at 6df97b55 >> >> This ability of a platform loaded class to depend on an app loaded class is probably due to the soon-to-be-disabled mechanism[2] we use for overriding the version of Graal bundled with JDK 9. >> >> Is there some command line magic I can use to make this case work now or do I have to wait until [2] is addressed? If the latter, how will it work then? >> > An upgraded moduledefined to the platform loader can link to types in modules defined to the app loader. So I wouldn't expect issues there. > > Can you track down the code that uses ServiceLoader.load to load the LayoutFactory providers? The code is in the first link of my previous message: https://github.com/graalvm/graal-core/blob/1efc1c543acd7ed447c59788aeabc223be13e774/graal/org.graalvm.compiler.truffle/src/org/graalvm/compiler/truffle/GraalTruffleRuntime.java#L693 > It might be using loadInstalled or invoking it with the platform class loader and that would explain what you are seeing. Thanks - using LayoutFactory.class.getClassLoader() works. So the general rule is to use the leaf most class loader the service client knows about? -Doug From doug.simon at oracle.com Sun Feb 26 12:26:35 2017 From: doug.simon at oracle.com (Doug Simon) Date: Sun, 26 Feb 2017 13:26:35 +0100 Subject: Problem loading Truffle service providers in Graal In-Reply-To: References: Message-ID: <7D3F4645-5219-4EE7-97A6-9B6131811735@oracle.com> > On 26 Feb 2017, at 13:22, Doug Simon wrote: > >> >> On 26 Feb 2017, at 13:08, Alan Bateman wrote: >> >> On 26/02/2017 11:20, Doug Simon wrote: >> >>> While trying to get upstream Graal working again with JDK 9, I'm having problems with service loading. Graal uses a LayoutFactory service defined by Truffle where the latter also includes a provider. The relevant parts of the module-info descriptors are: >>> >>> module com.oracle.truffle.truffle_api { >>> >>> exports com.oracle.truffle.object; >>> exports com.oracle.truffle.object.basic; >>> >>> uses com.oracle.truffle.api.object.LayoutFactory; >>> provides com.oracle.truffle.api.object.LayoutFactory with com.oracle.truffle.object.basic.DefaultLayoutFactory; >>> >>> } >>> >>> module jdk.internal.vm.compiler { >>> requires transitive com.oracle.truffle.truffle_api; >>> uses com.oracle.truffle.api.object.LayoutFactory; >>> >>> } >>> >>> However, looking up a provider in Graal[1] returns no providers. As far as I understand service loading with modules, this is because jdk.internal.vm.compiler is loaded via the platform class loader while truffle is loaded via the app class loader as shown by the output of trace statements I added: >>> >>> GraalTruffleRuntime.class.getClassLoader() -> jdk.internal.loader.ClassLoaders$PlatformClassLoader at 366e2eef >>> LayoutFactory.class.getClassLoader() -> jdk.internal.loader.ClassLoaders$AppClassLoader at 6df97b55 >>> >>> This ability of a platform loaded class to depend on an app loaded class is probably due to the soon-to-be-disabled mechanism[2] we use for overriding the version of Graal bundled with JDK 9. >>> >>> Is there some command line magic I can use to make this case work now or do I have to wait until [2] is addressed? If the latter, how will it work then? >>> >> An upgraded moduledefined to the platform loader can link to types in modules defined to the app loader. So I wouldn't expect issues there. >> >> Can you track down the code that uses ServiceLoader.load to load the LayoutFactory providers? > > The code is in the first link of my previous message: > > https://github.com/graalvm/graal-core/blob/1efc1c543acd7ed447c59788aeabc223be13e774/graal/org.graalvm.compiler.truffle/src/org/graalvm/compiler/truffle/GraalTruffleRuntime.java#L693 > >> It might be using loadInstalled or invoking it with the platform class loader and that would explain what you are seeing. > > Thanks - using LayoutFactory.class.getClassLoader() works. So the general rule is to use the leaf most class loader the service client knows about? If that's the case, does that mean I could pick up any provider on the app class path? Seems a little risky. Is there some way to confine it to modules the service user trusts (by virtual of being a module in its dependency graph)? -Doug From doug.simon at oracle.com Sun Feb 26 13:13:32 2017 From: doug.simon at oracle.com (Doug Simon) Date: Sun, 26 Feb 2017 14:13:32 +0100 Subject: Problem loading Truffle service providers in Graal In-Reply-To: <7D3F4645-5219-4EE7-97A6-9B6131811735@oracle.com> References: <7D3F4645-5219-4EE7-97A6-9B6131811735@oracle.com> Message-ID: <78D820BA-F0B0-4F65-82CC-41B9F5A5BE6F@oracle.com> > On 26 Feb 2017, at 13:26, Doug Simon wrote: > >> >> On 26 Feb 2017, at 13:22, Doug Simon wrote: >> >>> >>> On 26 Feb 2017, at 13:08, Alan Bateman wrote: >>> >>> On 26/02/2017 11:20, Doug Simon wrote: >>> >>>> While trying to get upstream Graal working again with JDK 9, I'm having problems with service loading. Graal uses a LayoutFactory service defined by Truffle where the latter also includes a provider. The relevant parts of the module-info descriptors are: >>>> >>>> module com.oracle.truffle.truffle_api { >>>> >>>> exports com.oracle.truffle.object; >>>> exports com.oracle.truffle.object.basic; >>>> >>>> uses com.oracle.truffle.api.object.LayoutFactory; >>>> provides com.oracle.truffle.api.object.LayoutFactory with com.oracle.truffle.object.basic.DefaultLayoutFactory; >>>> >>>> } >>>> >>>> module jdk.internal.vm.compiler { >>>> requires transitive com.oracle.truffle.truffle_api; >>>> uses com.oracle.truffle.api.object.LayoutFactory; >>>> >>>> } >>>> >>>> However, looking up a provider in Graal[1] returns no providers. As far as I understand service loading with modules, this is because jdk.internal.vm.compiler is loaded via the platform class loader while truffle is loaded via the app class loader as shown by the output of trace statements I added: >>>> >>>> GraalTruffleRuntime.class.getClassLoader() -> jdk.internal.loader.ClassLoaders$PlatformClassLoader at 366e2eef >>>> LayoutFactory.class.getClassLoader() -> jdk.internal.loader.ClassLoaders$AppClassLoader at 6df97b55 >>>> >>>> This ability of a platform loaded class to depend on an app loaded class is probably due to the soon-to-be-disabled mechanism[2] we use for overriding the version of Graal bundled with JDK 9. >>>> >>>> Is there some command line magic I can use to make this case work now or do I have to wait until [2] is addressed? If the latter, how will it work then? >>>> >>> An upgraded moduledefined to the platform loader can link to types in modules defined to the app loader. So I wouldn't expect issues there. >>> >>> Can you track down the code that uses ServiceLoader.load to load the LayoutFactory providers? >> >> The code is in the first link of my previous message: >> >> https://github.com/graalvm/graal-core/blob/1efc1c543acd7ed447c59788aeabc223be13e774/graal/org.graalvm.compiler.truffle/src/org/graalvm/compiler/truffle/GraalTruffleRuntime.java#L693 >> >>> It might be using loadInstalled or invoking it with the platform class loader and that would explain what you are seeing. >> >> Thanks - using LayoutFactory.class.getClassLoader() works. So the general rule is to use the leaf most class loader the service client knows about? > > If that's the case, does that mean I could pick up any provider on the app class path? Seems a little risky. Is there some way to confine it to modules the service user trusts (by virtual of being a module in its dependency graph)? Also, what if there's provider in jdk.internal.vm.compiler itself? Will it be loaded along with the providers on my module path? -Doug From Alan.Bateman at oracle.com Sun Feb 26 13:35:27 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 26 Feb 2017 13:35:27 +0000 Subject: Problem loading Truffle service providers in Graal In-Reply-To: <7D3F4645-5219-4EE7-97A6-9B6131811735@oracle.com> References: <7D3F4645-5219-4EE7-97A6-9B6131811735@oracle.com> Message-ID: On 26/02/2017 12:26, Doug Simon wrote: > : > If that's the case, does that mean I could pick up any provider on the app class path? Seems a little risky. Is there some way to confine it to modules the service user trusts (by virtual of being a module in its dependency graph)? > You can restrict the service type using a qualified export. -Alan From Alan.Bateman at oracle.com Sun Feb 26 13:44:42 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 26 Feb 2017 13:44:42 +0000 Subject: Problem loading Truffle service providers in Graal In-Reply-To: <78D820BA-F0B0-4F65-82CC-41B9F5A5BE6F@oracle.com> References: <7D3F4645-5219-4EE7-97A6-9B6131811735@oracle.com> <78D820BA-F0B0-4F65-82CC-41B9F5A5BE6F@oracle.com> Message-ID: On 26/02/2017 13:13, Doug Simon wrote: > : > Also, what if there's provider in jdk.internal.vm.compiler itself? Will it be loaded along with the providers on my module path? > If it has `provides com.oracle.truffle.api.object.LayoutFactory` then it will be located too. If the provider interface is only for overriding then you could use ServiceLoader.load(LayerFactory.class).findFirst().orElse(DefaultLayoutFactory.get()) so that it use a default/fallback implementation in your module when there isn't a provider deployed on the module path. -Alan From doug.simon at oracle.com Sun Feb 26 13:54:38 2017 From: doug.simon at oracle.com (Doug Simon) Date: Sun, 26 Feb 2017 14:54:38 +0100 Subject: Problem loading Truffle service providers in Graal In-Reply-To: References: <7D3F4645-5219-4EE7-97A6-9B6131811735@oracle.com> <78D820BA-F0B0-4F65-82CC-41B9F5A5BE6F@oracle.com> Message-ID: <31EE63B3-7076-4BF6-BE65-F100945B1B22@oracle.com> > On 26 Feb 2017, at 14:44, Alan Bateman wrote: > > > > On 26/02/2017 13:13, Doug Simon wrote: >> : >> Also, what if there's provider in jdk.internal.vm.compiler itself? Will it be loaded along with the providers on my module path? >> > If it has `provides com.oracle.truffle.api.object.LayoutFactory` then it will be located too. I assume that's because the app class loader delegates to the platform class loader? > If the provider interface is only for overriding then you could use ServiceLoader.load(LayerFactory.class).findFirst().orElse(DefaultLayoutFactory.get()) so that it use a default/fallback implementation in your module when there isn't a provider deployed on the module path. Ok, thanks for the tip. -Doug From mark.reinhold at oracle.com Sun Feb 26 15:24:37 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Sun, 26 Feb 2017 15:24:37 +0000 Subject: hg: jigsaw/jake/jdk: Add missing @spec/@revised tags for JPMS PR Message-ID: <201702261524.v1QFObab011013@aojmv0008.oracle.com> Changeset: afa342473815 Author: mr Date: 2017-02-26 15:23 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/afa342473815 Add missing @spec/@revised tags for JPMS PR ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java ! src/java.instrument/share/classes/java/lang/instrument/ClassFileTransformer.java From mark.reinhold at oracle.com Sun Feb 26 20:53:45 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Sun, 26 Feb 2017 20:53:45 +0000 Subject: hg: jigsaw/jake/jdk: Remove incorrect @spec tag on ClassLoader::resources Message-ID: <201702262053.v1QKrjA0019664@aojmv0008.oracle.com> Changeset: 4a27502b9049 Author: mr Date: 2017-02-26 20:52 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4a27502b9049 Remove incorrect @spec tag on ClassLoader::resources ! src/java.base/share/classes/java/lang/ClassLoader.java From scolebourne at joda.org Mon Feb 27 13:45:40 2017 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 27 Feb 2017 13:45:40 +0000 Subject: How to name modules, automatic and otherwise In-Reply-To: References: <20170216164827.A309F65E1B@eggemoggin.niobe.net> Message-ID: Having spent further time considering naming, I have come to the conclusion there is only one acceptable solution - highest package name (reverse DNS). It now seems to me that this can almost be "proven" as follows: Consider a module that contains three packages: module ??? { exports com.foo.willow; exports com.foo.willow.model; exports com.foo.willow.util; } It is possible to refactor such a module into three separate modules, where each module consists of one package: module ??? { exports com.foo.willow; requires transient ???.model; requires transient ???.util; } module ??? { exports com.foo.willow.model; } module ??? { exports com.foo.willow.util; } Note here that as a general rule, it is always possible to refactor a module into a number of single-package modules. (I can't actually prove this offhand, but it seems an entirely reasonable claim). Now, ask yourself the question - what should the module name be for each single-package module? There is only one possible, answer that is not completely ridiculous - the module name must be the same as the package name. Any other answer involves the invention of some other name that does not uniquely reference the content of the single-package module. module com.foo.willow { exports com.foo.willow; requires transient com.foo.willow.model; requires transient com.foo.willow.util; } module com.foo.willow.model { exports com.foo.willow.model; } module com.foo.willow.util { exports com.foo.willow.util; } Stepping back up to the original, it therefore follows that the module name must be a summary of the packages included. Which means, in general, the "highest" of the packages included/exported - aka reverse DNS. module com.foo.willow { exports com.foo.willow; exports com.foo.willow.model; exports com.foo.willow.util; } In fact, the primacy of package naming is fundamental to the whole Jigsaw design. The JPMS won't load two modules where the packages conflict. Exports and Requires are expressed at the package level too. And the developer writing code is actually importing from a package, not a module. There is thus no getting away from the fact that modules are built on top of the existing package concept, simply providing packages with greater security. Given all this, a module name SHOULD match one of the packages it contains. In essence, there are two worlds that JPMS seeks to keep separate - development and build system. The build system world has versions, artifacts, groups, organizations, jar-files, project names, etc - none of which affect bytecode. The development world has class, package and module names - all ending up in bytecode. Module names should therefore be completely uninfluenced by versions, artifacts, groups, organizations, jar-file names and project names. The fact that jar-files are being used to package modules is a big confusion to this whole naming debate, as the jar-file name is from the build system world, not the development world. With regards to automatic modules, this implies that automatic modules must contain the Module-Name MANIFEST information (as it takes too long to scan a jar for packages). Allowing the command line to map jar files to module names would also be acceptable. On 16 February 2017 at 16:48, wrote: > I do know, however, of at least > one major, well-known project whose developers intend to adopt the > project-name-prefix convention for their module names. Mark indicates that some projects are intent on using short names. To stop this (where developers try and be "clever" and anti-social) the module-info compiler and/or jar tool MUST emit a warning (I'd prefer error, but there are probably some edge cases). The warning would be something like "the module name must match or be related to one of the contained packages". While this does not absolutely prevent developers doing the wrong thing, it would provide additional force to the rule. Potentially Maven Central could also validate this. In summary, module naming must match package naming, because modules are ultimately just a collection of packages with some additional security rules. Any module can always be reduced to a number of single-package modules, and since there is only one possible name a single-package module should have, the combined module should have a name based on the packages contained - which will almost certainly be the highest contained package name. Stephen On 16 February 2017 at 23:19, Stephen Colebourne wrote: > On 16 February 2017 at 16:48, wrote: >> This can be done very simply, with a single new JAR-file manifest `Module-Name` attribute > > I welcome this. > >> The reversed domain-name approach was sensible in the early days of Java, >> before we had development tools sophisticated enough to help us deal with >> the occasional conflict. We have such tools now, so going forward the >> superior readability of short module and package names that start with >> project or product names is preferable to the onerous verbosity of those >> that start with reversed domain names. > > What tools? > > With short identifiers clashes are inevitable. Because the module name > is baked inside the module in binary format, the only way to resolve > the clash is to rewrite the module. The Java platform has not demanded > anything like this before, and I can't see how it meets the reliable > configuration requirement. Rewriting modules as part of the build > system is a red line for me. I need to be able to see that the module > on the module path is the same bits as that from the source of jars. > > The standard case to consider is as follows: > > - In 2017, a company creates an internal foundation library called > "willow" and it becomes very popular within the company and is used > 100s of times > - In 2018, an unrelated open source project starts up with the name > "willow" and becomes very popular. Both now publish modules with the > name "willow" (one privately, one publicly). > - In 2019, the company wants to use the open source "willow" library > (directly or indirectly), but can't due to name clash > - In 2020, the company wants to open source their "willow" library, > but can't due to name clash > > The plan outlined, favouring short IDs, provides no solution to this > problem that I can see. There simply isn't the breadth of identifier > to avoid clashes like this (you can't possibly predict the future > where you might need to coexist with an open source module that > doesn't even exist yet). Proposal (A) only tackles automatic modules, > and not the bigger problem where names are baked into the module > itself. > > The simplest and most consistent option is reverse DNS everywhere. > Everyone understand it and few will object! > > An alternative option would be that open source can use short names, > but companies "must" use reverse DNS. But this is far from ideal given > how projects move from private to public, or how companies merge. > > Another alternative is some form of group, that may or may not map > onto maven's group, where most of the time it does not have to be > specified: > > module mainlib from com.mycompany { > requires base; // implicit, favours group 'com.mycompany' if there is a clash > requires willow; // uses 'com.mycompany' because there is a clash > requires willow from org.joda; // explicitly specified, but only > needed to resolve a clash > } > > With this approach, the clash can be resolved, but only needs to be by > the first module in the graph to pull both in. Any transitive use of > the two willow modules would be fine. > > In summary, I recognise the desire for short, pretty identifiers. > However, I remain of the opinion that they are highly dangerous for > the wider ecosystem without some additional ability to qualify them. > The are many more private jars than public jars, and the clashes seen > today on Maven Central are just the tip of the iceberg of this > problem. > > Stephen From claes.redestad at oracle.com Mon Feb 27 18:55:36 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 27 Feb 2017 18:55:36 +0000 Subject: RFR: 8175561: Memory churn in jimage code affects startup after resource encapsulation changes In-Reply-To: <369c4d61-32d8-ae8d-6f88-45f6bde3ff37@oracle.com> References: <369c4d61-32d8-ae8d-6f88-45f6bde3ff37@oracle.com> Message-ID: <92e1e7d3-66b1-4d36-f87f-162488eab6bd@oracle.com> Hi, thanks Mandy and Jim for reviewing! However, I've found enough evidence now that we should this one step further and eliminating the allocation in BasicImageReader::findLocation(String, String), which completely gets rid of the regressions we're seeing: http://cr.openjdk.java.net/~redestad/8175561/jdk.02/ http://cr.openjdk.java.net/~redestad/8175561/jdk.01.02.diff/ Working through the details on how to do this it became clear that stringing together ImageStringsReader.hashCode - as done in ImageLocationWriter - is likely a bug in the making since it's not guaranteed to give equivalent results to applying the same method to the whole string. I took the liberty to fix this, and ran the final patch through several JDK and HotSpot test lists without any surprises. Thanks! /Claes On 02/23/2017 10:57 PM, Claes Redestad wrote: > Hi, > > various resource encapsulation changes in 9+148 meant an uptick in > footprint and startup times for certain applications. > > While some of this regression is hard to avoid[1] (opening readers, > touching more memory mapped pages etc), a large part is due to simple > java allocation churn, some of which can be optimized away by reducing > the number of objects we create when scanning modules for resources. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8175561 > Webrev: http://cr.openjdk.java.net/~redestad/8175561/jdk.01/ > > Thanks! > > /Claes > > [1] Things we could do in the future to improve further include adding > an index to the jimage (too late for 9) or marking modules with no > non-encapsulated resources as such so that they can be skipped. From Alan.Bateman at oracle.com Mon Feb 27 20:44:02 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 27 Feb 2017 20:44:02 +0000 Subject: How to name modules, automatic and otherwise In-Reply-To: References: <20170216164827.A309F65E1B@eggemoggin.niobe.net> Message-ID: On 27/02/2017 13:45, Stephen Colebourne wrote: > : > > Note here that as a general rule, it is always possible to refactor a > module into a number of single-package modules. (I can't actually > prove this offhand, but it seems an entirely reasonable claim). Yes, assuming no cycles. > : > > With regards to automatic modules, this implies that automatic modules > must contain the Module-Name MANIFEST information (as it takes too > long to scan a jar for packages). The contents of JAR files containing automatic modules need to be scanned anyway in order to determine the packages in the module, the module name doesn't help. > : > > > In summary, module naming must match package naming, because modules > are ultimately just a collection of packages with Some module don't contain any types/packages. Aggregator modules is one example (`java.se` and `java.se.ee`). Resource bundles (for i18n/translation) might only contain .properties files. Then there are modules that only contain native code, one example in the JDK is`jdk.jdwp.agent` (debugger agent). -Alan From alan.bateman at oracle.com Tue Feb 28 08:23:00 2017 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 28 Feb 2017 08:23:00 +0000 Subject: hg: jigsaw/jake/jdk: 2 new changesets Message-ID: <201702280823.v1S8N0fa009022@aojmv0008.oracle.com> Changeset: cd4be05bd9e5 Author: alanb Date: 2017-02-28 08:13 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/cd4be05bd9e5 Fixed typo in javadoc ! src/java.base/share/classes/java/lang/module/ModuleFinder.java Changeset: 1033991775b5 Author: alanb Date: 2017-02-28 08:22 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1033991775b5 exports_to/opens_to/provides_with not allowed to contain duplicates ! src/java.base/share/classes/jdk/internal/module/ModuleInfo.java